Demand Forecasting – Dự Báo Nhu Cầu Trong Khách Sạn Bằng Dữ Liệu

Bài viết tập trung vào pipeline (chuỗi xử lý dữ liệu từ nguồn đến báo cáo) dữ liệu đứng sau dự báo nhu cầu khách sạn: trích xuất từ PMS và các nguồn khác, làm sạch, chuẩn hóa định nghĩa, phân khúc, tính pickup và kiểm định đầu ra trước khi đưa vào mô hình dự báo.

Tóm tắt nhanh

• Dự báo nhu cầu bắt đầu từ dữ liệu đặt phòng theo ngày lưu trú, không phải từ mô hình phức tạp.
• Chuẩn hóa trạng thái đặt phòng, phòng-đêm, doanh thu và phân khúc trước khi tính lượng đặt mới hay hủy.
• Đối chiếu dự báo với kết quả thực tế, ghi lại lỗi nguồn và sửa giả định trước khi dùng để quyết định giá hoặc tồn phòng.

Từ snapshot đến quyết định: trọng tâm dữ liệu

Bài này tập trung vào pipeline dữ liệu: trích xuất PMS (phần mềm quản lý khách sạn) và nguồn ngoài, làm sạch, chuẩn hóa định nghĩa, phân khúc, tính pickup (lượng đặt phòng mới ghi nhận thêm) và kiểm định đầu ra. Khác với bài nền tảng demand forecast vốn xây quy trình dự báo tổng thể, tại đây mục tiêu là biến các bản ghi rời rạc thành tín hiệu đáng tin. Forecast không tốt hơn dữ liệu và quy tắc tạo nó. Nếu pickup tính trên snapshot (ảnh chụp dữ liệu tại một thời điểm) lệch phạm vi, segment (phân khúc khách hàng) thay đổi tên, hoặc booking sửa ngày bị đếm như booking mới, mô hình có thể cho con số chính xác bề ngoài nhưng sai ý nghĩa.

Sơ đồ pipeline và hợp đồng dữ liệu

Vẽ luồng từ PMS, channel manager (phần mềm đồng bộ giá và phòng trống lên nhiều kênh bán), CRS (hệ thống đặt phòng trung tâm), CRM (hệ thống quản lý quan hệ khách hàng), lịch sự kiện và bảng công suất đến vùng staging, vùng làm sạch, bảng phân tích và báo cáo. Với mỗi nguồn ghi owner, thời điểm trích xuất, timezone, khóa booking, trường ngày, trạng thái, currency, định nghĩa room night (một phòng được bán cho một đêm lưu trú) và tần suất. Thống nhất hợp đồng dữ liệu: kiểu trường, giá trị cho phép, xử lý null, phiên bản mapping và kiểm tra chất lượng. Lưu raw snapshot bất biến để tái lập kết quả; không ghi đè nguồn thô bằng dữ liệu đã làm sạch. Nếu file đến trễ hoặc schema đổi, đánh dấu pipeline chưa hoàn tất thay vì dùng âm thầm bản cũ.

Trích xuất snapshot và event log

Snapshot trả lời “tồn booking tại mốc này là bao nhiêu”; event log (nhật ký ghi lại các thay đổi của booking) trả lời “điều gì đổi và khi nào”. Lưu timestamp trích xuất, cutoff, bộ lọc ngày đến và trạng thái. Để đo pickup, cần hai snapshot tương đương. Nếu PMS có nhật ký sửa đổi, lấy booking ID, event time, loại thay đổi, giá trị trước/sau và người hoặc hệ thống tạo. Không suy ra booking mới từ chênh lệch tồn khi có đặt rồi hủy giữa hai snapshot. Kiểm tra độ trễ nạp, múi giờ địa phương và giao dịch qua nửa đêm. Nếu nguồn chỉ có snapshot, ghi rõ giới hạn phân tích.

Làm sạch khóa và trạng thái

Xác định khóa chính theo cấu trúc nguồn; một booking có thể có nhiều phòng hoặc sửa đổi, nên ID đơn lẻ chưa chắc là khóa dòng. Chuẩn hóa khoảng trắng, chữ hoa/thường và định dạng mã nhưng giữ bản gốc để truy nguyên. Tạo mapping trạng thái như confirmed, tentative (đặt phòng tạm giữ, chưa chốt), cancelled, no-show (khách đã đặt nhưng không đến) và checked-out theo định nghĩa đã duyệt. Không gộp tentative vào confirmed nếu mục đích khác nhau. Phát hiện trùng bằng khóa nghiệp vụ và dấu thời gian; phân biệt bản ghi lặp do tải file với hai phòng hợp lệ. Ghi số dòng bị loại, lý do và chủ sở hữu ngoại lệ để có thể kiểm toán.

Chuẩn hóa ngày, phòng đêm và doanh thu

Chuyển ngày đặt và ngày đến thành kiểu ngày chuẩn, lưu timezone nguồn. Một booking nhiều đêm tạo số dòng ngày lưu trú theo quy tắc nhất quán; booking đổi ngày phải phân bổ lại giữa ngày cũ và mới. Kiểm tra ngày đi sau ngày đến, room nights không âm và phòng đêm vượt thời gian lưu trú. Chuẩn hóa loại phòng, tiền tệ, thuế và quy ước gross/net riêng biệt. Đừng đổi số tiền đa tiền tệ mà không lưu tỷ giá, ngày tỷ giá và đơn vị ban đầu. Đối chiếu tổng phòng đêm với báo cáo PMS kiểm soát trước khi dùng dữ liệu cho forecast.

Phân khúc và mapping có hiệu lực thời gian

Dùng danh mục mã chuẩn cho segment và channel, lưu ngày hiệu lực để xử lý đổi taxonomy. Phân biệt loại nhu cầu như corporate/group/leisure với kênh direct/OTA (đại lý du lịch trực tuyến như Booking.com, Agoda, Expedia)/agency; không gộp hai chiều thành một nhãn. Booking có thể đổi segment khi thông tin được cập nhật, vì vậy pipeline cần quy tắc dùng trạng thái hiện tại hay trạng thái tại snapshot. Theo dõi mã unknown và giá trị mới, không tự động gán vào nhóm phổ biến. Xem tỷ lệ dữ liệu chưa phân loại theo ngày và nguồn. Nếu mapping thay đổi, chạy lại lịch sử có ghi phiên bản hoặc chú thích điểm đứt chuỗi.

Xử lý thiếu, ngoại lệ và lỗi nguồn

Phân biệt null, zero, not applicable và chưa tải. Không điền thiếu bằng trung bình toàn bộ nếu khác biệt có hệ thống. Báo cáo tỷ lệ thiếu theo trường, nguồn, ngày lưu trú và segment; ưu tiên sửa các trường ảnh hưởng đến pickup hoặc phân khúc. Đặt kiểm tra ngoại lệ: ngày bất khả thi, giá âm ngoài hoàn tiền, phòng đêm quá lớn, occupancy (tỷ lệ lấp đầy phòng) vượt năng lực và booking không có ngày đến. Không loại ngoại lệ tự động chỉ vì xa ngưỡng; có thể là đoàn lớn hợp lệ. Tạo hàng đợi xử lý với raw value, quy tắc kích hoạt, người xác minh, kết quả và ngày hoàn tất.

Pickup: định nghĩa, so sánh và phân rã

Định nghĩa pickup là biến động một chỉ số booking giữa hai snapshot cùng phạm vi và cùng lead time (khoảng thời gian từ lúc đặt đến ngày khách đến); nêu rõ đơn vị là booking, room nights hay doanh thu dự kiến. Tính gross pickup, drop/hủy và net pickup riêng nếu dữ liệu hỗ trợ. So sánh ngày đến cùng khoảng cách tới ngày lưu trú; kiểm soát thứ trong tuần, mùa, kênh và phòng khả dụng. Nếu snapshot trích xuất lệch giờ, các booking trong khoảng chênh có thể làm sai pace (tốc độ đặt phòng so với cùng kỳ). Không kết luận cầu tăng chỉ từ pickup; giá, trạng thái mở bán và chiến dịch kênh cũng ảnh hưởng. Liên kết kết quả với báo cáo forecast khách sạn để hiển thị nguồn và phiên bản.

Phân đoạn theo mục đích dự báo

Chọn segment theo khác biệt hành vi có thể hành động: lead time, cancellation, ADR (giá phòng bình quân), nguồn, quy tắc giá hoặc điều kiện hợp đồng. Bắt đầu bằng nhóm đủ lớn; phân đoạn quá nhỏ làm mẫu lịch sử nhiễu và tăng rủi ro nhận dạng khách. So sánh cả mix và hiệu suất trong nhóm. Đặt quy tắc khi booking đổi channel, nhiều nguồn cùng ghi nhận hoặc đoàn chuyển thành transient (khách lẻ, không thuộc đoàn hay hợp đồng). Xác định dữ liệu nào dùng cho forecast, dữ liệu nào chỉ dùng phân tích hậu kiểm. Tài liệu mapping cần ví dụ ranh giới để hai nhân viên không gán cùng booking vào hai segment khác nhau.

Bước thực hành: xử lý một ngày đến

Bước 1: lấy snapshot hiện tại và snapshot tham chiếu với timestamp. Bước 2: kiểm tra cutoff, ngày đến và số phòng mở bán. Bước 3: khóa booking hợp lệ, lưu trạng thái raw và trạng thái chuẩn. Bước 4: xử lý sửa đổi, hủy và booking đa phòng bằng quy tắc ID. Bước 5: phân bổ room nights theo ngày lưu trú, chuẩn hóa segment và channel. Bước 6: tính OTB (số phòng đã đặt còn hiệu lực tính đến thời điểm xem), pickup gross, drop và pickup net. Bước 7: so pace tại cùng lead time với lịch sử tươngparable. Bước 8: rà soát ngoại lệ và dữ liệu thiếu. Bước 9: tạo forecast kèm khoảng và giải thích driver (yếu tố tác động chính). Bước 10: ghi kết quả kiểm soát, phiên bản mapping và người duyệt. Mỗi bước có thể tái chạy mà không thay dữ liệu raw.

Ví dụ giả định: sai lệch do sửa ngày

Ví dụ giả định, không phải dữ liệu khách sạn thật: snapshot thứ Hai có 50 room nights cho ngày 20/9; snapshot thứ Ba có 53. Hiệu số ròng là +3. Event log cho thấy 6 room nights booking mới, 2 bị hủy và 1 chuyển từ ngày 19 sang 20. Nếu chỉ báo pickup +3, nhóm không biết nhu cầu mới là 6 hay thay đổi ròng là 3. Bảng vận hành trình bày cả gross pickup, drop, chuyển ngày và net. Nếu log thiếu, báo cáo ghi rõ “net change between snapshots”, không đặt nhãn “booking mới”. So sánh với snapshot năm trước chỉ hợp lệ khi cutoff và phạm vi tương đồng.

Kiểm định pipeline và đầu ra

Chạy kiểm tra tự động mỗi lần nạp: schema, tính duy nhất khóa theo quy tắc, tỷ lệ null, room nights, tổng doanh thu và phân phối trạng thái. Đối chiếu tổng với PMS bằng cùng bộ lọc; đặt ngưỡng cảnh báo theo lịch sử của cơ sở, không lấy ngưỡng chung không kiểm chứng. Lấy mẫu bản ghi đã làm sạch, truy ngược raw và đối chiếu booking. Kiểm tra kết quả sau mỗi thay đổi mapping. Theo dõi lỗi theo nguồn và thời gian xử lý. Báo cáo forecast nên nêu timestamp dữ liệu và trạng thái kiểm định; nếu kiểm tra thất bại, giữ bản trước với nhãn cũ hoặc phát hành cảnh báo rõ ràng.

Từ bảng dữ liệu đến forecast có thể dùng

Sau khi sạch, đưa OTB, pace, lịch sử pickup, hủy, phân khúc và inventory (số phòng còn có thể bán) vào mô hình. Dùng baseline (mức nền tham chiếu) đơn giản trước, phân tích sai số theo lead time và nhóm; chỉ thêm thuật toán nếu cải thiện được ngoài mẫu. Giữ feature và cách biến đổi có thể tái tạo. Mô hình không tự sửa được mapping sai hay snapshot mất. Khi dự báo occupancy, thống nhất mẫu số phòng bán được; đọc hướng dẫn occupancy forecasting. Khi cần doanh thu, nối giá và mix theo định nghĩa riêng qua revenue projection; không nhân một ADR tổng vào mọi phân khúc.

Quản trị, quyền truy cập và thay đổi

Đặt owner cho nguồn, mapping, kiểm tra và phê duyệt. Dữ liệu booking có thể chứa thông tin cá nhân; tối thiểu hóa trường nhận dạng, giới hạn quyền, dùng dữ liệu tổng hợp khi có thể và tuân thủ chính sách khách sạn. Ghi nhật ký ai sửa quy tắc làm sạch, ngày hiệu lực và lý do. Thử thay đổi trên bản sao hoặc pipeline staging, so tổng và forecast trước/sau rồi mới phát hành. Có kế hoạch rollback khi mapping mới làm lệch lịch sử. Không gửi snapshot có tên hoặc email khách trong báo cáo rộng nếu người nhận chỉ cần xu hướng tổng hợp.

Sai lầm pipeline thường gặp

Các lỗi lặp lại gồm trộn ngày đặt với ngày lưu trú, so sánh snapshot giờ khác nhau, đếm sửa đổi booking như đặt mới, bỏ mất hủy, phân khúc theo nhãn tự do, chuyển thiếu thành zero, cập nhật taxonomy ngược thời gian mà không lưu phiên bản, và so pickup ở lead time khác nhau. Thêm lỗi là xóa ngoại lệ lớn mà không kiểm tra có phải đoàn thật. Khắc phục bằng raw immutable, quy tắc có owner, hàng đợi ngoại lệ, reconciliation và versioning. Nếu không thể truy nguyên đầu vào của một forecast, không dùng nó cho quyết định giá trọng yếu.

Kết luận

Một pipeline dữ liệu demand forecasting đáng tin cậy cần dữ liệu nguồn immutable (không sửa trực tiếp), quy tắc xử lý ngoại lệ có chủ sở hữu, và khả năng truy nguyên từng con số về nguồn gốc. Nếu không thể giải thích một forecast đến từ đâu, đừng dùng nó cho quyết định giá quan trọng.

Câu hỏi thường gặp (FAQ)