วิธีซิงค์เว็บไซต์จองตรงของคุณกับ Airbnb และ Booking.com

เว็บไซต์จองตรง การซิงค์กับ OTA หมายความว่า เมื่อขายห้องหนึ่งผ่านเว็บไซต์โรงแรม จำนวนห้องที่ยังขายได้บน Airbnb และ Booking.com ต้องเปลี่ยนทันที และต้องทำงานในทางกลับกันด้วย เมื่อมีการจองผ่าน OTA ห้องว่างบนหน้าจองตรงต้องลดลงก่อนที่แขกอีกคนจะจองห้องเดียวกัน

อย่าดูแลปฏิทินอิสระสามชุด ระบบจอง ระบบบริหารจัดการที่พัก (PMS) และ channel manager ควรทำงานเป็นวงจรเดียวกัน โดยมีกฎที่ชัดเจนสำหรับราคา ข้อจำกัด การจอง และกรณียกเว้น

คู่มือนี้อธิบายวงจรดังกล่าวจากมุมมองการดำเนินงานของเจ้าของที่พัก

สถาปัตยกรรมการซิงค์เว็บไซต์จองตรงกับ OTA

PMSควรเก็บโครงสร้างห้องและระเบียนการจองของโรงแรม ระบบจองจะแสดงห้องและราคาแบบเรียลไทม์บนเว็บไซต์โรงแรม ส่วน channel manager จะแลกเปลี่ยนข้อมูลที่รองรับกับ Airbnb, Booking.com และตัวแทนท่องเที่ยวออนไลน์ (OTA) อื่น ๆ

ขั้นตอนปกติคือ:

แขกจองตรง → การจองเข้าสู่ PMS → สต็อกของประเภทห้องลดลง → channel manager ส่งจำนวนห้องว่างใหม่ไปยัง Airbnb และ Booking.com

การจองผ่าน OTA จะทำงานในทิศทางกลับกัน:

แขกจองบน OTA → การจองเข้าสู่ PMS → สต็อกห้องพักลดลง → เว็บไซต์โรงแรมและช่องทางอื่นที่เชื่อมต่อได้รับจำนวนห้องใหม่

ในการตั้งค่าส่วนใหญ่ แต่ละช่องทางจะแลกเปลี่ยนข้อมูลผ่าน PMS และ channel manager หรือแพลตฟอร์มแบบครบวงจร

ข้อมูลใดควรซิงค์ระหว่างเว็บไซต์กับ OTA

แยกข้อมูลที่ใช้แหล่งร่วมกันออกจากเนื้อหาเฉพาะช่องทาง

ห้องว่างและการจองต้องได้รับการควบคุมอย่างเข้มงวดที่สุด เพราะข้อผิดพลาดอาจทำให้ห้องสุดท้ายถูกขายซ้ำสองครั้ง ราคาและข้อจำกัดก็สำคัญเช่นกัน แต่ผลลัพธ์ที่แขกเห็นอาจแตกต่างกันเมื่อ OTA ใช้โปรโมชัน ค่าธรรมเนียม การแสดงภาษี ส่วนลด หรือกฎที่ระบบเชื่อมต่อไม่รองรับ

Smart Order เชื่อมต่อระบบจองโรงแรมเข้ากับสต็อกห้องพักใน PMS และchannel manager โรงแรม เมื่อมีการจองตรง รายการจองจะเข้าสู่ปฏิทินดำเนินงาน ลดจำนวนห้องในกลุ่มที่กำหนด และส่งห้องว่างที่ปรับแล้วไปยังช่องทาง OTA ที่เชื่อมต่อ

เลือกแหล่งข้อมูลหลักเพียงแห่งเดียว

ก่อนเชื่อมต่อระบบใด ๆ ให้กำหนดว่าพนักงานจะจัดการค่าแต่ละประเภทที่ระบบใด โครงสร้างที่ใช้กันทั่วไปคือ:

• PMS หรือ channel manager ควบคุมประเภทห้อง ราคาพื้นฐาน ห้องว่าง และข้อจำกัดที่รองรับ
• ระบบจองอ่านข้อเสนอสำหรับช่องทางตรงที่ได้รับอนุมัติ และบันทึกการจองตรงลงใน PMS
• Airbnb และ Booking.com รับการอัปเดตที่รองรับ พร้อมเก็บเนื้อหา โปรโมชัน ค่าธรรมเนียม นโยบาย หรือค่าที่เขียนทับเฉพาะช่องทางไว้ตามความจำเป็น

อย่าให้พนักงานหลายคนเปลี่ยนจำนวนห้องว่างพื้นฐานชุดเดียวกันในระบบหลังบ้านสามแห่ง การแก้ไขด้วยตนเองอาจเหมาะสมระหว่างเกิดเหตุขัดข้อง แต่ต้องบันทึกไว้และปรับให้ตรงกับแหล่งข้อมูลหลักภายหลัง

การกำหนดแหล่งข้อมูลหลักต้องมีผู้รับผิดชอบด้วย ควรมีบุคคลหนึ่งอนุมัติการจับคู่ห้อง ตรรกะราคา การจัดสรรห้องให้แต่ละช่องทางโดยเจตนา และการเปลี่ยนแปลงผลิตภัณฑ์ที่เชื่อมต่อ

ห้องว่างต้องอ้างอิงสต็อกห้องจริงชุดเดียวกัน

เริ่มจากห้องที่โรงแรมสามารถจัดให้แขกได้จริง รวมหลายห้องไว้เป็นประเภทเดียวสำหรับขายก็ต่อเมื่อแขกสามารถใช้แทนกันได้

สมมติว่าที่พักมีห้อง Deluxe King สี่ห้อง ข้อเสนอแบบยืดหยุ่นและแบบไม่คืนเงินบนเว็บไซต์กับ OTA เป็นแผนราคาคนละแบบ แต่ยังดึงจากห้องสี่ห้องชุดเดียวกัน การขายหนึ่งแผนราคาต้องลดห้องว่างของข้อเสนออื่นทุกข้อที่ผูกกับกลุ่มห้องนั้น

ปัญหาเกิดขึ้นเมื่อหน้าจองตรงมีการจัดสรรห้องของตนเอง หรือเมื่อผลิตภัณฑ์ OTA สองรายการชี้ไปยังสำเนาคนละชุดของห้องจริงห้องเดียวกัน ซอฟต์แวร์อาจแสดงว่าอัปเดตสำเร็จ ทั้งที่ทุกช่องทางรวมกันขายห้องมากกว่าจำนวนที่มีจริง

ทดสอบวันที่มีการจองน้อย วันที่เกือบเต็ม ห้องที่ปิดซ่อม และห้องสุดท้ายที่ยังว่าง การซิงค์เว็บไซต์จองตรงกับ OTA จะเชื่อถือได้ก็ต่อเมื่อทุกเหตุการณ์เปลี่ยนจำนวนที่ใช้ร่วมกันอย่างถูกต้อง

การซิงค์ราคาไม่ได้หมายความว่าราคาสาธารณะต้องเท่ากันเสมอไป

เลือกแหล่งราคาพื้นฐานและบันทึกการปรับราคาของแต่ละช่องทาง โรงแรมอาจตั้งใจเผยแพร่ข้อเสนอเฉพาะช่องทางตรง บวกราคาเพิ่มสำหรับ OTA คงโปรโมชันของ OTA ไว้ หรือใช้เงื่อนไขยกเลิกที่แตกต่างกัน

เป้าหมายการซิงค์คือกลยุทธ์ราคาที่อนุมัติแล้ว ไม่จำเป็นต้องเป็นตัวเลขเดียวกันทุกหน้าจอ สำหรับแต่ละห้องและแผนราคา ให้ตรวจสอบว่า:

• ระบบใดเก็บราคาพื้นฐาน
• ราคาของช่องทางเป็นค่าตายตัว คำนวณต่อยอด หรือมีการปรับค่า
• ภาษี ค่าธรรมเนียม อาหาร ค่าบริการตามจำนวนผู้เข้าพัก และส่วนลดใดส่งผลต่อยอดรวมที่แสดง
• ระบบเชื่อมต่อรองรับข้อจำกัดใดบ้าง

ค้นหาการเข้าพักหนึ่งคืนและหลายคืนบนเว็บไซต์สาธารณะ Airbnb และ Booking.com เปรียบเทียบยอดรวมและเงื่อนไขที่แขกเห็น ไม่ใช่เพียงราคาที่ PMS ส่งออก

หากราคาแม่เปลี่ยน ให้ตรวจสอบราคาที่คำนวณต่อยอดทั้งหมดทั้งช่องทางตรงและ OTA การอัปเดตราคาพื้นฐานสำเร็จไม่ได้พิสูจน์ว่าสูตรราคาลูกหรือยอดรวมสาธารณะถูกต้อง

การเชื่อมต่อ Airbnb และ Booking.com ทำงานแตกต่างกัน

Airbnb รองรับตัวเลือกการซิงค์กับซอฟต์แวร์อย่างเป็นทางการสองแบบ ได้แก่ ซิงค์ทุกอย่าง หรือซิงค์เฉพาะราคาและห้องว่าง เมื่อใช้การซิงค์เฉพาะราคาและห้องว่าง เจ้าของที่พักยังจัดการเนื้อหาที่พักและการตั้งค่าการจองใน Airbnb ได้ และอาจเขียนทับค่าบางอย่างในระบบนั้นได้ เจ้าของต้องทราบว่าฟิลด์ใดควบคุมจาก PMS และฟิลด์ใดยังคงอยู่ฝั่ง Airbnb

Booking.com ระบุว่าโดยปกติที่พักแต่ละแห่งควรเชื่อมต่อผ่าน channel manager แทนการสร้างการเชื่อมต่อ API โดยตรง เครื่องมือการเชื่อมต่อรองรับราคาและห้องว่าง ส่วนฟังก์ชันอื่นขึ้นอยู่กับการเชื่อมต่อของผู้ให้บริการและการตั้งค่าของที่พัก

ด้วยเหตุนี้ “เชื่อมต่อทั้งสองช่องทางแล้ว” จึงยังไม่ใช่กฎการดำเนินงานที่ครบถ้วน ควรมีเอกสารควบคุมสั้น ๆ ระบุแหล่งข้อมูลสำหรับห้องว่าง ราคา ข้อจำกัด เนื้อหา โปรโมชัน ภาษี การชำระเงิน การแก้ไขการจอง และการยกเลิกของแต่ละแพลตฟอร์ม

อย่าคิดว่าการเชื่อมต่อปฏิทินผ่าน iCal ของ Airbnb เทียบเท่าการเชื่อมต่อ API แบบสองทางเต็มรูปแบบ ฟีดปฏิทินอาจเน้นเฉพาะวันที่ปิดขาย และอาจไม่แลกเปลี่ยนราคา ข้อจำกัด รายละเอียดการจอง หรือการอัปเดตได้ครอบคลุมเท่ากัน

จับคู่ประเภทห้องและแผนราคาก่อนเปิดขายสต็อกห้อง

การจับคู่บอกระบบว่าผลิตภัณฑ์ใดเทียบเท่ากัน “Deluxe King” บนเว็บไซต์โรงแรมอาจใช้ชื่อ “Superior Double Room” บน Booking.com และมีชื่ออีกแบบบน Airbnb ชื่ออาจต่างกันได้ แต่สิ่งที่สัญญาว่าจะมอบเป็นห้องจริงต้องตรงกัน

สำหรับทุกผลิตภัณฑ์ที่เปิดขาย ให้ตรวจสอบกลุ่มห้อง จำนวนผู้เข้าพักสูงสุด รูปแบบเตียง วิวหรือประเภทที่สัญญาไว้ เงื่อนไขราคา นโยบายยกเลิก อาหาร และวิธีชำระเงิน จากนั้นจับคู่แต่ละแผนราคากับข้อเสนอที่ต้องการ

อย่าจับคู่อัตราบนเว็บไซต์ที่คืนเงินได้กับอัตรา OTA ที่ไม่คืนเงิน เพียงเพราะทั้งสองใช้ห้องเดียวกัน กลุ่มห้องว่างอาจใช้ร่วมกันได้ แต่ราคาและนโยบายยังต้องแยกกัน

ปิดหรือแก้ไขผลิตภัณฑ์ OTA ที่ยังไม่ได้จับคู่ รายการที่ถูกลืมอาจยังขายต่อไปนอกกระบวนการซิงค์เว็บไซต์จองตรงกับ OTA

ทำความเข้าใจความล่าช้า ความล้มเหลว และการเขียนทับค่าด้วยตนเอง

“เรียลไทม์” คือเป้าหมายการดำเนินงาน ไม่ใช่เหตุผลให้ละเลยสถานะการส่ง การอัปเดตต้องผ่านหลายระบบ และ OTA อาจปฏิเสธหรือชะลอข้อความเนื่องจากการจับคู่ ข้อมูลรับรอง ขีดจำกัดอัตราการส่ง ข้อจำกัดที่ไม่รองรับ หรือการบำรุงรักษาฝั่งช่องทาง

PMS โรงแรมหรือ channel manager ควรแสดงการอัปเดตที่ล้มเหลว วันที่และผลิตภัณฑ์ที่ได้รับผลกระทบ สถานะการลองใหม่ และรายละเอียดเพียงพอให้พนักงานตอบสนองได้

สร้างกฎรับมือเหตุขัดข้องแบบง่าย ๆ:

1. ระบุห้อง ราคา วันที่ และช่องทางที่ได้รับผลกระทบ
2. ปกป้องสต็อกห้องด้วยตนเองหากมีความเสี่ยงที่จะขายเกินจำนวนทันที
3. บันทึกค่าที่เขียนทับชั่วคราวใน OTA
4. แก้ไขข้อผิดพลาดที่แหล่งข้อมูลหรือการจับคู่
5. ส่งใหม่หรือรอให้ระบบลองใหม่ตามกระบวนการที่อนุมัติ
6. ตรวจสอบให้ทุกช่องทางสาธารณะตรงกัน แล้วนำค่าที่เขียนทับชั่วคราวออก

อย่าคิดว่าการอัปเดตสำเร็จเพียงเพราะปฏิทินภายในเปลี่ยน หน้าจองสาธารณะคือจุดขายสุดท้ายที่ต้องยืนยัน

ทดสอบการจองผ่านทุกเส้นทาง

ใช้วันที่ในอนาคตที่มีความเสี่ยงต่ำ และบันทึกจำนวนห้องว่างเริ่มต้น ราคา ข้อจำกัด และยอดรวมที่แสดงต่อสาธารณะ จากนั้นทดสอบการจองตรง การจอง Airbnb และการจอง Booking.com อย่างละอย่างน้อยหนึ่งครั้ง

สำหรับทุกการจอง ให้ตรวจสอบประเภทห้องใน PMS แผนราคา วันที่ แขก แหล่งที่มา รหัสภายนอก ราคา สถานะการชำระเงิน และนโยบายให้ถูกต้อง ยืนยันว่าห้องว่างลดลงบนเว็บไซต์โรงแรมและ OTA ทั้งสองแห่ง

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

ทดสอบห้องสุดท้ายแยกต่างหาก ตั้งให้เหลือหนึ่งห้อง ทำการจองให้เสร็จ และยืนยันว่าผลิตภัณฑ์ปิดขายทุกช่องทาง ทำซ้ำสำหรับกลุ่มสต็อกห้องจริงแต่ละชุด และแผนราคาใด ๆ ที่มีข้อจำกัดหรือเงื่อนไขชำระเงินไม่ปกติ

บันทึกรหัสการจอง เวลา ภาพหน้าจอ ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง และหมายเหตุการแก้ไข ทดสอบวงจรทั้งหมดอีกครั้งหลังแก้ไขทุกครั้ง

ติดตามการซิงค์หลังเปิดใช้งานจริง

ใน 48 ชั่วโมงแรก ให้ตรวจสอบการจองใหม่ การแก้ไข และการยกเลิกทุกรายการ รวมถึงห้องว่างใน 30 วันถัดไป ตรวจสอบบันทึกความล้มเหลวหลายครั้งในช่วงที่มีการขายหนาแน่น

หลังระบบมีเสถียรภาพ ให้ติดตามการแจ้งเตือนทุกวันและตรวจสอบราคาสาธารณะกับห้องว่างตามกำหนดเวลา ทดสอบใหม่ทุกครั้งที่โรงแรมเพิ่มหรือเปลี่ยนชื่อห้อง เปิดแผนราคา เปลี่ยนราคาตามจำนวนผู้เข้าพัก แก้ไขข้อจำกัด เชื่อมต่อ OTA ใหม่ หรือเปลี่ยน channel manager

ติดตามเหตุขัดข้องแยกตามสาเหตุ ข้อผิดพลาดในการจับคู่ซ้ำ ๆ การเขียนทับค่าด้วยตนเอง การยกเลิกที่ตกหล่น สต็อกห้องค้าง หรือราคาที่ถูกปฏิเสธ บ่งชี้ถึงปัญหาการตั้งค่าหรือความรับผิดชอบ ไม่ใช่เพียงโชคร้ายแบบสุ่ม

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

ฉันซิงค์เว็บไซต์โรงแรมโดยตรงกับ Airbnb และ Booking.com ได้หรือไม่

โดยทั่วไป ระบบจองบนเว็บไซต์โรงแรมจะเชื่อมกับ PMS และ channel manager ซึ่งทำหน้าที่จัดการการเชื่อมต่อ OTA ที่รองรับ Booking.com แนะนำให้ที่พักเชื่อมต่อผ่าน channel manager ส่วน Airbnb รองรับการเชื่อมต่อกับซอฟต์แวร์ PMS หรือ channel manager ที่ได้รับอนุมัติ

ควรมีข้อมูลใดอัปเดตหลังได้รับการจองตรง

การจองควรเข้าสู่ PMS ลดสต็อกของประเภทห้องที่ถูกต้อง อัปเดตปฏิทินดำเนินงาน และส่งจำนวนห้องว่างที่ปรับแล้วไปยัง Airbnb, Booking.com และช่องทางอื่นที่เชื่อมต่อ

ราคาต้องเหมือนกันทุกช่องทางหรือไม่

ไม่จำเป็น โรงแรมอาจใช้ข้อเสนอช่องทางตรง การปรับราคาตามช่องทาง หรือโปรโมชัน OTA เจ้าของควรกำหนดความสัมพันธ์ของราคาให้ชัดเจน และตรวจสอบยอดรวม นโยบาย และข้อจำกัดสุดท้ายที่แขกเห็น

iCal เพียงพอที่จะป้องกันการจองซ้ำหรือไม่

iCal แลกเปลี่ยนช่วงวันที่ปิดในปฏิทินได้ แต่ขอบเขตและลักษณะการอัปเดตต่างจากการเชื่อมต่อ API เต็มรูปแบบ ควรยืนยันเวลา ฟิลด์ และข้อจำกัดกับผู้ให้บริการ และอย่าคิดว่า iCal จะซิงค์ราคาหรือข้อจำกัดโดยละเอียด

ควรทดสอบการซิงค์ OTA บ่อยเพียงใด

ทดสอบก่อนเปิดใช้งานและหลังการเปลี่ยนแปลงห้อง ราคา ข้อจำกัด จำนวนผู้เข้าพัก การจับคู่ หรือการเชื่อมต่อทุกครั้ง ติดตามการแจ้งเตือนทุกวันและตรวจสอบห้องสุดท้ายเป็นระยะ

แหล่งสต็อกห้องเดียว สามช่องทางขาย

การซิงค์เว็บไซต์จองตรงกับ OTA ที่เชื่อถือได้ ต้องอาศัยโครงสร้างสต็อกห้องจริงเพียงชุดเดียว การจับคู่ที่อนุมัติแล้ว การกำหนดผู้ควบคุมราคา การเชื่อมต่อที่รองรับ และการจัดการความล้มเหลวที่มองเห็นได้

ปฏิบัติต่อเว็บไซต์จองตรงในฐานะช่องทางจริง ไม่ใช่ปฏิทินแยกต่างหาก เมื่อทุกการจองเข้าสู่ระเบียน PMS เดียวกันและกระตุ้นให้อัปเดตห้องว่างทั่ว Airbnb และ Booking.com โรงแรมก็เพิ่มยอดขายตรงได้โดยไม่เพิ่มงานจัดการสต็อกด้วยตนเองหรือสร้างช่วงเสี่ยงต่อการขายเกินจำนวนที่หลีกเลี่ยงได้