Segment Tag ที่ Tag มั่ววันนี้ = Forecast ที่เชื่อไม่ได้ในอีก 6 เดือน
Segment tagging ที่ไม่สม่ำเสมอคือตัวการที่ทำให้ Forecast เพี้ยน pricing เดา Channel Mix อ่านไม่ออก — โดยที่คุณไม่รู้ตัวนานหลายเดือน
โดย BoydWee
Segment tagging ที่ไม่สม่ำเสมอ คือตัวการที่ทำให้ Forecast เพี้ยน pricing เดา Channel Mix อ่านไม่ออก — โดยที่คุณไม่รู้ตัวนานหลายเดือน วิธีแก้ไม่ใช่ซื้อ RMS แพงขึ้น แต่เริ่มจากการตั้ง tagging convention ที่ชัดเจน กำหนดเจ้าของ tag และฝึก discipline ให้ทีมตั้งแต่วันแรกที่รับ booking
ปัญหาไม่ได้อยู่ที่ Segment — แต่อยู่ที่ความสม่ำเสมอของการ tag
Revenue manager ส่วนใหญ่รู้ดีว่า Segment คืออะไร รู้ว่า leisure กับ corporate ต่างกัน รู้ว่า OTA กับ Direct Booking มี margin ต่างกัน แต่สิ่งที่มักพลาดคือ วินัยในการ tag — ว่าใครเป็นคน tag, tag ตอนไหน, ใช้ชื่ออะไร และสม่ำเสมอแค่ไหน
ลองนึกภาพโรงแรม 80 ห้องที่มี front office agent 3 คน: Agent A tag กลุ่มทัวร์ญี่ปุ่นว่า “GROUP-INBOUND” — Agent B tag กลุ่มเดียวกันว่า “LEISURE-GROUP” — Agent C บางทีลืม tag ปล่อยให้ default เป็น “TRANSIENT” ห้าเดือนถัดมา Demand กระจายอยู่ใน 3 bucket ที่ไม่เกี่ยวกัน
ผลคือ Forecast model อ่านว่าปีหน้า leisure Demand ช่วงนั้นอ่อน ทั้งที่จริงๆ กลุ่มทัวร์แข็งแกร่งมาก คุณเลยตั้งราคาต่ำเกินไป และเสียรายได้โดยไม่รู้สาเหตุ
ความเสียหายที่ compound แบบเงียบๆ
เมื่อ Segment data เพี้ยน ผลกระทบลามออกไป 3 ทาง:
- Demand Forecast บิดเบือน — model ที่ train บน historical Segment data จะ project pattern ที่ไม่มีอยู่จริง ถ้า leisure Demand ถูก misclassify เป็น transient มานาน 6 เดือน ระบบจะประเมิน price sensitivity ผิดทั้ง bucket
- Channel Mix analysis อ่านไม่ออก — เมื่อ booking จาก OTA ถูก tag บ้างว่า “OTA-LEISURE” บ้างว่า “LEISURE” บ้างว่าปล่อย default — channel contribution report กลายเป็นเรื่องเล่า ไม่ใช่ข้อมูล
- Rate strategy เดา ไม่ใช่ตัดสิน — dynamic pricing ที่ดีต้องการ Segment-level Demand signal ที่ชัด ถ้า signal เพี้ยน คุณก็ตั้งราคาด้วยความรู้สึก ไม่ใช่ข้อมูล
3 สัญญาณที่บอกว่า Tag Data ของคุณเพี้ยนแล้ว
- Segment distribution เปลี่ยนกะทันหันโดยไม่มีเหตุการณ์จริงรองรับ — ถ้า “TRANSIENT” กระโดดจาก 30% ขึ้นไป 55% ในเดือนที่ front office สลับกะ นั่นไม่ใช่ Demand shift แต่คือ tagging shift
- Market code ที่ไม่เคยใช้โผล่ขึ้นมาใน report — Code อย่าง “MISC”, “OTHER”, “TBD” หรือ default code ของ PMS ที่ไม่มีใครตั้งใจเลือก — เมื่อมีสิ่งเหล่านี้ใน data แปลว่ามี booking ที่ถูกปล่อยผ่านโดยไม่ tag
- Segment ที่ซ้ำกันในชื่อต่างกัน — Pull Segment list ออกมาแล้วดู: ถ้ามีทั้ง “CORP”, “CORPORATE”, “COR”, “Corp-Negotiated” อยู่ด้วยกัน — คุณกำลังนับ corporate Demand ใน 4 bucket ที่ระบบไม่รู้ว่าเป็นเรื่องเดียวกัน
วิธีตั้ง Convention ที่ใช้งานได้จริง
ล็อก master Segment list ใน PMS แล้วปิด free-text
กำหนด Segment code ที่ approved ให้ครบก่อน แล้วตั้ง PMS ให้ agent เลือกได้เฉพาะจาก dropdown เท่านั้น ห้าม free-text เด็ดขาด จำนวน Segment ที่เหมาะสมสำหรับโรงแรม 50-150 ห้องในไทยคือประมาณ 8-15 code — พอให้วิเคราะห์ได้ ไม่มากจนจำไม่ไหว
กำหนดเจ้าของ: ใครเป็น tagger, ใครเป็น auditor
Front office agent tag ณ วันรับ booking — ไม่ใช่ตอน check-in ไม่ใช่ตอน check-out Revenue manager หรือ supervisor audit ทุกสัปดาห์โดย pull รายการ booking ที่ tag เป็น default หรือ “OTHER” ออกมา แล้ว correct ภายใน 7 วัน ก่อนที่ data จะถูกดึงไปใน Forecast model
เขียน tagging rule ให้ชัดในกรณีที่คลุมเครือ
กรณีที่ทีมมักเถียงกัน:
- Walk-in ที่บอกว่า corporate → tag ตาม rate ที่ใช้จ่าย ถ้าไม่มี negotiated rate → TRANSIENT
- Group ที่จองผ่าน OTA → tag ตาม channel หลัก (OTA) ไม่ใช่ tag เป็น GROUP เพราะ channel analysis จะเสีย
- Staff rate / complimentary → แยก Segment ออกมาชัดๆ อย่าทิ้งไว้ใน LEISURE เพราะจะทำ ADR เพี้ยน
Review ทุก Quarter — ไม่ใช่รอให้ปัญหาชัดก่อน
ทุก 3 เดือน pull Segment distribution ปีปัจจุบัน vs ปีก่อน ถ้ามี shift ใหญ่กว่า 10 percentage point ใน Segment ใด ให้ถามก่อนว่า “มี business reason จริงไหม” ก่อนเชื่อ
Data ที่ clean ไม่ได้เกิดขึ้นเอง แต่เกิดจาก discipline ที่ตั้งใจสร้าง
ขั้นตอนแรกที่ทำได้วันนี้คือ pull Segment list ออกจาก PMS แล้วนับว่ามีกี่ code ที่ active เทียบกับที่ควรจะมีจริงๆ ถ้ามี code เกิน 20 หรือมี “OTHER/MISC” ติดอยู่ด้วย — นั่นคือจุดเริ่มต้น ทำ master list ให้เสร็จก่อน แล้วค่อย map booking เก่าให้ถูกต้อง