Báo cáo pickup (lượng đặt phòng mới tăng thêm) và drop (lượng hủy/giảm đặt phòng) hàng ngày giúp khách sạn theo dõi booking thay đổi ra sao giữa hai thời điểm. Bài này hướng dẫn từng bước cách chụp snapshot, phân loại sự kiện, tính delta và đọc tín hiệu để ra quyết định, phù hợp cho người mới làm Revenue Management.
Tóm tắt nhanh
- Chụp hai snapshot cùng ngày lưu trú và cùng thời điểm trước khi tính pickup/drop.
- Tách đặt mới, hủy và sửa booking để tránh gọi mọi chênh lệch là nhu cầu mới.
- Đối soát dữ liệu rồi mới dùng báo cáo để điều chỉnh giá hoặc tồn phòng.
Quy trình snapshot từng bước
Báo cáo pickup (lượng đặt phòng mới) / drop (lượng hủy/giảm đặt phòng) đo thay đổi giữa hai lần chụp booking cho cùng ngày lưu trú và cùng lead-time (khoảng thời gian từ lúc đặt phòng đến ngày khách đến). Nếu ngày lưu trú (stay date) là 18/08 tại mốc 30 ngày trước khi đến, snapshot (ảnh chụp dữ liệu tại một thời điểm) so sánh cũng phải ở đúng 18/08 và đúng mốc 30 ngày. So khác ngày hoặc khác lead-time trộn biến động thực với khác biệt thời điểm, khiến kết luận thiếu tin cậy.
Trước khi xuất dữ liệu, thống nhất đơn vị: booking, phòng, room nights, doanh thu phòng hay tổng doanh thu. Ghi rõ tiền tệ, thuế, phí, hoa hồng, giảm giá và trạng thái được tính. Gross và net revenue không thể so nếu quy tắc khác nhau. Dùng timestamp cố định, múi giờ, người thực hiện, dải stay date và bộ lọc; xác định lead-time nhất quán từ snapshot đến ngày khách đến.
Xuất các trường cần thiết: ID booking, ngày tạo, ngày đến/đi, trạng thái, số phòng, room type, giá, tiền tệ, segment, channel và lịch sử sửa. Lưu snapshot bất biến cùng timestamp, bộ lọc và phiên bản định nghĩa. Dữ liệu lịch sử đúng lead-time chỉ có thể lấy từ kho snapshot; PMS hiện tại không tái tạo chính xác trạng thái cũ.
Chuẩn hóa ngày giờ và mã phân khúc/kênh, xử lý trùng theo quy tắc đã duyệt, ghép A và B theo khóa booking cùng stay date. Phân loại thành mới, hủy, sửa đổi (amendment), không đổi và không ghép được. Booking nhiều đêm cần bung theo từng đêm để đổi ngày không bị tính như mất toàn bộ.
Đối chiếu tổng snapshot với PMS cùng thời điểm; kiểm tra bản ghi chưa ghép, ngày ngoài dải, tiền tệ lẫn, giá trị âm và thay đổi trạng thái. Đánh dấu null khi chưa biết; zero chỉ dùng khi đã quan sát và không phát sinh. Giữ ID cần thiết nhưng bảo vệ dữ liệu cá nhân.
Phân loại booking mới, cancellations và amendments
Booking mới xuất hiện ở snapshot mới nhưng không có ở bản cũ và thỏa điều kiện trạng thái. Hủy là booking trước đó chuyển sang hủy; ghi số phòng và doanh thu giảm theo từng stay date. Nếu khách hủy rồi đặt lại, liên kết sự kiện khi có chứng cứ để tránh tính hai giao dịch. Luôn trình bày pickup và cancellation gộp riêng dù net bằng zero.
Amendment (sửa đổi đặt phòng) gồm đổi ngày đến/đi, số phòng, hạng, giá, gói hoặc trạng thái. Tạo delta cho room nights, ADR và revenue. Đêm bị bỏ ghi drop ở ngày ấy, đêm mới thêm ghi pickup ở ngày mới. Tách biến động giá khỏi sản lượng để không gọi tăng giá là tăng cầu.
Quy định cách xử lý no-show, walk-in, complimentary, phòng out-of-order và booking chuyển kênh. OTA chuyển sang direct có thể chỉ là đổi nguồn, không phải hủy cộng booking mới. Giữ event history để không làm sai tỷ lệ hủy hoặc chi phí kênh.
Tính delta booking, room nights và revenue
Gọi A là snapshot cũ, B là mới; delta bằng B trừ A. Cộng số phòng từng đêm rồi mới tính room nights (số đêm phòng bán được). Quy doanh thu về cùng tiền tệ, thuế và cơ sở gross/net. ADR (giá phòng bình quân mỗi đêm) tổng bằng doanh thu phòng chia room nights, không phải trung bình ADR từng booking; nếu room nights bằng zero, để trống thay vì chia cho zero.
Ví dụ giả định: A có 42 room nights và 63 triệu đồng; B có 47 đêm và 70,5 triệu. Delta là +5 đêm, +7,5 triệu; ADR cả hai là 1,5 triệu. Bridge sự kiện: booking mới +8 đêm, hủy -2, amendment -1, tổng +5. Booking count cần định nghĩa riêng vì một booking có thể chứa nhiều phòng.
Pickup dùng stay date; đối chiếu kế toán có thể theo posting date. Không trộn hai trục thời gian trong một biểu đồ. Nêu rõ tiền tệ, phí, thuế, giảm giá, hoa hồng và cách định nghĩa gross/net để người đọc hiểu delta.
Bảng minh họa theo phân khúc và kênh
Số liệu sau là ví dụ giả định để minh họa cách tính, không phải benchmark hay số liệu thật. Hai snapshot cùng stay date/lead-time; revenue là gross doanh thu phòng theo cùng quy tắc.
| Stay date | Segment / channel | A room nights | B room nights | Delta | A revenue | B revenue | Revenue delta | Events |
|---|---|---|---|---|---|---|---|---|
| 18/08 | Leisure / OTA | 20 | 23 | +3 | 30.000.000 | 34.500.000 | +4.500.000 | 4 mới, 1 hủy |
| 18/08 | Corporate / Direct | 12 | 11 | -1 | 18.000.000 | 16.500.000 | -1.500.000 | Amend -1 |
| 18/08 | Group / Sales | 10 | 13 | +3 | 15.000.000 | 19.500.000 | +4.500.000 | Amend +3 |
| 18/08 | Tổng | 42 | 47 | +5 | 63.000.000 | 70.500.000 | +7.500.000 | Net positive |
Có thể lọc room type, rate plan (gói giá phòng) hoặc account nếu dữ liệu sạch; tránh lát cắt quá nhỏ dẫn tới kết luận từ một booking. Dòng tổng giúp xác nhận các segment/channel cộng khớp. Ghi chú cỡ mẫu và không suy rộng khi mẫu nhỏ.
Diễn giải tín hiệu và ghi action log
Pickup dương không đồng nghĩa tăng giá. Kiểm tra occupancy, tồn phòng bán được, pace (tốc độ đặt phòng tích lũy so với cùng mốc kỳ trước) với forecast hoặc cùng ngày lịch sử, giá cạnh tranh đáng tin, hủy dự kiến và net contribution sau phí kênh. Pickup OTA (đại lý du lịch trực tuyến) có thể tăng phòng nhưng giảm biên; corporate/direct giảm có thể báo thay đổi hợp đồng. Một hủy nhóm đơn lẻ khác xu hướng hủy lan rộng.
Đọc segment và channel cùng lúc, kiểm tra dịch chuyển. Direct tăng có thể bù OTA giảm mà không tăng tổng cầu. So pace cùng lead-time và loại ngày, không so ngày lễ với ngày thường. Đọc room nights cùng revenue để phân biệt sản lượng, ADR và mix.
Action log ghi ngày, stay date, phát hiện, giả thuyết, hành động, owner, hạn, kết quả mong đợi và trạng thái. Ví dụ: “18/08, Leisure/OTA +3 đêm, Corporate/Direct -1; kiểm tra hợp đồng, RM xác nhận allotment (hạn mức phòng phân bổ) trước 11:00; chưa mở giảm giá toàn khách sạn.” Kiểm chứng giả thuyết ở snapshot sau.
Kiểm soát chất lượng và nhịp họp
Checklist: stay date đúng, lead-time trùng, timestamp chính xác, tiền tệ đồng nhất, trạng thái nhất quán, không trùng booking, tổng khớp PMS, bản ghi chưa ghép có giải trình. Cảnh báo delta vượt ngưỡng nội bộ để điều tra, không dùng ngưỡng làm phán quyết tự động. Khi PMS gián đoạn, đánh dấu dữ liệu chưa đầy đủ.
Giữ dữ liệu thô chỉ đọc, phiên bản hóa truy vấn, ghi thay đổi định nghĩa, không ghi đè snapshot cũ. Dashboard có thể hiện pickup gross, drop gross, net delta, room nights, revenue, ADR, mix segment/channel và pace. Dùng cùng từ điển KPI để tránh một nhóm tính hủy theo ngày thao tác, nhóm khác theo stay date.
Trong họp doanh thu tập trung ngày thiếu cầu, giới hạn tồn, biến động kênh, booking nhóm rủi ro và amendment lớn. Giao kiểm tra allotment, liên hệ khách nhóm, rà rate fence hoặc điều chỉnh giá theo ngày. Ghi người làm và thời điểm review.
Quy trình kiểm tra chi tiết trước khi phát hành
Trước khi gửi báo cáo, người trích xuất ghi lại nguồn dữ liệu, thời điểm chạy, bộ lọc, phiên bản định nghĩa và tên tệp snapshot. Người kiểm tra độc lập chọn vài booking từ mỗi trạng thái để xác nhận ngày lưu trú, trạng thái, số phòng, giá và phân khúc khớp với PMS. Kiểm tra một booking nhiều đêm, một booking đổi ngày, một trường hợp hủy và một trường hợp chuyển kênh. Mẫu này không thay thế đối chiếu toàn bộ tổng, nhưng phát hiện lỗi ghép phổ biến trước khi số liệu được dùng để điều chỉnh giá hoặc tồn phòng.
So sánh số lượng bản ghi A và B, booking mới, hủy, amendments và booking không ghép được. Số lượng khác thường cần giải thích: có thể do đồng bộ chậm, lọc sai trạng thái, đổi mã nguồn hoặc lỗi xuất file. Kiểm tra tổng room nights bằng cách cộng từng stay date; booking nhiều đêm không được đếm một lần như một đêm. Kiểm tra tổng doanh thu sau khi quy đổi tiền tệ, đồng thời lưu tỷ giá và thời điểm áp dụng nếu có nhiều đồng tiền.
Nếu tổng delta không bằng tổng các sự kiện, không cân bằng bằng một dòng điều chỉnh vô danh. Tìm booking thiếu, quy tắc phân bổ thuế, làm tròn, đổi phòng, sửa ngày hoặc sự kiện đồng bộ đến muộn. Nếu cần một dòng điều chỉnh do hệ thống không cung cấp chi tiết, ghi nguyên nhân, số tiền, người xác nhận và cách xử lý ở kỳ sau. Chỉ phát hành khi sai lệch nằm trong ngưỡng kiểm soát đã duyệt hoặc được quản lý chấp nhận có ghi chú.
Thiết lập bảng đối chiếu gồm metric, tổng A, tổng B, delta tính trực tiếp, tổng event bridge, sai lệch và trạng thái kiểm tra. Đối với số booking, giải thích khác biệt giữa booking count và room count. Đối với revenue, xác nhận hủy có hoàn tiền hay không, thuế có được hoàn lại và doanh thu được phân bổ theo đêm ra sao. Bảng đối chiếu giúp người nhận truy ngược từ kết quả đến bản ghi thay vì chỉ tin một con số trên dashboard.
Bảo vệ tính toàn vẹn của file bằng cách lưu bản gốc chỉ đọc, đặt tên có ngày giờ, hạn chế sửa công thức và lưu bản phát hành riêng. Nếu dùng bảng tính, tách sheet dữ liệu thô, mapping, tính toán và dashboard; khóa vùng công thức, ghi đơn vị ở tiêu đề và không dùng ô màu làm nguồn dữ liệu duy nhất. Lưu nhật ký người sửa, thời gian và thay đổi. Tránh gửi dữ liệu nhận diện khách qua kênh không được phép; dashboard thường chỉ cần mã đã ẩn danh.
Khi phát hiện sai sau phát hành, phát hành bản sửa với số phiên bản và ghi rõ metric, ngày lưu trú, nguyên nhân và ảnh hưởng tới hành động trước đó. Không thay âm thầm file cũ vì người nhận có thể đã lưu bản riêng. Nếu lỗi làm thay đổi quyết định giá, allotment hoặc nhân sự, thông báo trực tiếp owner và yêu cầu xác nhận họ đã cập nhật. Bài học từ sai lệch cần thành quy tắc kiểm tra mới, không chỉ là ghi chú cho một người.
Ở cuộc họp, bắt đầu bằng các ngày có delta lớn hơn dự kiến hoặc có rủi ro thực thi. Người trình bày nêu kết quả, bridge, so sánh pace, giả thuyết và mức tin cậy. Người ra quyết định xác nhận hành động, phạm vi, thời hạn, tác động phụ và tiêu chí dừng. Ghi cả quyết định không hành động cùng lý do; ví dụ pickup thấp nhưng còn thời gian đặt dài và kênh direct đang được thử nghiệm, nhóm có thể chờ thêm một snapshot rồi đánh giá lại.
Review sau hành động phải xem outcome cùng baseline đã chốt, tránh đổi chuẩn sau khi biết kết quả. Nếu giảm giá, đo thêm doanh thu thuần, lượng tăng thêm, hủy và dịch chuyển kênh. Nếu gọi khách nhóm, xác nhận pickup thực tế và tình trạng allotment. Nếu mở thêm tồn phòng, theo dõi khả năng phục vụ và overbooking risk. Không quy toàn bộ biến động cho một hành động khi có nhiều yếu tố đồng thời; ghi nhận giới hạn quy kết để cải thiện lần phân tích tiếp theo.
Kết luận và đọc thêm
Dùng quy tắc nhất quán, kiểm tra dữ liệu và lưu lịch sử để biến báo cáo thành quyết định có thể rà soát. Nêu giới hạn thay vì suy diễn khi thiếu dữ liệu.
Đọc thêm: Pickup Report; Forecast Report; Group và Transient.
Đọc thêm
Forecast Report 30-60-90 ngày · Demand Forecasting khách sạn · Revenue Trend theo tháng
Câu hỏi thường gặp (FAQ)
Không nếu đo pickup cho một ngày cụ thể. Giữ cùng stay date và lead-time; mỗi ngày cần chuỗi riêng.
Ghi giảm ở đêm bỏ, tăng ở đêm mới và gắn cùng amendment; không tính hủy toàn phần nếu booking chỉ được sửa.
Chọn một định nghĩa, nêu thuế, phí, hoa hồng, giảm giá và tiền tệ. Không trộn gross với net.
Không thể tái tạo pickup chính xác từ trạng thái hiện tại. Bắt đầu lưu timestamped snapshot; đánh dấu quá khứ không khả dụng.
Booking nhỏ có thể thay booking dài; hủy và amendment cũng đổi mix. Đọc booking count, room nights, ADR và revenue cùng nhau.
