ภาพประกอบบทความ ข้อมูลโรงแรม 8 อย่างที่ต้องเก็บก่อนคิดเรื่อง AI · Gusornhai

GUSORNHAI
Data Foundation
Data Foundation

ข้อมูลโรงแรม 8 อย่างที่ต้องเก็บให้ครบตั้งแต่วันนี้ — ก่อนคิดเรื่อง AI

AI pricing tool ราคาแพง ซื้อมาแล้ว แต่ recommendation แปลกๆ ทุกครั้ง? ส่วนใหญ่ปัญหาไม่ได้อยู่ที่ตัว AI — ปัญหาอยู่ที่ข้อมูลที่ป้อนเข้าไป

โดย BoydWee

คำตอบสั้นๆ

ข้อมูล 8 ประเภทที่โรงแรมควรเก็บอย่างสม่ำเสมอเพื่อรองรับ Revenue Management และ AI ได้แก่: (1) Booking Pace / OTB, (2) Market Segment, (3) Source Market, (4) Channel Mix, (5) Length of Stay, (6) Denial และ Regret, (7) Rate History, และ (8) Reason Code สำหรับ cancellation และ No-show ข้อมูลทั้ง 8 ประเภทนี้ต้องเก็บอย่างสม่ำเสมอ ถูกต้อง และมี historical depth อย่างน้อย 2 ปีขึ้นไปจึงจะใช้งานได้จริง

ทำไมข้อมูลถึงสำคัญกว่า AI

ก่อนไปดู checklist ต้องเข้าใจก่อนว่าโรงแรมส่วนใหญ่ลงทุนผิดลำดับ

หลายโรงแรมซื้อ RMS (Revenue Management System) หรือ AI pricing tool มาก่อน แล้วค่อยมาตั้งคำถามว่า “ทำไม recommendation ไม่ตรงกับความเป็นจริง?” คำตอบมักจะเหมือนกันเสมอ: ข้อมูลใน PMS ไม่สะอาด, Segment ถูก code ผิด, channel ไม่ได้แยกอย่างถูกต้อง

AI เก่งในการ “หา pattern จากข้อมูล” แต่มันหา pattern ที่ถูกต้องได้ก็ต่อเมื่อข้อมูลที่ให้มาสะท้อนความเป็นจริง ถ้าข้อมูลมีช่องโหว่หรือถูกบันทึกผิด AI จะเรียนรู้ pattern ที่ผิดนั้นและนำไปทำนายต่อ

ฐานข้อมูลสะอาดไม่ได้เป็นแค่ “nice to have” — มันคือเงื่อนไขขั้นต่ำของ Revenue Management ที่ใช้งานได้จริง

Checklist ข้อมูลโรงแรม 8 ประเภท

1

Booking Pace / OTB (On-The-Books)

เก็บอะไร: จำนวนห้องที่ถูก book แล้วสำหรับแต่ละวันในอนาคต เปรียบเทียบกับช่วงเวลาเดียวกันของปีที่แล้ว (same time last year / STLY)

ทำไมสำคัญ: Booking Pace บอกว่า Demand “มาเร็วหรือมาช้า” กว่าปกติ ถ้า OTB ณ วันนี้สูงกว่า STLY 20% อาจถึงเวลาปรับราคาขึ้น ถ้าต่ำกว่าอาจต้องเปิด promotion เพิ่ม

ปัญหาที่พบบ่อย: ไม่ได้เก็บ snapshot OTB รายวัน ทำให้ดูได้แค่ภาพปัจจุบัน ไม่เห็น trend ของการ book

อ่านเพิ่มเติม: OTB, Pace, Pickup — ใช้ยังไงให้ได้ประโยชน์จริง

2

Market Segment

เก็บอะไร: แหล่งที่มาของรายได้จำแนกตามประเภทลูกค้า เช่น FIT (Free Individual Traveler), Corporate, Group, Government, OTA leisure, Wholesale

ทำไมสำคัญ: แต่ละ Segment มี booking window, price sensitivity, และ cancellation behavior ต่างกัน โรงแรมที่รู้ว่า Segment ไหนทำ RevPAR ให้สูงที่สุด สามารถ allocate ห้องและกำหนด strategy ได้ตรงเป้า

ปัญหาที่พบบ่อย: Segment code ใน PMS ถูกตั้งผิดตั้งแต่แรก หรือ front office ไม่ได้รับการ train ให้ใส่ข้อมูลถูก ทำให้ข้อมูลสะสมผิดมาหลายปี

อ่านเพิ่มเติม: Market Segmentation สำหรับโรงแรม

3

Source Market

เก็บอะไร: ประเทศหรือภูมิภาคต้นทางของผู้เข้าพัก เช่น Thai domestic, China, Russia, Western Europe, GCC

ทำไมสำคัญ: Source Market บอก pattern การจอง, ช่วงเวลาที่เดินทาง, และ average spend ต่างกันอย่างชัดเจน ตัวอย่างประกอบ: โรงแรมรีสอร์ทที่รู้ว่า Russian guests จองล่วงหน้า 45 วันและพักเฉลี่ย 7 คืน สามารถวางแผน inventory ได้ดีกว่าโรงแรมที่ไม่มีข้อมูลนี้

ปัญหาที่พบบ่อย: ไม่ได้ capture nationality ตั้งแต่ reservation step หรือ capture ได้แต่ไม่ได้ดึงมาวิเคราะห์

4

Channel Mix

เก็บอะไร: สัดส่วน booking จากแต่ละ channel — Direct (website, Walk-in, phone), OTA (Booking.com, Agoda, Expedia ฯลฯ), GDS, Wholesale/Bedbank, Corporate Direct

ทำไมสำคัญ: Channel ต่างกัน = cost of acquisition ต่างกัน OTA มี commission 15-20% Direct Booking ไม่มี ถ้าไม่รู้ Channel Mix จะไม่รู้ว่า revenue จริงๆ หลัง cost แล้วเหลือเท่าไร

ปัญหาที่พบบ่อย: รวม OTA ทุกเจ้าไว้ใน bucket เดียวแทนที่จะแยกรายช่อง ทำให้ไม่รู้ว่าช่องไหน perform ดีหรือแย่กว่ากัน

5

Length of Stay (LOS)

เก็บอะไร: จำนวนคืนที่พักเฉลี่ยต่อ booking จำแนกตาม Segment, channel, และช่วงเวลา

ทำไมสำคัญ: LOS กระทบโดยตรงต่อ revenue optimization โรงแรมที่มีข้อมูล LOS สามารถตั้ง Minimum LOS restriction ได้อย่างมีหลักการ เช่น ช่วง peak Demand กำหนด minimum 3 คืนเพื่อไม่ให้ถูกเติมด้วย single-night booking ที่บล็อกวัน high-Demand

ปัญหาที่พบบ่อย: เก็บแค่ average LOS รวม โดยไม่แยก Segment หรือ channel ทำให้ใช้ประโยชน์ได้จำกัด

6

Denial และ Regret Data

เก็บอะไร:

  • Denial = ครั้งที่โรงแรมไม่มีห้องให้ขาย (sold out หรือ close rate) แต่มีคนมาขอ
  • Regret = ครั้งที่ลูกค้าปฏิเสธราคาที่เสนอ (ราคาสูงไปในสายตาลูกค้า)

ทำไมสำคัญ: นี่คือ “Demand ที่มองไม่เห็น” — Demand ที่มีจริงแต่ไม่ถูกนับใน booking data ถ้าไม่มีข้อมูลนี้ Forecast จะ underestimate Demand จริงเสมอ

ปัญหาที่พบบ่อย: โรงแรมส่วนใหญ่ไม่ได้เก็บข้อมูลนี้เลย เพราะต้องตั้งค่าใน CRS หรือ PMS อย่างตั้งใจ ข้อมูลนี้จะไม่ถูกเก็บโดยอัตโนมัติ

อ่านเพิ่มเติม: Hotel Demand Forecast คืออะไร

7

Rate History

เก็บอะไร: ราคาที่ขายจริง (actual sold rate) แยกตาม date, Segment, channel, room type — ย้อนหลังอย่างน้อย 2 ปี

ทำไมสำคัญ: Rate history คือ “memory” ของ Revenue Manager เมื่อเจอ event หรือ season เดิม เราต้องการรู้ว่าปีที่แล้วขายที่เท่าไร แล้วผลลัพธ์เป็นอย่างไร ไม่มีข้อมูลนี้ = ตัดสินใจด้วย intuition ล้วนๆ

ปัญหาที่พบบ่อย: เก็บแค่ BAR (Best Available Rate) แต่ไม่เก็บ actual sold rate ที่รวม discount, package, และ negotiated rate

8

Reason Code สำหรับ Cancellation และ No-show

เก็บอะไร: เหตุผลที่ลูกค้า cancel หรือ No-show — เช่น price too high, found cheaper alternative, change of travel plans, weather/force majeure

ทำไมสำคัญ: Pattern ของ cancellation บอกปัญหาที่ซ่อนอยู่ ตัวอย่างประกอบ: ถ้า cancel rate สูงผิดปกติในช่วง 7 วันก่อน check-in และ Reason Code ส่วนใหญ่คือ “found cheaper rate” อาจหมายความว่า rate strategy มีปัญหา

ปัญหาที่พบบ่อย: front office ไม่ได้บันทึก Reason Code อย่างจริงจัง หรือ system ไม่มี dropdown ให้เลือก ทำให้ข้อมูลส่วนนี้ว่างเปล่า

ตาราง Summary: Data Checklist 8 ประเภท

#ประเภทข้อมูลใช้ทำอะไรHistorical Depth ที่แนะนำ
1Booking Pace / OTBติด Pace, วาง pricing strategy2+ ปี (snapshot รายวัน)
2Market Segmentแยก strategy ตามประเภทลูกค้า2+ ปี
3Source Marketวาง channel strategy ตามต้นทาง2+ ปี
4Channel Mixคำนวณ net revenue หลัง cost2+ ปี
5Length of Stayตั้ง LOS restrictions2+ ปี
6Denial / Regretวัด unconstrained Demandเก็บตั้งแต่วันนี้
7Rate Historyเปรียบเทียบ rate ปีต่อปี2+ ปี
8Cancellation Reason Codeวิเคราะห์ cancel patternเก็บตั้งแต่วันนี้

เริ่มต้นจากตรงไหนถ้าข้อมูลยังไม่ครบ

ไม่ต้องรอให้ครบ 100% ก่อนเริ่ม ให้ทำ 3 ขั้นตอนนี้:

ขั้นที่ 1 — Audit ข้อมูลใน PMS ที่มีอยู่แล้ว ดูว่า field ไหนถูกกรอกสม่ำเสมอ field ไหนว่างเปล่าหรือผิด เริ่มจากการรู้ว่าตัวเองอยู่ตรงไหน

ขั้นที่ 2 — Fix Segment และ channel code ก่อน สองข้อมูลนี้มีผลต่อ report ทุกอย่าง ถ้า Segment ผิดหรือ channel รวมกันหมด ข้อมูลอื่นก็จะ misleading ตาม

ขั้นที่ 3 — เริ่มเก็บ Denial/Regret และ Reason Code ตั้งแต่วันนี้ สองอย่างนี้ต้องตั้งใจเปิด — ไม่ได้เกิดขึ้นเอง แต่ 6 เดือนข้างหน้าคุณจะมี data set ที่มีค่ามาก

ข้อมูลสะอาดคือการลงทุนที่ compound ไปเรื่อยๆ ยิ่งเริ่มเร็ว ยิ่งมีฐานข้อมูลที่แข็งแกร่งกว่าในอีก 2-3 ปีข้างหน้า อ่านเพิ่มเติม: ทำไม data สะอาดคือฐานของ AI ทุกตัว · Hotel Demand Forecast คืออะไร · Market Segmentation สำหรับโรงแรม

คำถามที่พบบ่อย

โรงแรมเล็กที่มีแค่ 30 ห้องต้องเก็บข้อมูลครบ 8 อย่างไหม?
ขนาดโรงแรมไม่ได้เปลี่ยน logic ของข้อมูล แต่เปลี่ยนลำดับความสำคัญ โรงแรมเล็กควร focus ที่ Booking Pace/OTB, Market Segment, Channel Mix และ Cancellation Reason Code ก่อน — 4 อย่างนี้ให้ภาพที่ชัดพอสำหรับการตัดสินใจ pricing ในชีวิตประจำวัน ส่วน Denial/Regret อาจติดตามแบบ manual ก่อนถ้า system ยังไม่รองรับ
ถ้า PMS เก่าและ export data ได้จำกัด ควรทำอย่างไร?
เริ่มจาก export ทุกอย่างที่ PMS ให้ได้ แม้แต่ raw data แบบ CSV แล้วนำมาจัดการใน Excel หรือ Google Sheets ก็ยังดีกว่าไม่มีข้อมูลเลย ข้อสำคัญคือต้องทำ snapshot รายสัปดาห์หรือรายเดือน อย่าพึ่งพาแค่ live data ที่เห็นหน้าจอ เพราะข้อมูลเหล่านั้นจะถูก overwrite เมื่อ status เปลี่ยน
Denial และ Regret data ต้องเก็บจาก system ไหน?
Denial data มักมาจาก CRS (Central Reservation System) หรือ Channel Manager ที่บันทึก search ที่ไม่มีห้องว่าง ส่วน Regret data มาจาก Booking Engine ที่บันทึกว่าลูกค้า search แล้วออกไปโดยไม่ book ถ้า system ปัจจุบันไม่รองรับ สามารถเก็บ Regret แบบ proxy ได้จาก abandoned booking data ใน analytics ของ Booking Engine
Spread the love
Scroll to Top
English ↗