Một khách đặt ba lần chưa chắc là ba khách quay lại: họ có thể sửa hoặc hủy booking, đặt hộ người khác, hoặc tạo nhiều hồ sơ. Với Revenue Manager, câu hỏi cần trả lời là ai đã thực sự lưu trú lần đầu và ai trở lại trong một khoảng quan sát, rồi mỗi nhóm tạo ra đóng góp kinh tế nào. Bài này tập trung vào cohort khách và hành động giữ chân, khác với phân tích phễu đặt phòng hay tính LTV dài hạn.
Tóm tắt nhanh
- Đếm người lưu trú đã khử trùng lặp và các kỳ ở hoàn tất, không dùng số booking để xác định khách mới hay quay lại.
- So tỷ lệ quay lại giữa các nhóm khách có cùng thời gian theo dõi; tách người ở, người đặt hộ và tài khoản doanh nghiệp.
- Thử chăm sóc hoặc ưu đãi trên nhóm phù hợp, đo lượt ở và đóng góp tăng thêm sau chi phí; chỉ liên lạc trong phạm vi dữ liệu được phép dùng.
Chốt đơn vị người, lượt ở và cửa sổ thời gian
Đặt một mã khách đã khử trùng lặp làm đơn vị người; một lượt ở hoàn tất là một kỳ lưu trú của người đó tại khách sạn, không phải mỗi phòng-đêm hoặc mỗi booking. Khách “mới” trong kỳ là người có lượt ở đủ điều kiện đầu tiên được quan sát tại cơ sở; khách “quay lại” có một lượt ở hoàn tất trước đó trong phạm vi lịch sử đã chọn. Quy định trường hợp đặt hộ, đồng khách, đoàn, house use và lưu trú miễn phí. Nếu chỉ quan sát từ ngày mở PMS mới, gọi chính xác là “mới trong dữ liệu hiện có”, không khẳng định khách chưa từng đến.
Oracle phân biệt hồ sơ guest với company, agent và source, đồng thời cho phép nhiều hồ sơ gắn với reservation. Vì vậy người đặt, người trả tiền, người ngủ tại phòng và account doanh nghiệp không được gộp thành một “khách”. Cần nối booking ID với guest ID và stay ID; trường hợp hai người cùng phòng phải có quy tắc phân bổ doanh thu minh bạch hoặc chỉ đo người, không gán toàn bộ doanh thu phòng cho cả hai. Đếm khách theo ngày checkout hoặc ngày hoàn tất lưu trú, nhưng thống nhất trong mọi kỳ.
Làm sạch danh tính trước khi tính repeat rate
Một người có thể dùng tên viết khác, email OTA ẩn hoặc số điện thoại mới; hai người trong gia đình có thể chia sẻ liên hệ. Ưu tiên mã loyalty hoặc định danh đã được kiểm tra, rồi đối soát tên cùng dữ liệu đủ điều kiện; đưa ca không chắc vào nhóm chưa xác định. Tài liệu Oracle về hợp nhất hồ sơ cho biết việc merge có thể cập nhật lịch sử đặt và thống kê: cần lưu snapshot định nghĩa trước và sau khi merge để báo cáo cohort không tự nhiên thay đổi mà không có giải thích. Không ép gộp hồ sơ chỉ vì cùng họ tên hoặc cùng thẻ thanh toán.
Một repeat rate hữu ích là số người trong cohort lần đầu đã hoàn tất thêm một lượt ở trong cửa sổ theo dõi ÷ số người của cohort có đủ thời gian quan sát. Lấy cohort theo tháng checkout đầu tiên; chốt ngày trích và khoảng theo dõi trước khi tính. Không so cohort vừa đến tuần trước với cohort đã có cả năm để quay lại. Báo song song số người, số lượt ở, phòng-đêm, doanh thu phòng và đóng góp sau phí kênh; số booking xác nhận chỉ là tín hiệu sớm và phải tách khỏi kết quả lưu trú.
Ra quyết định khác nhau cho khách mới và khách quay lại
Với khách mới, xác định kênh mang khách đã lưu trú, chi phí thu hút và chất lượng kỳ ở đầu: hủy, phàn nàn, doanh thu thuần, nhu cầu dịch vụ. Nếu OTA giúp khách khám phá cơ sở, đừng tự nhận toàn bộ chi phí của lượt đầu là lãng phí; kiểm tra khả năng chuyển sang quan hệ trực tiếp ở những lượt sau bằng dữ liệu được phép dùng. Với khách quay lại, xem họ trở lại ngày thấp điểm hay chỉ xuất hiện trong đợt cao điểm vốn đã kín; ưu đãi giảm giá đại trà cho người vốn sẽ đặt là chi phí thay vì giữ chân.
Thử hành động theo cohort: nội dung nhắc đúng nhu cầu đã chủ động cung cấp, lựa chọn đặt lại dễ dùng, ưu đãi có điều kiện cho ngày cầu yếu, hoặc cải thiện trải nghiệm từng điểm đau. Lập nhóm đối chứng hoặc so cohort tương đồng; đo lượt ở tăng thêm và đóng góp sau ưu đãi, không chỉ tỷ lệ mở email hay số mã giảm giá dùng. Tách khác biệt mùa, mục đích chuyến đi và kênh ở lần đầu để tránh quy mọi chênh lệch cho “lòng trung thành”.
Giới hạn dữ liệu và quyền sử dụng
Dữ liệu ở một cơ sở không phản ánh khách quay lại cơ sở khác trong chuỗi nếu hồ sơ không được chia sẻ hợp lệ. Khách công tác có thể lặp lại vì hợp đồng công ty, không phải vì chương trình cá nhân; khách nghỉ dưỡng ít quay lại trong cửa sổ ngắn vẫn có thể hài lòng. Giới hạn quyền truy cập dữ liệu định danh, lưu cơ sở cho phép liên lạc và cơ chế từ chối; báo cáo tổng hợp chỉ cần mã ẩn danh cùng số liệu đủ dùng. Không dùng thông tin lưu trú nhạy cảm để suy đoán cá nhân hoặc gửi ưu đãi ngoài phạm vi cho phép.
Kết luận
Muốn có chiến lược khách quay lại, trước hết đếm đúng người và lượt ở hoàn tất, chuẩn hóa cửa sổ quan sát, rồi kiểm tra đóng góp tăng thêm của hành động. Booking mới, khách mới và khách quay lại là ba phép đo khác nhau; đặt tên rõ giúp Revenue, Marketing và vận hành không tối ưu nhầm mục tiêu.
Câu hỏi thường gặp (FAQ)
Chưa chắc. Chỉ tính quay lại khi cùng người có lượt lưu trú đủ điều kiện trước đó và thêm một lượt hoàn tất trong phạm vi đo.
Chỉ sau khi hai cohort có cùng thời gian theo dõi hoặc áp dụng phương pháp xử lý dữ liệu chưa đủ thời gian quan sát.
Không thể suy ra. Tách người lưu trú khỏi account công ty và người đặt, rồi kiểm tra lý do quay lại theo dữ liệu phù hợp.
