การตลาดโรงแรม

FAQ Forecasting

FAQ / Forecasting

คำตอบสั้นที่ออกแบบให้ cite ได้ง่าย พร้อมลิงก์ไปบทความหรือ glossary ที่เกี่ยวข้อง

1hotel Demand Forecast คืออะไร

hotel Demand Forecast คือการคาดการณ์ Demand ห้องพักในอนาคต โดยรวม OTB ที่จองแล้ว, Pickup ที่คาดว่าจะเข้ามาตามประวัติ, ลบ cancellation/No-show ที่คาดและ wash ของ group ผลลัพธ์ใช้ขับเคลื่อนทั้งการตั้งราคา inventory และการวางแผนปฏิบัติการ

  • นิยาม
  • องค์ประกอบของ Forecast
  • สูตรพื้นฐาน
  • ใช้ทำอะไรต่อ
2Forecast โรงแรมประกอบด้วยอะไรบ้าง

ประกอบด้วย 4 ส่วน ได้แก่ OTB (จองยืนยันแล้ว), expected Pickup (จองที่คาดว่าจะเข้ามาตามประวัติ), expected cancellation/No-show (ลดตามอัตราของแต่ละ Segment) และ Wash Factor (ปรับสำหรับ group ที่ block เกินจริง)

  • OTB
  • expected Pickup
  • cancellation/No-show
  • Wash Factor
3Forecast คำนวณยังไง

Final Forecast = OTB + expected remaining Pickup – expected cancellations – wash โดย OTB มาจากระบบ Pickup ประมาณจากประวัติวันคล้ายกัน cancellation จากอัตราของแต่ละ Segment และ wash จากประวัติ group แต่ละประเภท

  • สูตรเต็ม
  • ที่มาของแต่ละองค์ประกอบ
  • ตัวอย่างคำนวณ
  • ปรับตาม Segment
4ทำไม Forecast ถึงสำคัญ

เพราะ Forecast เป็นฐานของทุกการตัดสินใจ revenue management ตั้งราคา (ขึ้นถ้า Forecast สูง ลดถ้าต่ำ), จัดการ inventory และ restriction, ทำ Displacement และยังขับเคลื่อนการวางแผนข้ามแผนก (housekeeping, F&B, front desk, การเงิน) Forecast ผิดทำให้ตัดสินใจผิดทั้งสาย

  • ฐานการตั้งราคา
  • จัดการ inventory
  • ทำ Displacement
  • วางแผนข้ามแผนก
5Forecast horizon มีกี่ช่วง

โดยทั่วไปแบ่ง 4 ช่วง ได้แก่ 0-7 วัน (tactical: rate/inventory นาทีสุดท้าย), 8-30 วัน (operational: staffing, purchasing, rate moves), 31-90 วัน (strategic: promotion, channel strategy) และ 91-365 วัน (budget/planning: capex, hiring, contract) แต่ละช่วงมีเป้าความแม่นต่างกัน

  • 4 ช่วง horizon
  • ใช้แต่ละช่วงทำอะไร
  • เป้าความแม่นต่างกัน
  • ยิ่งใกล้ยิ่งแม่น
6Forecast แต่ละ horizon ควรแม่นแค่ไหน

เป้าหมายทั่วไป 0-7 วัน ±2% Occupancy, 8-30 วัน ±5%, 31-90 วัน ±8%, 91-365 วัน ±12% ยิ่งใกล้วันเข้าพักยิ่งควรแม่นเพราะ OTB เป็นสัดส่วนมากขึ้นและ Pickup ที่เหลือน้อยลง

  • เป้าแต่ละ horizon
  • ใกล้วันแม่นกว่า
  • เหตุผลความแม่นต่างกัน
  • ใช้วัด Forecast accuracy
7Forecast accuracy คืออะไร

Forecast accuracy คือความแม่นยำของ Forecast เทียบกับ actual วัดจาก variance ระหว่างที่คาดกับที่เกิดจริง เป้าทั่วไปเดือนถัดไป ±3-5% Occupancy, สัปดาห์ถัดไป ±2%, เดือนปัจจุบัน rolling ±3% ความแม่นต่ำแปลว่ากระบวนการ Forecast ต้องปรับปรุง

  • นิยาม
  • วัดจาก variance
  • เป้าแต่ละช่วง
  • ใช้ประเมินกระบวนการ
8Forecast variance วิเคราะห์ยังไง

แยก variance ว่ามาจาก room nights (Demand error) หรือ ADR (rate/mix error) แล้วศึกษา variance แยกตามวันในสัปดาห์และ Segment เพื่อหาจุดอ่อนเชิงระบบ ทุก variance คือโอกาสเรียนรู้ปรับ Forecast รอบถัดไป

  • แยก room nights vs ADR
  • ศึกษาตาม day และ Segment
  • หาจุดอ่อนเชิงระบบ
  • เรียนรู้รอบถัดไป
9Pace กับ Pickup ใช้ทำ Forecast ยังไง

Pace (เทียบ OTB กับ STLY ที่ lead time เดียวกัน) บอกว่าวันนั้นสร้างเร็วหรือช้ากว่าปีก่อน ส่วน Pickup (ห้องที่เพิ่มเข้ามา) บอกความเคลื่อนไหวล่าสุด รวมกันช่วยประมาณ remaining Pickup ที่จะบวกเข้า OTB เพื่อให้ได้ final Forecast

  • Pace บอกเทียบประวัติ
  • Pickup บอกความเคลื่อนไหว
  • รวมกันประมาณ remaining Pickup
  • ได้ final Forecast
10booking curve ช่วย Forecast ยังไง

booking curve แสดง pattern การ Pickup ของวันคล้ายกันในอดีต ทำให้ประมาณได้ว่าจาก OTB ปัจจุบันที่ lead time นี้ จะ Pickup เพิ่มอีกเท่าไรจนถึงวันเข้าพัก การเทียบ curve ปัจจุบันกับประวัติเผยทันทีว่า ahead/behind Pace และควรปรับ Forecast ขึ้นหรือลง

  • แสดง pattern Pickup ประวัติ
  • ประมาณ remaining Pickup
  • เทียบ ahead/behind
  • ปรับ Forecast
11unconstrained Demand Forecast คืออะไร

unconstrained Demand Forecast คือการคาดการณ์ Demand ทั้งหมดโดยไม่จำกัดด้วย capacity ใช้ denial/regret data เติมส่วนที่ถูกปฏิเสธหรือเสียไป ทำให้รู้ว่าวันไหน Demand จริงเกินห้องที่มี (ควรขึ้นราคา/ใส่ MLOS) ต่างจาก constrained Forecast ที่จำกัดที่จำนวนห้อง

  • นิยาม
  • ใช้ denial/regret data
  • เผยวันที่ Demand เกิน capacity
  • ต่างจาก constrained
12Demand calendar คืออะไร

Demand calendar คือเครื่องมือวางแผนพื้นฐานของ revenue management เป็น roadmap รายปีที่จับคู่ pattern Demand ในอดีตกับ event ในอนาคต ระบุระดับ Demand แต่ละวัน (High/Medium/Low/Distressed), event, วันหยุด และ pattern คู่แข่ง เพื่อให้ตัดสินใจราคาแบบ proactive

  • นิยาม
  • roadmap รายปี
  • จับคู่ประวัติกับ event
  • ตั้งราคา proactive
13Demand calendar มีอะไรบ้าง

ประกอบด้วย RevPAR รายวันปีก่อน, groups และ events (ในโรงแรมและตลาด), ระดับ Demand แต่ละวันปีก่อนและที่คาดปีนี้, วันหยุดราชการและโรงเรียนแยกตาม feeder market, indicator Demand ผิดปกติ และวัน sell-out/ราคาสูงของคู่แข่ง

  • RevPAR รายวันปีก่อน
  • groups และ events
  • ระดับ Demand และวันหยุด
  • ข้อมูลคู่แข่ง
14สร้าง Demand calendar ยังไง

เริ่มจาก RevPAR/Occupancy รายวันปีก่อนจาก PMS, overlay event ทั้งหมด (วันหยุดราชการ/โรงเรียนแยกประเทศ Source Market, local event, conference, festival), วิเคราะห์สถิติ arrival ตาม feeder market เทียบปฏิทินวันหยุดของเขา, บันทึก Demand exception และอัปเดตอย่างน้อยรายสัปดาห์

  • เริ่มจาก RevPAR ปีก่อน
  • overlay event และวันหยุด
  • วิเคราะห์ feeder market
  • อัปเดตรายสัปดาห์
15feeder market คืออะไรและเกี่ยวกับ Forecast ยังไง

feeder market คือตลาดต้นทาง (ประเทศ/เมือง) ที่ส่งแขกมาโรงแรม การรู้ feeder market ช่วย Forecast เพราะวันหยุดและ pattern การเดินทางของแต่ละตลาดต่างกัน เช่น Golden Week จีน, school holiday ยุโรป สร้าง Demand spike เฉพาะที่ต้องใส่ใน Demand calendar

  • นิยาม
  • ตลาดต้นทางของแขก
  • วันหยุดแต่ละตลาดต่างกัน
  • ใส่ใน Demand calendar
16segmented Forecast คืออะไร

segmented Forecast คือการ Forecast แยกตาม Segment (transient BAR, corporate, wholesale, group) แทนการ Forecast รวม เพราะแต่ละ Segment มี lead time, Pickup pattern และอัตรา cancellation ต่างกัน การแยก Segment ทำให้ Forecast แม่นขึ้นและเห็นว่า ADR จะขึ้นหรือลงตาม mix ที่เข้ามา

  • นิยาม
  • แยกตาม Segment
  • แต่ละกลุ่ม pattern ต่างกัน
  • แม่นขึ้นและเห็น ADR trend
17ทำไมต้อง Forecast แยก Segment

เพราะแต่ละ Segment Pickup คนละแบบ (corporate จองใกล้วัน, wholesale จองไกล), cancellation คนละอัตรา และ ADR คนละระดับ ถ้า Forecast รวมจะมองไม่เห็นว่า mix กำลังเปลี่ยนไปทางราคาสูงหรือต่ำ การแยก Segment ทำให้ทั้ง Occupancy และ ADR Forecast แม่นขึ้น

  • Pickup คนละแบบ
  • cancellation คนละอัตรา
  • mix กระทบ ADR
  • แม่นทั้ง Occupancy และ ADR
18monthly Pickup analysis คืออะไร

monthly Pickup analysis คือการ snapshot Occupancy% รายเดือนของทุกเดือนในอนาคต (definite booking) ทุกวันที่ 1 ของเดือน แล้ว track เดือนต่อเดือนเพื่อดูว่าแต่ละเดือนสร้างไกลแค่ไหนและด้วย Pace เท่าไร เทียบปีปัจจุบันกับปีก่อนที่ lead time เดียวกัน

  • นิยาม
  • snapshot Occupancy รายเดือน
  • track month-over-month
  • เทียบ STLY
19daily Pickup tracking คืออะไร

daily Pickup tracking คือการ track การเปลี่ยนแปลง OTB รายวันแยกตาม Segment สำหรับ 30-90 วันข้างหน้า เครื่องมือ segmented Pickup แสดงไม่ใช่แค่ห้องที่เพิ่ม แต่ Segment ไหนขับเคลื่อนและที่ราคาเฉลี่ยเท่าไร เผยว่า ADR กำลังขึ้นหรือลงตาม booking ที่สะสม

  • นิยาม
  • track OTB รายวันแยก Segment
  • เห็นว่ากลุ่มไหนขับเคลื่อน
  • เผย ADR trend
20STLY คืออะไร

STLY (Same Time Last Year) คือการเทียบ OTB ปัจจุบันกับ OTB ปีก่อน ณ lead time เดียวกัน (ไม่ใช่เทียบกับผลรวมสุดท้ายปีก่อน) ใช้วัด Pace ว่าวันนี้สร้างเร็วหรือช้ากว่าจุดเดียวกันปีที่แล้ว เป็นฐานสำคัญของการอ่าน Pace

  • นิยาม
  • เทียบ ณ lead time เดียวกัน
  • ไม่ใช่เทียบผลรวมสุดท้าย
  • ใช้วัด Pace
21Pace ahead กับ Pace behind ต่างกันยังไง

Pace ahead คือ OTB ปัจจุบันสูงกว่า STLY (จองเร็วกว่าปีก่อน) มักเป็นสัญญาณให้พิจารณาขึ้น BAR และจำกัด discount ส่วน Pace behind คือ OTB ต่ำกว่า STLY (จองช้ากว่า) ต้องวิเคราะห์ว่าเป็นปัญหาราคา visibility หรือ Demand ตลาดเปลี่ยน

  • ahead = สูงกว่า STLY
  • behind = ต่ำกว่า STLY
  • ahead พิจารณาขึ้นราคา
  • behind ต้องวิเคราะห์สาเหตุ
22Pace behind ควรทำยังไง

อย่าเพิ่งลดราคาทันที วิเคราะห์ก่อนว่าเป็นปัญหาอะไร: ราคาสูงเกิน (เทียบ comp set), visibility ต่ำ (ranking OTA, content), หรือ Demand ตลาดหดจริง (ทั้งตลาด behind) ถ้าเป็นราคาค่อยปรับ ถ้าเป็น visibility แก้ที่ distribution ถ้าตลาดหดอาจต้องยอมรับและเน้น Segment อื่น

  • อย่าเพิ่งลดราคา
  • วิเคราะห์ 3 สาเหตุ
  • แก้ตรงต้นตอ
  • ตลาดหดต้องปรับกลยุทธ์
23booking curve diverge ควรทำยังไง

ขึ้นกับทิศทาง ahead of Pace ให้พิจารณาขึ้น BAR จำกัด discount, behind ให้วิเคราะห์ราคา/visibility/Demand, เร่งขึ้นกะทันหันให้เช็ค event ที่พลาด คู่แข่ง sell-out หรือ rate error, ชะลอกะทันหันให้เช็ค cancellation wave คู่แข่งลดราคา หรือ disruption ภายนอก

  • ahead ขึ้นราคา
  • behind วิเคราะห์
  • เร่งเช็ค event/error
  • ชะลอเช็ค cancellation/disruption
24Wash Factor คืออะไรในการ Forecast

Wash Factor คือการปรับลด Forecast สำหรับ group ที่ block ห้องเกินจริง group มัก Pickup ห้องน้อยกว่าที่ block ไว้ การใช้ wash จากประวัติแต่ละประเภท group ทำให้ Forecast ไม่สูงเกินจริง เช่น group block 50 ห้อง wash 30% นับจริงราว 35 ห้อง

  • นิยาม
  • ปรับลดสำหรับ group
  • group block เกินจริง
  • ใช้ประวัติแต่ละประเภท
25materialization factor คืออะไร

materialization factor คือสัดส่วนที่ tentative group คาดว่าจะ confirm จริง ใช้ถ่วงน้ำหนัก tentative group ใน Forecast แทนการนับเต็มหรือไม่นับเลย เช่น tentative 40 ห้องที่ materialization 60% นับ 24 ห้อง อิงประวัติ conversion ของ group แต่ละประเภท

  • นิยาม
  • สัดส่วน tentative ที่ confirm
  • ถ่วงน้ำหนักใน Forecast
  • อิงประวัติ conversion
26tentative กับ definite group ต่างกันยังไงในการ Forecast

definite group คือ group ที่ยืนยันแล้ว นับเต็มใน Forecast (ปรับด้วย wash) ส่วน tentative group ยังไม่ยืนยัน ต้องถ่วงด้วย materialization factor ตามโอกาส confirm การนับ tentative เต็มทำให้ Forecast สูงเกิน การไม่นับเลยทำให้ต่ำเกิน

  • definite นับเต็มปรับ wash
  • tentative ถ่วง materialization
  • นับเต็มสูงเกิน
  • ไม่นับต่ำเกิน
27pre-Forecast checklist มีอะไรบ้าง

ก่อนดึง OTB ตรวจว่า Segmentation ถูกต้องทุกการจอง, group block definite รีวิวและ size ถูก, tentative group ใส่ materialization, ไม่มีการจองซ้ำ, ไม่มี pending reservation นอกระบบ, oversold บน expected cancellation ถูก net out และทุกการจองแนบ rate code ถูก

  • ตรวจ Segmentation
  • รีวิว group blocks
  • เช็ค duplicate และ pending
  • แนบ rate code ถูก
28ทำไมต้องตรวจข้อมูลก่อน Forecast

เพราะ "garbage in, garbage out" ถ้า OTB มี Segmentation ผิด, การจองซ้ำ, group size ผิด หรือ rate code ผิด Forecast จะเพี้ยนตั้งแต่ฐาน ไม่ว่าจะใช้วิธีคำนวณดีแค่ไหน การตรวจ pre-Forecast checklist จึงสำคัญกว่าความซับซ้อนของโมเดล

  • garbage in garbage out
  • ข้อมูลผิดทำ Forecast เพี้ยน
  • ฐานสำคัญกว่าโมเดล
  • ป้องกันด้วย checklist
29Forecast ทำได้บ่อยแค่ไหน

rolling Forecast ควรอัปเดตอย่างน้อยรายสัปดาห์ใน yield meeting และทบทวน OTB/Pace รายวันสำหรับ 30-90 วันข้างหน้า horizon ใกล้อัปเดตถี่กว่า (tactical รายวัน), horizon ไกล (budget) ทบทวนรายเดือน/ไตรมาส Demand calendar อัปเดตเมื่อมีข้อมูลใหม่

  • rolling รายสัปดาห์
  • daily สำหรับใกล้วัน
  • budget รายเดือน/ไตรมาส
  • อัปเดตเมื่อมีข้อมูล
30Forecast ขับเคลื่อนการวางแผนแผนกอื่นยังไง

forecasted Occupancy และ Segment mix ขับเคลื่อน housekeeping staffing และต้นทุนของใช้, F&B breakfast covers และ capacity ร้านอาหาร, front desk staffing สำหรับ arrival/departure และ projection การเงินรายเดือน Forecast ที่ดีจึงไม่ใช่แค่เครื่องมือ revenue แต่เป็นเครื่องมือทั้งโรงแรม

  • housekeeping staffing
  • F&B covers
  • front desk staffing
  • financial projection
31Forecast Occupancy กับ Forecast revenue ต่างกันยังไง

Forecast Occupancy คาดการณ์จำนวน/สัดส่วนห้องที่จะขาย ส่วน Forecast revenue คาดการณ์รายได้ (ต้องคูณด้วย ADR ที่คาด) การ Forecast Occupancy แม่นแต่ ADR ผิดยังทำให้ revenue Forecast เพี้ยน จึงต้อง Forecast ทั้ง Occupancy และ ADR/mix ควบคู่กัน

  • Occupancy = จำนวนห้อง
  • revenue = ต้องมี ADR
  • Occupancy แม่นไม่พอ
  • Forecast ทั้งสองควบคู่
32Forecast ADR ยังไง

Forecast ADR จากการคาด mix ของ Segment และ channel ที่จะเข้ามา (แต่ละกลุ่ม ADR ต่างกัน) บวกกับ BAR level ที่วางแผนจะขายตาม Pace ถ้า mix เอียงไปทาง discount/wholesale ADR Forecast ควรต่ำลง ถ้าเอียงไป BAR/direct ควรสูงขึ้น ใช้ segmented Pickup ช่วย

  • คาด mix Segment/channel
  • อิง BAR level ที่วางแผน
  • mix เอียงกระทบ ADR
  • ใช้ segmented Pickup
33Forecast สำหรับ serviced apartment ต่างยังไง

ต้องใช้ metric เพิ่ม ได้แก่ ALOS (มัก 7-30+ วัน), stay-through rate (% ที่ขยายเกินการจองแรก), churn rate (อัตราออกรายเดือน) และแยก monthly Occupancy กับ nightly Occupancy เพราะ extended stay มีโปรไฟล์รายได้และ Pickup pattern ต่างจากโรงแรม transient

  • metric เพิ่ม
  • ALOS ยาว
  • stay-through และ churn
  • monthly vs nightly
34Forecast ช่วง Demand ผันผวนสูงทำยังไง

พึ่ง OTB และ Pace มากกว่าค่าเฉลี่ยประวัติ (ที่อาจไม่สะท้อนสถานการณ์ใหม่), อัปเดตถี่ขึ้น, ใช้ scenario Forecast (best/base/worst case), ติดตาม Demand exception และ event ใกล้ชิด และยอมรับว่า horizon ไกลจะแม่นน้อยลง เน้นความเร็วในการปรับมากกว่าความแม่นครั้งเดียว

  • พึ่ง OTB/Pace มากขึ้น
  • อัปเดตถี่
  • ใช้ scenario
  • เน้นปรับเร็วกว่าแม่นครั้งเดียว
35scenario Forecast คืออะไร

scenario Forecast คือการทำ Forecast หลายกรณี (best case, base case, worst case) แทนตัวเลขเดียว เพื่อเตรียมแผนรับแต่ละสถานการณ์ มีประโยชน์มากในช่วง Demand ไม่แน่นอนหรือมีเหตุการณ์ภายนอก ช่วยให้ทีมเตรียม trigger ทั้งทางขึ้นและทางลงไว้ล่วงหน้า

  • นิยาม
  • หลายกรณีแทนตัวเลขเดียว
  • เตรียมแผนแต่ละสถานการณ์
  • ดีในช่วงไม่แน่นอน
36historical data ที่ต้องใช้ Forecast มีอะไรบ้าง

ต้องใช้ RevPAR/Occupancy/ADR รายวันย้อนหลัง, Pickup pattern ตามวันในสัปดาห์และ lead time, อัตรา cancellation/No-show ตาม Segment, group wash ตามประเภท, LOS pattern และ booking window ตาม Segment ยิ่งข้อมูลละเอียดและสะอาด Forecast ยิ่งแม่น

  • KPI รายวันย้อนหลัง
  • Pickup pattern
  • cancellation และ wash
  • LOS และ booking window
37ไม่มีข้อมูลประวัติจะ Forecast ยังไง

โรงแรมใหม่หรือไม่มีข้อมูลให้เริ่มจาก market data และ comp set, Demand calendar จาก event/วันหยุดตลาด, benchmark ตลาด (ช่วง Occupancy/ADR ตามระดับโรงแรม) แล้วเก็บ OTB/Pace ของตัวเองเร็วที่สุด ช่วงแรกพึ่ง market intelligence มากกว่า แล้วค่อยเปลี่ยนมาพึ่งข้อมูลตัวเองเมื่อสะสมพอ

  • เริ่มจาก market/comp set
  • Demand calendar ตลาด
  • benchmark ตลาด
  • เก็บข้อมูลตัวเองเร็ว
38Forecast กับ budget ต่างกันยังไง

budget คือเป้าหมายรายได้ที่ตั้งไว้ล่วงหน้า (มักทำปีละครั้ง) เป็นตัววัดความสำเร็จ ส่วน Forecast คือการคาดการณ์ที่ปรับตามข้อมูลจริงต่อเนื่อง (rolling) สะท้อนสิ่งที่น่าจะเกิดจริง budget ไม่เปลี่ยน Forecast เปลี่ยนตลอด ใช้เทียบกันดู variance

  • budget = เป้าตั้งล่วงหน้า
  • Forecast = คาดการณ์ที่ปรับต่อเนื่อง
  • budget นิ่ง Forecast เปลี่ยน
  • เทียบกันดู variance
39Forecast กับ actual ต่างกันมากควรทำยังไง

decompose variance ว่ามาจาก room nights หรือ ADR, แยกตามวันในสัปดาห์และ Segment เพื่อหา pattern ที่ผิดเชิงระบบ (เช่น ประเมิน corporate weekday สูงเกินตลอด), ตรวจว่าเป็น event ที่พลาด, cancellation wave หรือ data ผิด แล้วนำสิ่งที่เรียนรู้ปรับ assumption รอบถัดไป

  • decompose room nights vs ADR
  • แยก day/Segment
  • หา pattern เชิงระบบ
  • ปรับ assumption รอบถัดไป
40overbooking ตั้งจาก Forecast ยังไง

ตั้งระดับ overbooking จาก Forecast ของ cancellation และ No-show ตามอัตราประวัติของแต่ละ Segment ในวันคล้ายกัน เป้าคือให้โรงแรมเต็มพอดีหลัง cancellation/No-show จริง overbooking มากไปเสี่ยง walk แขก (ต้นทุนและชื่อเสียง) น้อยไปเสีย Occupancy

  • อิง Forecast cancellation/No-show
  • ใช้อัตราประวัติ Segment
  • เป้าเต็มพอดี
  • สมดุลความเสี่ยง walk
41No-show rate กับ cancellation rate ใช้ Forecast ยังไง

ใช้ลด OTB ให้เหลือ Forecast จริง (expected arrivals) และตั้งระดับ overbooking แต่ละ Segment มีอัตราต่างกัน (OTA non-refundable No-show ต่ำ, corporate flexible cancellation สูง) จึงต้องใช้อัตราแยก Segment ไม่ใช่ค่าเฉลี่ยรวม เพื่อให้แม่น

  • ลด OTB เหลือ expected
  • ตั้ง overbooking
  • แต่ละ Segment ต่างกัน
  • ใช้อัตราแยกไม่ใช่รวม
42Forecast ช่วยตั้งราคายังไง

Forecast Occupancy เทียบ threshold เป็นตัว trigger ราคา เช่น Forecast > 85% ใน 14 วัน ให้ขึ้น BAR และปิด discount, Forecast < 50% ใน 7 วัน ให้เปิด flash/opaque การตั้งราคาที่ดีจึงเริ่มจาก Forecast ที่แม่น ไม่ใช่เดาหรือ react ทีหลัง

  • Forecast เป็น trigger ราคา
  • threshold ขึ้น/ลงราคา
  • ราคาเริ่มจาก Forecast
  • ไม่ใช่ react
43Forecast ช่วยจัดการ inventory ยังไง

Forecast บอกว่าวันไหน Demand จะเกิน capacity (ใส่ MLOS/CTA, ปิด wholesale), วันไหนจะเหลือห้อง (เปิด discount/opaque) และช่วยทำ Displacement analysis สำหรับ group การจัดการ inventory ที่ดีพึ่ง Forecast ที่แยก Segment และมองหลาย horizon

  • ระบุวันเกิน/เหลือ capacity
  • ตั้ง restriction ตาม Forecast
  • ทำ Displacement
  • พึ่ง segmented Forecast
44moving average ใช้ Forecast โรงแรมยังไง

moving average ใช้หาค่าเฉลี่ย Demand ของวันคล้ายกันในอดีต (เช่น เฉลี่ย 5 วันพุธล่าสุด) เป็นฐานประมาณ Pickup ที่จะเข้ามา แต่ moving average เพียงอย่างเดียวไม่จับ trend หรือ event ที่เปลี่ยน จึงต้องใช้คู่กับ OTB, Pace และ Demand calendar ไม่ใช่พึ่งอย่างเดียว

  • หาค่าเฉลี่ยวันคล้ายกัน
  • ฐานประมาณ Pickup
  • ไม่จับ trend/event
  • ใช้คู่กับ OTB/Pace
45seasonality กระทบ Forecast ยังไง

seasonality (high/low/shoulder season) ทำให้ Demand pattern ต่างกันมากตามช่วงปี การ Forecast ต้องเทียบกับวันคล้ายกันใน season เดียวกันปีก่อน ไม่ใช่เฉลี่ยทั้งปี ในไทย high season (พ.ย.-ก.พ.) กับ low season (พ.ค.-ต.ค.) มี pattern คนละแบบ ต้องแยกฐานเทียบ

  • Demand pattern ต่างตาม season
  • เทียบ season เดียวกัน
  • ไม่เฉลี่ยทั้งปี
  • ไทย high/low ต่างชัด
46day of week pattern กระทบ Forecast ยังไง

แต่ละวันในสัปดาห์มี Demand pattern ต่างกัน (resort weekend สูง, corporate weekday สูง) การ Forecast และเทียบ Pace ต้องทำตาม day-type ไม่ใช่เฉลี่ยทั้งสัปดาห์ การ plot booking curve ควรเทียบกับวันเดียวกันในอดีต (พุธเทียบพุธ) เพื่อความแม่น

  • แต่ละวันต่างกัน
  • resort vs corporate
  • Forecast ตาม day-type
  • เทียบวันเดียวกัน
47lead time กระทบ Forecast ยังไง

lead time (booking window) บอกว่าแต่ละ Segment จองล่วงหน้านานแค่ไหน ใช้กำหนดว่า ณ จุดเวลานี้ควรมี OTB เท่าไรและจะ Pickup เพิ่มอีกเท่าไร Segment lead time ยาว (wholesale) สร้าง OTB เร็ว ส่วน lead time สั้น (OTA, last-minute) ยังเหลือ Pickup อีกมากแม้ใกล้วัน

  • บอกระยะจองล่วงหน้า
  • กำหนด OTB ที่ควรมี
  • lead time ยาวสร้างเร็ว
  • lead time สั้นเหลือ Pickup
48Forecast ระยะสั้น (0-7 วัน) ทำยังไง

พึ่ง OTB เป็นหลัก (เป็นสัดส่วนใหญ่แล้ว) บวก Pickup ที่เหลือน้อยจากวันคล้ายกัน ลบ cancellation/No-show ที่คาด ปรับด้วย Walk-in และ last-minute pattern เป้าความแม่น ±2% เพราะใช้ตัดสิน rate และ inventory นาทีสุดท้าย รวมถึง staffing วันนั้น

  • พึ่ง OTB เป็นหลัก
  • Pickup เหลือน้อย
  • ปรับ Walk-in/last-minute
  • เป้า ±2%
49Forecast ระยะยาว (90+ วัน) ทำยังไง

พึ่ง Demand calendar, ประวัติ season เดียวกัน, group pipeline (definite + tentative ถ่วง materialization) และ benchmark ตลาด มากกว่า OTB (ที่ยังน้อย) เป้าความแม่นต่ำกว่า (±12%) ใช้สำหรับ budget, hiring, contract และวางกลยุทธ์ promotion/channel ไม่ใช่ตัดสินราคารายวัน

  • พึ่ง Demand calendar/ประวัติ
  • group pipeline
  • OTB ยังน้อย
  • เป้า ±12% สำหรับ planning
50group pipeline ใช้ Forecast ยังไง

นับ definite group เต็ม (ปรับ wash) และ tentative group ถ่วงด้วย materialization factor เข้า Forecast โดยเฉพาะ horizon ไกลที่ transient OTB ยังน้อย group pipeline เป็นส่วนสำคัญ ติดตาม conversion ratio ตามประเภทและเดือนเพื่อประเมิน tentative ให้แม่น

  • definite เต็มปรับ wash
  • tentative ถ่วง materialization
  • สำคัญใน horizon ไกล
  • ติดตาม conversion ratio
51group conversion ratio คืออะไร

group conversion ratio คือสัดส่วน group ที่ปิดได้ต่อ lead ที่ได้รับ (groups won / leads received) แยกตามประเภทและเดือนที่จองสำหรับเดือนเข้าพัก ใช้ประเมิน materialization ของ pipeline และตัดสินว่าควรยืนราคา (pipeline แข็ง) หรือเจรจา (pipeline อ่อน)

  • นิยาม
  • won หารด้วย leads
  • แยกประเภทและเดือน
  • ใช้ประเมิน pipeline
52Forecast accuracy ต่ำเกิดจากอะไรได้บ้าง

เกิดได้จาก Segmentation ผิด, group size/wash ประเมินผิด, การจองซ้ำหรือ pending นอกระบบ, rate code ผิด, ไม่ได้ใส่ event ใน Demand calendar, ใช้ค่าเฉลี่ยรวมแทนแยก Segment/day-type หรือไม่อัปเดตตาม Pace จริง ส่วนใหญ่เป็นปัญหาข้อมูลและกระบวนการ ไม่ใช่โมเดล

  • Segmentation/group ผิด
  • data ซ้ำ/นอกระบบ
  • พลาด event
  • ไม่แยก Segment/ไม่อัปเดต
53ปรับปรุง Forecast accuracy ยังไง

ทำ pre-Forecast checklist ทุกครั้ง, แยก Forecast ตาม Segment และ day-type, decompose variance ทุกรอบเพื่อเรียนรู้ (room nights vs ADR), อัปเดตตาม Pace จริงรายสัปดาห์, ใส่ event ใน Demand calendar ครบ และใช้ booking curve เทียบ Pace อย่างสม่ำเสมอ ความแม่นมาจากวินัยกระบวนการ

  • ทำ checklist
  • แยก Segment/day-type
  • decompose variance
  • อัปเดตและใช้ booking curve
54Forecast Demand exception คืออะไร

Demand exception คือ Segment ที่ทำตัวนอก pattern ปกติ เช่น corporate สูงผิดปกติในวันหยุด หรือ tour operator cancellation wave การบันทึก exception ใน Demand calendar ช่วยอธิบาย variance และเตือนว่าปีหน้าเหตุการณ์นี้จะซ้ำหรือไม่ ป้องกันการ Forecast ผิดซ้ำ

  • นิยาม
  • Segment นอก pattern
  • บันทึกใน Demand calendar
  • ป้องกันผิดซ้ำ
55event ที่ไม่ซ้ำปีก่อนกระทบ Forecast ยังไง

event ใหม่ (ที่ปีก่อนไม่มี) ทำให้การเทียบ STLY ตรงๆ ผิดพลาด เพราะปีก่อนไม่มี Demand นั้น ต้องปรับ Forecast ขึ้นด้วย judgment และ market intelligence (ขนาดงาน, ผู้เข้าร่วมคาดการณ์, คู่แข่ง sell-out) บันทึกใน Demand calendar เพื่อเทียบปีถัดไป

  • STLY เทียบตรงผิด
  • ปรับด้วย judgment
  • ใช้ market intelligence
  • บันทึกเทียบปีหน้า
56Forecast ใช้คนหรือใช้ระบบ (RMS) ดีกว่ากัน

RMS ประมวลข้อมูลปริมาณมากและเร็ว เหมาะกับ pattern ปกติและการปรับถี่ ส่วนคนเก่งกว่าในการจับ event ใหม่ การเปลี่ยนแปลงตลาด และ judgment เชิงบริบท ทางที่ดีคือใช้ RMS เป็นฐานแล้วคนตีความและ override เมื่อมีข้อมูลที่ระบบไม่รู้ ไม่ใช่เลือกอย่างใดอย่างหนึ่ง

  • RMS เร็วจับ pattern ปกติ
  • คนจับ event/บริบท
  • ใช้ RMS เป็นฐาน
  • คน override เมื่อจำเป็น
57Forecast ในตลาดไทยมีความท้าทายอะไร

ความท้าทายได้แก่ Source Market หลากหลายที่วันหยุดต่างกัน (จีน Golden Week, รัสเซีย, อินเดีย), wholesale/FIT ที่ lead time ยาวและ wash สูง, domestic ที่จองนาทีสุดท้ายผ่าน LINE/social, ฤดูกาลที่สวิงแรง และ event ท้องถิ่น (สงกรานต์ ลอยกระทง) ต้องใช้ Demand calendar ที่ละเอียดตาม feeder market

  • Source Market หลากหลาย
  • wholesale lead time ยาว
  • domestic จองนาทีสุดท้าย
  • ฤดูกาลสวิงแรง
58Forecast ควรมองกี่วันข้างหน้า

มองหลาย horizon พร้อมกัน 0-7 วัน (tactical รายวัน), 8-30 วัน (operational), 31-90 วัน (strategic) และ 91-365 วัน (budget) ระยะ 30-90 วันเป็นช่วงสำคัญที่สุดสำหรับการตัดสินใจราคาและ channel เพราะยังปรับได้ทันแต่ใกล้พอจะมี OTB เป็นสัญญาณ

  • มองหลาย horizon
  • แต่ละช่วงใช้ต่างกัน
  • 30-90 วันสำคัญสุด
  • ปรับได้ทันและมีสัญญาณ
59Forecast เชื่อมกับ Pace report ยังไง

Pace report (OTB เทียบ STLY) เป็น input หลักของ Forecast ใช้บอกว่าวันนั้นนำหรือตามปีก่อนเท่าไร แล้วประมาณ remaining Pickup จาก pattern booking curve การรวม Demand calendar เข้า OTB และ Pickup summary ให้ภาพ forward view ที่สมบูรณ์สำหรับตัดสินใจ

  • Pace เป็น input Forecast
  • บอกนำ/ตาม STLY
  • ประมาณ remaining Pickup
  • รวม Demand calendar

Spread the love
Scroll to Top
English ↗