Dự báo nhu cầu phòng khách sạn không phải là việc nhìn vào công suất tháng trước rồi đoán tháng tới sẽ có bao nhiêu khách. Một forecast có giá trị phải dựa trên booking hiện tại, tốc độ booking, dữ liệu lịch sử, thời gian đặt phòng, mùa vụ, sự kiện và những thay đổi của thị trường để ước tính lượng phòng có khả năng được bán trong tương lai.
Với khách sạn nhỏ, quy trình này hoàn toàn có thể bắt đầu bằng Excel hoặc Google Sheets. Không cần chờ đến khi có Revenue Management System mới thực hiện forecast. Điều quan trọng là dữ liệu phải được theo dõi theo từng stay date, cập nhật đều và phương pháp tính phải nhất quán.
Cách Dự Báo Nhu Cầu Phòng Khách Sạn Về Cơ Bản
Một quy trình forecast thực tế có thể đi theo chuỗi:
Xác định stay date → Kiểm tra OTB → Phân tích Pickup → Kiểm tra Booking Pace → Đối chiếu Historical → Điều chỉnh theo Context → Forecast Demand → Forecast Occupancy → Đưa ra Action.
Mỗi bước trả lời một câu hỏi khác nhau. OTB cho biết khách sạn đã bán được bao nhiêu, Pickup cho biết booking mới đang vào thế nào, Pace cho biết tốc độ booking nhanh hay chậm so với benchmark, Historical cho biết pattern trong quá khứ và Context giúp điều chỉnh forecast khi có những yếu tố bất thường như lễ, sự kiện hoặc thay đổi thị trường.
Bước 1: Xác Định Stay Date Cần Forecast
Forecast nên bắt đầu từ ngày khách lưu trú, không phải ngày khách đặt phòng.
Ví dụ hôm nay là 1/9, khách sạn cần forecast cho ngày 15/9. Khi đó phải xác định:
- Còn 14 ngày đến stay date.
- Khách sạn có bao nhiêu phòng.
- Đã có bao nhiêu phòng OTB.
- Pickup trong những ngày gần nhất.
- Historical booking curve tại D-14.
- Forecast cuối cùng.
Có thể lập bảng:
| Stay Date | Days to Arrival | Available Rooms |
|---|---|---|
| 15/9 | 14 | 100 |
| 16/9 | 15 | 100 |
| 17/9 | 16 | 100 |
Không nên forecast cả tháng bằng một tỷ lệ occupancy duy nhất nếu mục tiêu là phục vụ pricing và inventory. Revenue Management cần nhìn từng stay date, bởi demand giữa weekday, weekend, holiday và event date có thể rất khác nhau.
Đang quản lý nhiều OTA và khó kiểm soát?
Khi bán phòng trên nhiều OTA, việc quản lý giá, availability, room type và booking trở nên phức tạp hơn. Chúng tôi hỗ trợ quản lý các kênh OTA và phối hợp hoạt động bán phòng phù hợp với quy mô của từng property.
Bước 2: Xác Định OTB
OTB (On-the-Books) là số room nights khách sạn đã có booking cho stay date tại thời điểm forecast.
Ví dụ:
| Stay Date | Available | OTB | OTB Occupancy |
|---|---|---|---|
| 15/9 | 100 | 60 | 60% |
| 16/9 | 100 | 45 | 45% |
| 17/9 | 100 | 80 | 80% |
Đây là điểm xuất phát của forecast.
Nếu ngày 17/9 đã có 80 phòng OTB thì forecast không thể bắt đầu từ giả định demand bằng 50% như một ngày bình thường. Nhưng OTB cũng chưa phải forecast cuối cùng vì vẫn còn booking có thể phát sinh.
Bước 3: Phân Tích Pickup
Sau khi biết OTB, cần xem booking đang tiếp tục vào với tốc độ nào.
Ví dụ:
| Stay Date | OTB 7 ngày trước | OTB hiện tại | Pickup |
|---|---|---|---|
| 15/9 | 48 | 60 | +12 |
| 16/9 | 42 | 45 | +3 |
| 17/9 | 68 | 80 | +12 |
Ngày 15/9 và 17/9 đều có pickup +12 phòng, nhưng cần đặt chúng trong bối cảnh khác nhau. Ngày 17/9 đã đạt 80% occupancy trong khi ngày 15/9 mới đạt 60%, nên cùng một mức pickup có thể dẫn đến quyết định khác nhau.
Pickup vì vậy không nên được đọc độc lập mà phải kết hợp với days to arrival và OTB hiện tại.
Bước 4: Kiểm Tra Booking Pace
Booking Pace cho biết tốc độ booking hiện tại so với một benchmark.
Benchmark có thể là:
- Cùng ngày năm trước.
- Cùng giai đoạn năm trước.
- Historical average.
- Một nhóm ngày tương tự.
Ví dụ:
| Stay Date | Historical OTB D-14 | Current OTB D-14 | Pace |
|---|---|---|---|
| 15/9 | 45% | 55% | Nhanh hơn |
| 16/9 | 50% | 42% | Chậm hơn |
| 17/9 | 70% | 72% | Tương đương |
Ngày 15/9 đang chạy nhanh hơn historical, trong khi ngày 16/9 đang chậm hơn đáng kể.
Đây là thông tin rất quan trọng để điều chỉnh phần demand còn lại trong forecast.
Bước 5: Xây Historical Booking Curve
Nếu khách sạn có dữ liệu lịch sử đủ tốt, nên xây booking curve.
Ví dụ một stay date trong năm trước có pattern:
| Days Before Arrival | Historical OTB |
|---|---|
| D-30 | 25% |
| D-21 | 35% |
| D-14 | 50% |
| D-7 | 68% |
| D-3 | 82% |
| D-1 | 92% |
| Arrival | 95% |
Hiện tại khách sạn đang ở D-14 và OTB đạt 60%.
So với historical 50%, hiện tại booking đang đi trước khoảng 10 điểm phần trăm.
Đây là tín hiệu cho thấy forecast cuối cùng có thể cao hơn historical final occupancy, nhưng cần kiểm tra thêm pace, segment và context trước khi kết luận.
Bước 6: Ước Tính Pickup Còn Lại
Đây là phần khó nhất của forecast.
Giả sử khách sạn có 100 phòng, hiện OTB 60 phòng và historical cho thấy từ D-14 đến arrival thường bán thêm 30 phòng.
Nếu các điều kiện hiện tại tương đối giống historical, có thể ước tính:
Forecast Demand = 60 + 30 = 90 phòng
Tương đương:
Forecast Occupancy = 90%
Nhưng đây mới là baseline.
Nếu booking pace hiện tại nhanh hơn historical đáng kể, expected pickup có thể cần tăng. Nếu pace chậm hơn hoặc demand market đang yếu, expected pickup có thể cần giảm.
Cách Tính Forecast Đơn Giản Cho Khách Sạn Nhỏ

Một phương pháp dễ triển khai là:
Forecast Demand = Current OTB + Expected Future Pickup
Ví dụ:
| Thành phần | Số phòng |
|---|---|
| OTB hiện tại | 60 |
| Expected Pickup | 25 |
| Forecast Demand | 85 |
| Available Rooms | 100 |
| Forecast Occupancy | 85% |
Phương pháp này dễ hiểu và phù hợp để khách sạn bắt đầu xây quy trình.
Tuy nhiên, Expected Pickup không nên là một con số đoán tùy ý. Nó nên được xây từ historical pickup, booking pace và đặc điểm của stay date.
Cách Forecast Dựa Trên Historical Booking Curve
Một phương pháp tốt hơn là sử dụng booking curve.
Giả sử historical data cho thấy tại D-14, khách sạn thường đạt 50% OTB và cuối cùng đạt 90%.
Nếu hiện tại D-14 đang đạt 60%, có thể suy ra demand đang chạy tốt hơn historical.
Một cách đơn giản:
Historical Final Demand × Current OTB ÷ Historical OTB
Ví dụ:
90% × 60% ÷ 50% = 108%
Kết quả này cho thấy phương pháp tỷ lệ đơn giản đã vượt capacity nên phải cap theo inventory. Forecast thực tế không thể vượt 100% nếu không xét overbooking.
Điểm quan trọng ở đây là: không nên áp dụng công thức máy móc. Nếu current OTB cao hơn historical, không có nghĩa final demand chắc chắn tăng theo đúng tỷ lệ đó.
Phương pháp này chỉ nên được sử dụng như một baseline và phải được điều chỉnh bằng pickup, pace, cancellation và market context.
Cách Forecast Dựa Trên Pickup
Một cách khác là sử dụng pickup historical.
Ví dụ từ D-14 đến arrival, historical average pickup là 35 phòng.
Hiện tại OTB là 55 phòng.
Forecast: 55 + 35 = 90 phòng
Nếu booking pace hiện tại nhanh hơn historical 20%, có thể điều chỉnh expected pickup, nhưng phải kiểm tra xem demand thực tế có còn room để tăng hay không.
Ví dụ:
| Thành phần | Giá trị |
|---|---|
| Current OTB | 55 |
| Historical Remaining Pickup | 35 |
| Pace Adjustment | +20% |
| Adjusted Pickup | 42 |
| Raw Forecast | 97 |
| Capacity | 100 |
| Forecast | 97% |
Đây là cách tiếp cận thực tế hơn so với việc lấy một tỷ lệ occupancy cố định cho tất cả các ngày.
Forecast Nên Điều Chỉnh Theo Ngày Trong Tuần
Không nên sử dụng cùng một booking curve cho:
- Monday.
- Tuesday.
- Friday.
- Saturday.
Ví dụ:
| Day | Historical Final Occupancy | Typical Pickup |
|---|---|---|
| Monday | 58% | +20 |
| Tuesday | 62% | +22 |
| Friday | 86% | +30 |
| Saturday | 94% | +32 |
Nếu stay date là Saturday, dùng historical pattern của Monday sẽ khiến forecast sai.
Đây là lý do day-of-week thường là một trong những biến số cơ bản cần đưa vào forecast.
Forecast Phải Xét Seasonality
Demand tháng 1 có thể khác hoàn toàn tháng 6 hoặc tháng 12.
Ví dụ:
| Period | Historical Occupancy |
|---|---|
| Low Season | 48% |
| Shoulder Season | 67% |
| High Season | 84% |
| Peak Holiday | 94% |
Nếu chỉ lấy occupancy trung bình cả năm làm baseline, forecast có thể sai rất xa trong mùa cao điểm hoặc thấp điểm.
Seasonality nên được đưa vào ngay từ khi xây historical benchmark.
Forecast Phải Xét Event
Một event lớn có thể làm historical data của ngày bình thường trở nên không còn phù hợp.
Ví dụ:
| Ngày | Historical Occupancy | Event | Forecast |
|---|---|---|---|
| 10/11 | 65% | Không | 68% |
| 11/11 | 66% | Concert | 92% |
| 12/11 | 64% | Không | 65% |
Ngày 11/11 không nên forecast dựa đơn thuần trên historical average vì demand đã thay đổi do event.
Trong trường hợp này, cần xem thêm:
- Quy mô event.
- Địa điểm.
- Số người dự kiến.
- Competitor availability.
- Giá thị trường.
- Pickup thực tế.
Forecast Phải Xét Lead Time
Nếu khách của khách sạn thường đặt trước 3–5 ngày, OTB tại D-14 có thể chưa nói lên nhiều.
Ngược lại, nếu khách thường đặt trước 30 ngày, OTB thấp ở D-14 có thể là dấu hiệu đáng lo.
Ví dụ:
| Hotel | Typical Lead Time | OTB D-14 | Interpretation |
|---|---|---|---|
| A | 3–5 ngày | 40% | Chưa kết luận |
| B | 20–30 ngày | 40% | Có thể đang chậm |
Cùng 40% OTB nhưng ý nghĩa hoàn toàn khác nhau.
Forecast Phải Tính Đến Cancellation
Không phải toàn bộ booking OTB đều chắc chắn trở thành room night thực tế.
Ví dụ khách sạn có:
OTB = 80 phòng
Nếu historical cancellation rate là 8%, có thể ước tính net OTB thấp hơn gross OTB.
| Chỉ số | Giá trị |
|---|---|
| Gross OTB | 80 |
| Expected Cancellation | 6 |
| Net OTB | 74 |
Tuy nhiên, cancellation không nên áp dụng bằng một tỷ lệ cố định cho mọi segment hoặc channel nếu dữ liệu cho thấy hành vi khác nhau.
OTA, direct, group và corporate có thể có cancellation pattern rất khác.
Forecast Theo Segment Có Thể Cải Thiện Độ Chính Xác
Thay vì forecast tổng 100 phòng, có thể chia:
| Segment | OTB | Expected Pickup | Forecast |
|---|---|---|---|
| Leisure | 40 | +20 | 60 |
| Corporate | 15 | +10 | 25 |
| Group | 20 | +2 | 22 |
| Wholesale | 10 | +3 | 13 |
Tổng forecast raw là 120 room nights, nhưng nếu khách sạn chỉ có 100 phòng thì cần xử lý inventory và overlap giữa các segment.
Đây là lý do forecast theo segment nên được sử dụng cẩn thận, đặc biệt khi các segment cạnh tranh cùng inventory.
Forecast Theo Room Type
Khách sạn có nhiều room type cũng nên cân nhắc forecast riêng.
Ví dụ:
| Room Type | Inventory | OTB | Expected Pickup | Forecast |
|---|---|---|---|---|
| Standard | 50 | 40 | +8 | 48 |
| Deluxe | 30 | 18 | +8 | 26 |
| Suite | 20 | 6 | +5 | 11 |
Hotel forecast có thể vẫn chưa full nhưng Standard gần sold out trong khi Suite còn nhiều inventory.
Thông tin này quan trọng cho pricing và upselling.
Forecast ADR Và Revenue Sau Khi Forecast Demand
Sau khi forecast room demand, có thể chuyển sang forecast doanh thu.
Ví dụ:
| Chỉ số | Forecast |
|---|---|
| Rooms Sold | 85 |
| Occupancy | 85% |
| ADR | 1.050.000đ |
| RevPAR | 892.500đ |
| Room Revenue | 89.250.000đ |
Công thức:
Forecast Room Revenue = Forecast Rooms Sold × Forecast ADR
và:
Forecast RevPAR = Forecast Room Revenue ÷ Available Rooms
Điều này cho thấy demand forecast là đầu vào quan trọng của revenue forecast.
Forecast Không Nên Chỉ Có Một Con Số
Trong một số trường hợp, đặc biệt khi stay date còn xa, nên sử dụng scenario forecast.
Ví dụ:
| Scenario | Occupancy | Điều kiện |
|---|---|---|
| Low | 65% | Pickup yếu |
| Base | 75% | Theo historical |
| High | 85% | Pickup mạnh |
Thay vì nói:
“Ngày 20/12 forecast 75%.”
Revenue Manager có thể hiểu:
“Base case là 75%, nhưng nếu pickup tiếp tục ở mức hiện tại thì có khả năng lên 85%; nếu demand yếu hơn dự kiến thì có thể chỉ đạt 65%.”
Cách này hữu ích khi stay date còn xa và uncertainty lớn.
Forecast Nên Được Rolling
Forecast không nên lập một lần.
Ví dụ:
| Time | OTB | Forecast |
|---|---|---|
| D-30 | 35% | 72% |
| D-21 | 45% | 76% |
| D-14 | 58% | 82% |
| D-7 | 72% | 90% |
| D-3 | 84% | 95% |
Mỗi khi có thêm booking, cancellation hoặc thông tin thị trường mới, forecast được cập nhật.
Đây gọi là rolling forecast.
Forecast Accuracy Nên Được Đo Như Thế Nào?
Forecast không thể cải thiện nếu khách sạn không đo xem forecast trước đây sai bao nhiêu.
Có thể bắt đầu rất đơn giản:
Forecast Error = Actual − Forecast
Ví dụ:
| Stay Date | Forecast | Actual | Error |
|---|---|---|---|
| 10/9 | 80% | 78% | -2 điểm % |
| 11/9 | 75% | 82% | +7 điểm % |
| 12/9 | 90% | 88% | -2 điểm % |
Sau một thời gian, khách sạn có thể tính thêm các chỉ số như MAE, MAPE hoặc bias để đánh giá chất lượng forecast.
Nhưng với khách sạn nhỏ, việc quan trọng nhất ban đầu là tạo thói quen:
Forecast → Actual → Sai lệch → Tìm nguyên nhân → Điều chỉnh phương pháp.
Khi Nào Forecast Đang Có Vấn Đề?
Không nên chỉ nhìn một lần forecast sai.
Hãy tìm pattern.
Ví dụ:
| Tháng | Forecast | Actual | Error |
|---|---|---|---|
| 1 | 80% | 72% | -8 |
| 2 | 82% | 74% | -8 |
| 3 | 85% | 76% | -9 |
Nếu forecast liên tục cao hơn actual, phương pháp có thể đang over-forecast.
Ngược lại:
| Tháng | Forecast | Actual | Error |
|---|---|---|---|
| 1 | 65% | 73% | +8 |
| 2 | 68% | 76% | +8 |
| 3 | 70% | 79% | +9 |
Khách sạn đang under-forecast, có thể khiến Revenue Manager bỏ lỡ cơ hội tăng giá.
Forecast Có Nên Dùng Excel Không?
Có.
Đối với khách sạn nhỏ, Excel hoặc Google Sheets hoàn toàn có thể đủ để xây quy trình ban đầu.
Một file cơ bản có thể có các cột:
| Stay Date | DTA | Capacity | OTB | Pickup | Historical | Pace | Forecast | Actual |
|---|---|---|---|---|---|---|---|---|
| 15/9 | 14 | 100 | 60 | +12 | 90% | Strong | 92% | — |
| 16/9 | 15 | 100 | 45 | +3 | 75% | Weak | 68% | — |
| 17/9 | 16 | 100 | 80 | +12 | 95% | Strong | 98% | — |
Khi dữ liệu đủ lớn, có thể nâng cấp lên PMS/CRS/Revenue Management System hoặc BI dashboard.
Nhưng công cụ không thay thế methodology. Một dashboard đẹp với forecast sai vẫn là một hệ thống forecast kém.
Khách Sạn Mới Chưa Có Historical Data Thì Làm Gì?
Nếu chưa có dữ liệu lịch sử, khách sạn vẫn có thể forecast nhưng phải dựa nhiều hơn vào:
- OTB.
- Pickup.
- Competitor.
- Market demand.
- Event.
- Seasonality.
- Lead time từ booking hiện tại.
- Data từ OTA/PMS nếu có.
Ban đầu forecast sẽ có độ bất định cao hơn.
Sau khi vận hành vài tháng, khách sạn bắt đầu tích lũy booking curve của chính mình. Sau một năm, dữ liệu lịch sử sẽ trở nên có giá trị hơn rất nhiều.
Do đó, không có historical data không có nghĩa là không thể forecast; chỉ có nghĩa là forecast cần phụ thuộc nhiều hơn vào external data và phải được cập nhật thường xuyên hơn.
Từ Forecast Đến Quyết Định Revenue

Forecast không phải mục tiêu cuối cùng. Mục tiêu cuối cùng là ra quyết định tốt hơn.
Ví dụ:
| Tình trạng | Forecast | Có thể cân nhắc |
|---|---|---|
| Demand yếu | 55% | Kiểm tra pricing, promotion |
| Demand ổn định | 70% | Theo dõi pace |
| Demand mạnh | 88% | Bảo vệ ADR |
| Gần full | 96% | Kiểm soát rate/inventory |
Các threshold này chỉ mang tính minh họa. Mỗi khách sạn cần xây ngưỡng riêng dựa trên market, seasonality, room type và booking curve.
Điểm quan trọng là phải có logic:
Forecast thay đổi → Action thay đổi.
Một Quy Trình Forecast Hàng Ngày Cho Khách Sạn Nhỏ
Nếu chưa có Revenue Manager chuyên trách, chủ khách sạn hoặc quản lý có thể dành một khoảng thời gian cố định mỗi ngày để xem các stay date quan trọng.
Có thể ưu tiên:
7 ngày tới: kiểm tra toàn bộ.
8–30 ngày: tập trung ngày có pickup bất thường hoặc forecast lệch.
31–90 ngày: xem trend, event và seasonality.
Mỗi ngày chỉ cần cập nhật những thông tin quan trọng:
| Stay Date | OTB | Pickup | Pace | Forecast | Action |
|---|---|---|---|---|---|
| 15/9 | 72% | +8 | Strong | 92% | Bảo vệ rate |
| 16/9 | 48% | +2 | Weak | 62% | Theo dõi/kích cầu |
| 17/9 | 88% | +6 | Strong | 98% | Kiểm soát inventory |
Đây là cách đơn giản để biến forecast thành một phần của hoạt động Revenue hàng ngày.
Những Sai Lầm Khi Dự Báo Nhu Cầu Phòng
Dùng Occupancy trung bình làm Forecast
Occupancy trung bình tháng hoặc năm không phản ánh booking curve của từng stay date.
Chỉ dựa vào năm trước
Historical data cần được kết hợp với OTB, pace, pickup và market context.
Không phân biệt ngày thường và ngày đặc biệt
Weekend, holiday và event date có demand pattern riêng.
Không tính Lead Time
OTB thấp ở D-14 có ý nghĩa khác nhau với thị trường booking window 3 ngày và 30 ngày.
Không tính Cancellation
Gross OTB có thể cao nhưng net demand thấp hơn.
Forecast không cập nhật
Demand thay đổi mỗi ngày nên forecast cũng phải được cập nhật.
Không đo Forecast Accuracy
Nếu không so sánh forecast với actual, khách sạn không biết phương pháp đang tốt lên hay xấu đi.
Forecast nhưng không hành động
Nếu forecast không ảnh hưởng đến pricing, inventory, promotion hoặc distribution thì giá trị quản trị rất thấp.
Kết Luận
Cách dự báo nhu cầu phòng khách sạn hiệu quả không bắt đầu từ một công thức phức tạp mà bắt đầu từ dữ liệu đúng và quy trình đúng. Khách sạn cần xác định stay date, kiểm tra OTB, phân tích Pickup và Booking Pace, đối chiếu historical booking curve, sau đó điều chỉnh forecast theo day-of-week, seasonality, lead time, cancellation, segment, room type và event.
Một mô hình đơn giản có thể bắt đầu bằng:
Forecast Demand = OTB + Expected Pickup
Sau đó nâng cấp dần bằng historical booking curve và pace adjustment.
Quan trọng hơn, forecast phải là rolling forecast. Khi booking mới, cancellation hoặc market condition thay đổi, forecast cũng phải thay đổi. Sau mỗi kỳ, cần so sánh forecast với actual để tìm bias và cải thiện phương pháp.
Đối với khách sạn nhỏ, chưa cần bắt đầu bằng một hệ thống phức tạp. Một bảng Excel được cập nhật đều theo từng stay date đã có thể xây dựng nền tảng rất tốt:
OTB → Pickup → Pace → Historical → Context → Forecast → Action → Actual → Accuracy
Đó là vòng lặp giúp forecast ngày càng tốt hơn và biến dự báo nhu cầu thành một công cụ thực sự phục vụ pricing, inventory và Revenue Management.
Bạn không có thời gian theo dõi OTA mỗi ngày?
Việc vận hành OTA cần theo dõi booking, giá, availability, khuyến mãi, room type và các thay đổi trên từng kênh. Chúng tôi hỗ trợ vận hành OTA thường xuyên để bạn giảm tải công việc và duy trì hoạt động bán phòng ổn định.
