Một khách dự hội nghị có thể đặt qua OTA; một gia đình dùng thẻ công ty để thanh toán chuyến nghỉ. Nếu hệ thống gán OTA = leisure và hóa đơn công ty = corporate, báo cáo có thể sai ngay từ khâu phân loại. Corporate và leisure chủ yếu trả lời câu hỏi mục đích chuyến đi; người chi trả, hợp đồng và kênh đặt cần được lưu thành những chiều riêng để lựa chọn giá và phân phối.
Tóm tắt nhanh
- Lưu mục đích chuyến đi, người thanh toán, tài khoản hợp đồng và kênh đặt thành các trường riêng; thiếu bằng chứng thì ghi chưa biết.
- Đánh giá hợp đồng công ty theo ngày ở, giá thực thu, chi phí và cam kết tồn phòng, không chỉ tổng số booking.
- Thử giá hoặc gói theo hành vi và đóng góp của nhóm khách thực tế; không mặc định OTA là nghỉ dưỡng hay mọi khách nghỉ đều nhạy giá.
Phân biệt purpose, payer, account và booking channel
Purpose là lý do chuyến đi: công vụ, hội họp, nghỉ dưỡng hoặc kết hợp. Payer là người hay tổ chức chịu chi phí; account là quan hệ thương mại hoặc hợp đồng; channel là đường đặt như website, OTA, GDS hoặc sales trực tiếp. Không chiều nào tự suy ra chiều còn lại. Trong hướng dẫn phân khúc STAR của STR/HSMAI, transient gồm cả giá corporate và đặt qua bên thứ ba, còn group là phòng bán đồng thời theo block; đó là phân loại nguồn kinh doanh cho báo cáo benchmark, không phải bằng chứng về động cơ của từng khách.
Thiết kế PMS/CRM với các trường độc lập: purpose (nếu khách tự nguyện cung cấp), payer, account ID, rate plan, channel, group block ID và mức tin cậy của phân loại. Nếu thiếu purpose, ghi “chưa biết”; không tự gán theo ngày trong tuần, giá hay thiết bị. Với chuyến bleisure, có thể lưu mục đích hỗn hợp hoặc tách các phần lưu trú khi dữ liệu và mục tiêu báo cáo cho phép; cùng một khách không buộc phải thuộc một nhóm vĩnh viễn.
Biến phân khúc thành quyết định thương mại
Khi đánh giá hợp đồng công ty, đọc sản lượng thực theo account, ngày lưu trú, room type, giá thực thu, hủy, chi phí phục vụ và phần nhu cầu có thể bị thay thế. Một account đặt qua GDS vẫn là account đó; phí GDS thuộc chiều chi phí kênh. Đừng đánh giá hợp đồng bằng tổng booking nếu nhiều đêm rơi vào ngày cao điểm và mức đóng góp thấp hơn khả năng bán thay thế. HSMAI khuyến nghị xét tổng giá trị account, chi phí ưu đãi và displacement trong quyết định giữa Sales và Revenue.
Với nhu cầu leisure, xem thời gian đặt trước, độ dài lưu trú, ngày cần lấp, nhu cầu hoàn hủy và chi phí kênh từ dữ liệu của chính khách sạn; đừng coi mọi khách nghỉ đều nhạy giá hay chỉ đi cuối tuần. Một rate plan có thể nhắm một hành vi đặt cụ thể nhưng cần kiểm tra eligibility, khả năng hủy và tác động lên khách vốn sẽ mua giá cao hơn. So contribution của phương án với trạng thái không can thiệp, không chỉ so ADR hoặc số lượt truy cập.
Ví dụ: ngày giữa tuần gần kín
Ví dụ giả định, tối thứ Tư chỉ còn 8 phòng king. Một account công ty muốn thêm 5 phòng theo giá hợp đồng; cùng lúc website nhận nhiều yêu cầu nghỉ ngắn ngày. Trước khi đóng bán cho account, Revenue kiểm tra hợp đồng có bảo đảm room availability hay không, pickup lịch sử đúng ngày, xác suất chốt của nhu cầu khác, phí kênh và loại phòng. Nếu có cam kết last-room availability, không tự ý từ chối chỉ vì dự báo giá lẻ cao. Nếu không có cam kết, thương lượng allotment hoặc điều kiện giá cho các ngày cao điểm; mô hình hóa phần đóng góp của từng lựa chọn theo kịch bản thấp/cơ sở/cao.
Đối chiếu báo cáo account với PMS để phát hiện đặt phòng gắn sai mã, lưu trú bị hủy và hóa đơn thanh toán tách người ở. Khi báo cáo corporate/leisure, cho biết tỷ lệ booking “chưa biết” và cách xử lý bleisure. Việc thu thập purpose không nên thành khảo sát bắt buộc không cần thiết: nguyên tắc tối thiểu hóa dữ liệu của ICO là tham chiếu hữu ích, còn nghĩa vụ pháp lý cụ thể phải đối chiếu quy định áp dụng tại nơi kinh doanh.
Kết luận
Đừng biến kênh bán thành loại khách. Lưu mục đích, người trả tiền, account và channel riêng; nêu mức độ chắc chắn của dữ liệu; rồi quyết định hợp đồng, giá và tồn phòng theo stay date, contribution và cam kết thực tế. Khi thiếu bằng chứng về purpose, phân tích tập hợp có nhãn chưa biết đáng tin hơn một báo cáo đã phân loại hết nhưng sai.
Câu hỏi thường gặp (FAQ)
Không. OTA là kênh đặt; mục đích công vụ hay nghỉ dưỡng cần bằng chứng riêng hoặc ghi chưa biết.
Không hẳn. Payer và purpose là hai trường khác; kiểm tra hợp đồng, account và thông tin khách được phép sử dụng.
Dùng nhãn hỗn hợp hoặc tách các đêm nếu có dữ liệu đáng tin, giữ nhất quán trong báo cáo và không ép thành một mục đích duy nhất.
