1. การซิงก์ราคา OTA จะส่งราคาและกฎการขายจากระบบ PMS โรงแรม หรือ channel manager โรงแรม ไปยังแต่ละช่องทางการจองที่เชื่อมต่ออยู่
2. ราคาที่ถูกคำนวณมา (Derived rates) ช่วยลดการทำงานแบบแมนนวล แต่ราคาหลัก กฎการคำนวณ การปัดเศษ และการจับคู่ช่องทาง จะต้องถูกต้องทั้งหมด
3. ควรตรวจสอบการอัปเดตที่สำเร็จแล้วจากต้นทาง ในบันทึกการจัดส่ง และบนหน้าเว็บ OTA ที่ลูกค้าเห็น โดยเฉพาะหลังการเปลี่ยนแปลงในช่วงวันหยุดหรือช่วงพีค
การซิงก์ราคา OTA ผ่าน ระบบ PMS โรงแรม ช่วยให้โรงแรมสามารถเปลี่ยนราคาเพียงครั้งเดียว และกระจายไปยัง Booking.com, Expedia, Agoda, Airbnb และช่องทางอื่นๆ ที่เชื่อมต่ออยู่ได้ กระบวนการเดียวกันนี้สามารถรองรับการกำหนดวันเข้าพักขั้นต่ำ การระงับการขาย และข้อจำกัดอื่นๆ ได้เช่นกัน
นั่นไม่ได้หมายความว่าทุก OTA จะแสดงราคาใหม่ในทันที ระบบ PMS จะสร้างการอัปเดต จากนั้น channel manager โรงแรม จะเป็นผู้ส่งออกไป และแต่ละ OTA จะประมวลผลข้อมูลดังกล่าว ข้อผิดพลาดในการจับคู่ข้อมูล การแก้ไขที่ขัดแย้งกันในเอกซ์ทราเน็ต หรือความล่าช้าในขั้นตอนใดก็ตาม อาจทำให้บางช่องทางยังคงขายในราคาเดิมได้
สิ่งที่การซิงก์ราคา OTA อัปเดตจริงๆ คืออะไร
การซิงโครไนซ์ราคาเป็นส่วนหนึ่งของกระบวนการส่งข้อมูลราคา ความพร้อมใช้งาน (Availability) และจำนวนห้องว่างที่กว้างกว่า ซึ่งมักเรียกว่า ARI ในส่วนของการกำหนดราคา ระบบต้นทางจะส่งราคาสำหรับที่พักแต่ละแห่ง ประเภทห้องพัก แผนราคา วันที่ และในบางครั้งรวมถึงจำนวนผู้เข้าพัก
แหล่งข้อมูลหลักอาจเป็น ระบบ PMS ระบบจัดการรายได้ หรือตัว channel manager เอง โดยปกติแล้วควรมีเพียงระบบเดียวที่ควบคุมแต่ละฟิลด์ หากระบบ PMS เป็นตัวคุมราคา BAR ในขณะที่พนักงานก็ไปแก้ไข BAR ในเอกซ์ทราเน็ตของ OTA ด้วย การซิงโครไนซ์ครั้งต่อไปอาจเขียนทับการเปลี่ยนแปลงที่ทำด้วยตนเอง หรือทำให้เกิดผลลัพธ์ที่ไม่คาดคิดได้
การอัปเดตราคาที่สมบูรณ์อาจประกอบด้วย:
- ราคารายคืน: จำนวนเงินสำหรับประเภทห้องพัก แผนราคา วันที่ และจำนวนผู้เข้าพัก
- กฎราคาที่ถูกคำนวณมา (Derived-rate): การปรับเปลี่ยนเป็นเปอร์เซ็นต์หรือแบบคงที่จากราคาหลัก
- ข้อจำกัด: วันเข้าพักขั้นต่ำ วันเข้าพักสูงสุด ปิดรับการเช็คอิน ปิดรับการเช็คเอาต์ กรอบเวลาการจอง หรือการระงับการขาย
- ราคาตามจำนวนผู้เข้าพัก: จำนวนเงินที่แตกต่างกันสำหรับแขกหนึ่ง สอง หรือมากกว่าในห้องเดียวกัน
จำนวนห้องว่างมีความเกี่ยวข้องกันแต่เป็นคนละส่วน ราคาอาจส่งมาถึงอย่างถูกต้องในขณะที่ความพร้อมใช้งานส่งมาไม่ถึง หรือจำนวนห้องว่างอาจถูกต้องในขณะที่ราคารองยังคงแสดงราคาของเมื่อวานนี้ ดังนั้นควรวิเคราะห์ข้อมูลแต่ละประเภทแยกกัน
การเปลี่ยนแปลงราคาเพียงครั้งเดียว ส่งไปถึงทุกช่องทางได้อย่างไร
ลองนึกภาพโรงแรมขนาด 30 ห้องที่ปรับขึ้นราคา BAR สำหรับห้อง Deluxe King จาก 180 ดอลลาร์เป็น 240 ดอลลาร์ในช่วงสุดสัปดาห์ที่มีคอนเสิร์ต ผู้จัดการฝ่ายรายได้ (Revenue Manager) จะบันทึกการเปลี่ยนแปลงสำหรับวันศุกร์และวันเสาร์ในระบบ PMS
channel manager ที่เชื่อมต่ออยู่จะแปลงการเปลี่ยนแปลงนั้นให้อยู่ในรูปแบบที่แต่ละ OTA ยอมรับ โดยจะส่งข้อมูลที่พัก รหัสห้องพักและราคาที่จับคู่ไว้ วันที่เข้าพัก จำนวนผู้เข้าพัก สกุลเงิน และจำนวนเงินใหม่ แต่ละ OTA จะตรวจสอบความถูกต้องของข้อความ อัปเดตผลิตภัณฑ์ที่สามารถขายได้ และส่งการตอบรับหรือข้อผิดพลาดกลับมา
ขั้นตอนการทำงานควรเป็นดังนี้:
- ผู้จัดการเปลี่ยนแปลงราคา BAR ของห้อง Deluxe King สำหรับวันที่เข้าพักที่ถูกต้อง
- ระบบ PMS บันทึกราคาใหม่และส่งการเปลี่ยนแปลงไปยัง channel manager
- channel manager ผลักดันการอัปเดตไปยังผลิตภัณฑ์ราคาของ OTA ทุกช่องทางที่จับคู่ไว้
- แต่ละ OTA ยอมรับหรือปฏิเสธข้อความนั้น และสถานะการจัดส่งจะปรากฏให้เห็น
- ทีมงานตรวจสอบหน้าการค้นหาที่ลูกค้าเห็น เพื่อยืนยันราคาและเงื่อนไขใหม่
ขั้นตอนสุดท้ายนั้นสำคัญมาก เพราะคำว่า “ส่งแล้ว” ไม่ได้แปลว่า “แสดงผลแล้ว” เสมอไป ภาษี ค่าธรรมเนียม ส่วนลดบนมือถือ โปรโมชั่นสำหรับสมาชิก หรือการตั้งค่าจำนวนผู้เข้าพัก สามารถเปลี่ยนแปลงราคาขายจริงที่แสดงต่อสาธารณะได้หลังจากที่ราคาเริ่มต้นถูกส่งไป
เมื่อการปรับราคาในช่วงวันหยุดยาวต้องถูกส่งไปยังหลายช่องทางอย่างรวดเร็ว channel manager โรงแรม ของ Smart Order จะเชื่อมต่อการเปลี่ยนแปลงราคาของระบบ PMS เข้ากับผลิตภัณฑ์ของ OTA ที่จับคู่ไว้ ผู้จัดการสามารถอัปเดตราคาเพียงครั้งเดียว ดูราคาและความพร้อมใช้งานปัจจุบันในแดชบอร์ดเดียว และสามารถตรวจสอบช่องทางที่ไม่ยอมรับการอัปเดตได้
อัปเดตราคาห้องพักโรงแรมจากแดชบอร์ดที่เชื่อมต่อแบบครบวงจร
เปลี่ยนราคาและข้อจำกัดเพียงครั้งเดียว จากนั้นให้ระบบ PMS และ channel manager ของ Smart Order ช่วยปรับช่องทาง OTA ที่จับคู่ไว้ให้สอดคล้องกันอย่างง่ายดายและประหยัดเวลา
ราคาแบบ Derived Rates ช่วยให้โครงสร้างราคามีความสอดคล้องกัน
ราคาที่ถูกคำนวณมา (Derived rate) จะถูกคำนวณจากราคาหลัก (Parent rate) แทนที่จะต้องมาตั้งค่าแยกกันเป็นราคาคงที่ ราคา BAR ที่ยืดหยุ่นอาจเป็นราคาหลัก ในขณะที่ราคาแบบไม่สามารถขอคืนเงินได้ จองล่วงหน้า หรือรวมอาหารเช้า จะเป็นราคารอง (Child rates)
หากราคา BAR คือ 200 ดอลลาร์ แผนราคาแบบไม่สามารถขอคืนเงินได้อาจเป็น BAR ลบ 10% ซึ่งจะได้ผลลัพธ์ที่ 180 ดอลลาร์ แผนแบบรวมอาหารเช้าอาจเป็น BAR บวก 20 ดอลลาร์ ซึ่งได้ 220 ดอลลาร์ การขึ้นราคา BAR เป็น 240 ดอลลาร์จะขยับราคาเหล่านั้นเป็น 216 และ 260 ดอลลาร์โดยไม่ต้องไปแก้ไขแยกต่างหาก
โรงแรมต้องตัดสินใจว่าจะให้เกิดการคำนวณที่จุดใด ระบบ PMS หรือ channel manager บางระบบจะคำนวณราคารองและส่งยอดสุทธิไปยังแต่ละ OTA ในขณะที่บาง OTA รองรับความสัมพันธ์แบบราคาหลัก-ราคารองของตนเอง การใช้ทั้งสองวิธีพร้อมกันบนผลิตภัณฑ์เดียวอาจทำให้ส่วนลดถูกนำไปหักออกถึงสองครั้งได้
ควรตรวจสอบรายละเอียดสี่ประการสำหรับทุกแผนราคาที่ถูกคำนวณมา: ราคาหลักที่ถูกต้อง การปรับเปลี่ยนเป็นเปอร์เซ็นต์หรือแบบคงที่ กฎการปัดเศษ และประเภทห้องพักที่บังคับใช้ นอกจากนี้ ต้องยืนยันด้วยว่าการปรับราคานั้นคำนวณก่อนหรือหลังการบวกเพิ่มตามจำนวนผู้เข้าพัก
การตั้งราคาแบบ Derived pricing จะไม่คัดลอกนโยบายการยกเลิก แผนมื้ออาหาร หรือกรอบเวลาการจองให้โดยอัตโนมัติ เงื่อนไขเหล่านั้นอาจยังคงต้องมีการกำหนดค่าและจับคู่แยกต่างหาก ราคา 180 ดอลลาร์ที่ถูกต้องก็อาจกลายเป็นผลิตภัณฑ์ที่ผิดพลาดได้ หาก OTA ดันแสดงเงื่อนไขยกเลิกฟรีสำหรับราคาที่ควรจะไม่สามารถขอคืนเงินได้
ข้อจำกัดต่างๆ ต้องถูกส่งไปพร้อมกับราคาด้วย
ราคาห้องพักโรงแรมจะสามารถขายได้ก็ต่อเมื่อข้อจำกัดของมันอนุญาตให้แสดงในผลการค้นหาของลูกค้า การอัปเดตราคาโดยไม่ควบคุมข้อจำกัดที่เกี่ยวข้อง อาจทำให้ข้อเสนอหลุดออกไปในวันที่โรงแรมตั้งใจจะปิดการขาย
วันเข้าพักขั้นต่ำเป็นตัวอย่างที่พบบ่อย ที่พักอาจปรับราคาในวันเสาร์ขึ้นเป็น 300 ดอลลาร์ และกำหนดให้เข้าพักขั้นต่ำสองคืน หากการอัปเดตราคาสำเร็จ แต่ข้อความที่ระบุจำนวนวันเข้าพักขั้นต่ำส่งไม่ผ่าน ลูกค้าก็จะยังคงจองแค่วันเสาร์คืนเดียวได้
กฎปิดรับการเช็คอินและปิดรับการเช็คเอาต์นั้นแตกต่างจากการระงับการขาย การปิดรับการเช็คอิน (Closed to arrival) จะบล็อกการเช็คอินในวันนั้น แต่แขกที่เข้าพักอยู่ก่อนแล้วยังคงพักต่อไปได้ การปิดรับการเช็คเอาต์ (Closed to departure) จะบล็อกการเช็คเอาต์ ส่วนการระงับการขาย (Stop-sell) จะปิดแผนราคานั้นไม่ให้ทำการขายในวันที่ได้รับผลกระทบ
ไม่ใช่ทุก OTA ที่รองรับทุกข้อจำกัดในรูปแบบเดียวกัน กฎบางอย่างใช้ได้ในระดับห้องพัก ส่วนกฎอื่นๆ ใช้ในระดับแผนราคา การจับคู่ช่องทางควรมีการระบุให้ชัดเจนว่าระบบใดควบคุมกฎข้อใด และ OTA ที่เชื่อมต่ออยู่ตีความกฎเหล่านั้นอย่างไร
หลังจากเปลี่ยนข้อจำกัดที่มีผลกระทบสูง ให้ลองค้นหารูปแบบการเข้าพักในหลายๆ แบบ ทดสอบการเข้าพักแบบคืนเดียว การเข้าพักหลายคืนที่คาบเกี่ยวกับวันที่ถูกจำกัด และวันที่เช็คอินที่แตกต่างกัน มุมมองปฏิทินแบบหน้าเดียวอาจไม่สามารถแสดงได้ทั้งหมดว่า OTA นำกฎไปใช้กับการค้นหาจริงอย่างไร
ทำไมความล่าช้าในการซิงก์ราคา OTA จึงเกิดขึ้น
คำว่า “เรียลไทม์” (Real-time) อธิบายถึงการเชื่อมต่อที่ทำงานตามเหตุการณ์ ไม่ใช่การรับประกันว่าทุกหน้าเว็บสาธารณะจะเปลี่ยนภายในศูนย์วินาที การอัปเดตราคาต้องผ่านหลายระบบ และแต่ละระบบอาจนำไปจัดคิว ตรวจสอบความถูกต้อง ลองส่งใหม่ หรือปฏิเสธมันก็ได้
ความล่าช้าเล็กน้อยอาจเกิดจากการประมวลผลข้อความที่ระบบ PMS, channel manager หรือ OTA ช่องว่างเวลาที่นานขึ้นมักบ่งชี้ว่า ข้อมูลการเข้าสู่ระบบล้มเหลว การเชื่อมต่อหมดอายุ แผนราคาไม่ได้ถูกจับคู่ ช่วงวันที่ไม่ถูกต้อง ปัญหาเรื่องสกุลเงิน หรือราคาอยู่นอกเหนือขีดจำกัดที่ OTA อนุญาต
การเปลี่ยนแปลงข้อมูลจำนวนมากก็ใช้เวลานานกว่าการอัปเดตแค่วันเดียวเช่นกัน การปรับราคาใหม่ 365 วันในสิบห้องร่วมกับแผนราคาต่างๆ จะสร้างข้อความที่ต้องส่งมากกว่าการเปลี่ยนราคาแค่ช่วงสุดสัปดาห์เดียวมาก บางระบบจะส่งเฉพาะวันที่ถูกแก้ไขเท่านั้น ในขณะที่บางระบบจะใช้วิธีเขียนทับครอบคลุมช่วงวันที่ที่กว้างกว่า
โปรโมชั่น OTA ที่ตั้งค่าแบบแมนนวลคืออีกหนึ่งสาเหตุที่ทำให้ราคาดูเหมือนไม่ตรงกัน ราคาเริ่มต้นที่ 200 ดอลลาร์อาจซิงก์ไปได้อย่างถูกต้อง แต่ดีลบนมือถือลดราคาที่ลูกค้าเห็นเหลือ 180 ดอลลาร์ ก่อนที่จะมองว่าระบบทำงานผิดพลาด ควรแยกแยะราคาเริ่มต้นที่ทางโรงแรมส่งไป ออกจากส่วนลดที่ได้เงินสนับสนุนจาก OTA หรือจากตัวที่พักเองเสียก่อน
สำหรับการเปลี่ยนแปลงเร่งด่วน อย่าคอยแต่จะกดส่งการอัปเดตเดิมซ้ำๆ โดยไม่ตรวจสอบสถานะ การผลักดันข้อมูลซ้ำแบบเต็มช่วงเวลาจะยิ่งทำให้คิวงานยาวขึ้น ควรตรวจสอบค่าสุดท้ายที่ได้รับการยอมรับ เวลาของข้อความ รหัสราคาที่ได้รับผลกระทบ และการตอบกลับข้อผิดพลาดใดๆ ก่อนเสมอ
แนวทางปฏิบัติในการตรวจสอบการซิงก์ราคาที่นำไปใช้ได้จริง
การสุ่มตรวจประจำเป็นรายวัน ควรมุ่งเน้นไปที่วันที่หากพลาดใช้ราคาเก่าแล้วจะสร้างความเสียหายหนัก: เช่น วันที่ห้องพักใกล้จะเต็ม วันที่มีกิจกรรมในท้องถิ่น โปรโมชั่นใหม่ การเปลี่ยนแปลงข้อจำกัด และช่วงเวลาสิ้นสุดของกรอบการจอง
บันทึกราคาเริ่มต้น ราคาที่ถูกคำนวณมา ข้อจำกัด และผลลัพธ์สาธารณะที่คาดหวังสำหรับวันที่นำมาเป็นตัวอย่างสักสองหรือสามวัน จากนั้นเปรียบเทียบระบบ PMS หรือแหล่งที่มาของราคา บันทึกการจัดส่งของ channel manager เอกซ์ทราเน็ตของ OTA และผลการค้นหาที่ลูกค้าเห็น
ใช้สกุลเงินและจำนวนผู้เข้าพักตามที่ OTA แสดงผล ราคาสำหรับแขกสองท่านไม่สามารถนำไปเปรียบเทียบได้อย่างแม่นยำกับราคาเริ่มต้นสำหรับแขกหนึ่งท่าน ควรรวมภาษีและค่าธรรมเนียมให้สอดคล้องกัน และสังเกตด้วยว่าผลลัพธ์สาธารณะที่แสดงนั้นเป็นราคาต่อคืนหรือราคาสำหรับการเข้าพักทั้งหมด
หากมีช่องทางเดียวที่ผิดพลาด ให้หลีกเลี่ยงการไปแก้ไขมันทุกช่องทาง ยืนยันการจับคู่ห้องพักและราคา จากนั้นจึงคัดแยกหาต้นตอว่าข้อผิดพลาดส่งผลกระทบต่อราคาหลัก ราคารองรายการเดียว ข้อจำกัดเดียว หรือระดับผู้เข้าพักแบบใดแบบหนึ่งกันแน่ การส่งข้อมูลซ้ำเฉพาะจุดที่แคบกว่านั้น ย่อมปลอดภัยกว่าการเขียนทับข้อมูลที่ถูกต้องทั้งปีอย่างแน่นอน
เมื่อต้องส่งเรื่องต่อ ควรส่งพร้อมหลักฐาน ระบุรหัสที่พัก รหัสห้องพักและราคา วันที่เข้าพัก ค่าที่คาดหวัง ค่าที่แสดง เวลาที่อัปเดต การตอบรับ ข้อความแสดงข้อผิดพลาด และภาพหน้าจอ สิ่งนี้จะช่วยให้ผู้ให้บริการระบบ PMS หรือ OTA มีรายละเอียดมากพอที่จะติดตามประวัติข้อความได้
คำถามที่พบบ่อย (FAQ)
ราคาห้องพักโรงแรมควรอัปเดตบน OTA ได้เร็วแค่ไหน?
โดยปกติแล้วระบบที่เชื่อมต่อกันจะส่งการเปลี่ยนแปลงทันทีที่ถูกบันทึก แต่เวลาที่แสดงผลต่อสาธารณะจะแตกต่างกันไปตามช่องทางและขนาดของข้อมูลที่อัปเดต ตรวจสอบการเปลี่ยนแปลงเร่งด่วนบนหน้าเว็บที่ลูกค้าเห็น และตรวจสอบหาสาเหตุหากบันทึกการจัดส่งแสดงข้อผิดพลาดหรือไม่ตอบรับ
ทำไมราคา OTA จึงแตกต่างจากราคาในระบบ PMS?
สาเหตุอาจมาจากการซิงก์ล้มเหลว การจับคู่ผิดพลาด ราคาตามจำนวนผู้เข้าพัก การแปลงสกุลเงิน ภาษี โปรโมชั่นของ OTA หรือการเข้าไปแก้ไขเองแบบแมนนวลในเอกซ์ทราเน็ต ให้เปรียบเทียบข้อมูลห้องพัก แผนราคา วันที่ จำนวนผู้เข้าพัก สกุลเงิน และสิ่งที่รวมอยู่ในราคาที่เป็นตัวเดียวกัน ก่อนที่จะวิเคราะห์ความไม่ตรงกันนี้
ราคาเริ่มต้น (Base rate) และราคาที่ถูกคำนวณมา (Derived rate) แตกต่างกันอย่างไร?
ราคาเริ่มต้นหรือราคาหลัก (Parent rate) จะถูกตั้งค่าและดูแลโดยตรง ส่วนราคาที่ถูกคำนวณมา (Derived rate) จะถูกคำนวณจากราคาหลักนั้นโดยใช้การปรับลดเปอร์เซ็นต์หรือแบบคงที่ เช่น BAR ลบ 10% สำหรับข้อเสนอแบบไม่สามารถขอคืนเงินได้
กฎการเข้าพักขั้นต่ำ ซิงก์ไปพร้อมกับราคาโรงแรมหรือไม่?
สามารถซิงก์ได้ เมื่อการเชื่อมต่อ OTA นั้นๆ รองรับข้อจำกัดดังกล่าว และมีการจับคู่ราคาห้องพักไว้อย่างถูกต้อง อย่างไรก็ตาม ข้อความราคาและข้อจำกัดอาจส่งผ่านหรือล้มเหลวแยกจากกัน ดังนั้นควรทดสอบกฎโดยการลองค้นหาแบบผู้เข้าพักจริง
พนักงานโรงแรมควรแก้ไขราคาโดยตรงในเอกซ์ทราเน็ตของ OTA หรือไม่?
หลีกเลี่ยงการเข้าไปแก้ไขในเอกซ์ทราเน็ตเป็นประจำ เมื่อระบบ PMS หรือ channel manager คือแหล่งข้อมูลหลัก การแก้ไขค่าด้วยตนเองอาจถูกเขียนทับจากการซิงก์ในครั้งถัดไป หรือไปขัดแย้งกับกฎราคาที่ถูกคำนวณมา ควรใช้เอกซ์ทราเน็ตเฉพาะสำหรับการตั้งค่าที่ตั้งใจจะควบคุมจากที่นั่นโดยตรงเท่านั้น
รักษาแหล่งที่มาของราคาให้ชัดเจน
การกำหนดราคา OTA ที่สอดคล้องกันนั้นขึ้นอยู่กับความเป็นเจ้าของข้อมูล ควรกำหนดให้ชัดเจนว่าราคา BAR ควรเปลี่ยนแปลงที่ใด ราคารองควรถูกคำนวณจากที่ใด ข้อจำกัดถูกควบคุมที่ใด และโปรโมชั่นใดบ้างที่จะให้เป็นหน้าที่จัดการของแต่ละ OTA โดยเฉพาะ
จากนั้นให้ตรวจสอบเส้นทางทั้งหมดแทนที่จะเชื่อมั่นแค่สถานะไฟเขียวอันเดียว: ตรวจสอบค่าต้นทาง ข้อความขาออก การตอบรับจาก OTA และผลลัพธ์ที่ลูกค้าเห็น กิจวัตรเหล่านี้จะช่วยให้การซิงก์ราคามีประสิทธิภาพสูงสุด โดยไม่เกิดความสับสนว่าความล่าช้าในการประมวลผล โปรโมชั่น หรือข้อผิดพลาดในการจับคู่ข้อมูล เป็นการตัดสินใจกำหนดราคาที่ผิดพลาดแต่อย่างใด
