Chatbot โรงแรม​กับ Booking.com คำขอ​ที่​บอท​ต้อง​ส่ง​ให้​คน​ตัดสิน

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

แหล่ง​ที่​ใช้​คือ​เอกสาร Connectivity APIs ของ Booking.com สอง​หน้า ได้แก่ หน้า​อธิบาย Messaging API และ หน้า​การ​จัดการ​ข้อความ กับ หน้า Rates & Availability ผู้​เขียน​เปิด​อ่าน​ทั้ง​สาม​หน้า​ใน​วัน​ที่ 27 กันยายน 2569 ส่วน​ผู้​เขียน​เอง บริษัท ฟิจิ⁠ทัล เอ​เจน​ซี จำกัด (PHYGITAL AGENCY) ทำงาน​วาง​บอ​ทบน​แชท​ของ​ธุรกิจ แต่​ไม่​ได้​เป็น​ผู้​ให้​บริการ​เชื่อม​ต่อ​ของ Booking.com และ​ไม่​ได้​รับ​เชื่อม Channel Manager ส่วน​ที่​เชื่อม​กับ OTA จึง​เป็น​งาน​ของ​ผู้​ให้​บริการ​ระบบ​ที่​โรงแรม​ใช้​อยู่

Messaging API ให้​โรงแรม​ดึง​ข้อความ​และ​บท​สนทนา ส่ง​และ​ตอบ​ข้อความ​ตัว​อักษร ตอบ​คำขอ​พิเศษ​ที่​แขก​พิมพ์​เอง ส่ง​ไฟล์​แนบ และ​ติด​ป้าย​ว่า​บท​สนทนา​นั้น​ไม่​ต้อง​ตอบ เอกสาร​ชุด​นี้​เขียน​ให้​ผู้​พัฒนา​ของ​ผู้​ให้​บริการ​เชื่อม​ต่อ (Connectivity Partner) และ​มี​ขั้น​ตอน​ขอรับ​รอง​กับ​ทีม Connectivity Support ก่อน​ใช้​จริง

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

โรงแรม​หลาย​แห่ง​ใน​เครือ​เดียวกัน​ใช้​ระบบ​ดึง​ข้อความ​ชุด​เดียว​ได้​ไหม

ได้ แต่​ต้อง​รู้​ว่า​คิว​ข้อความ​รวม​กัน​อยู่​ที่​ใด เอกสาร​ระบุ​ว่า​คิว​ผูก​กับ​บัญชี​เครื่อง (machine account) ของ​ผู้​ให้​บริการ​เชื่อม​ต่อ ทุก​ที่พัก​ที่​อยู่​ใน​บัญชี​เดียวกัน​จึง​ใช้​คิว​ร่วม​กัน การ​ดึง​แต่ละ​ครั้ง​ได้​สูงสุด 100 ข้อความ และ​ต้อง​ยืนยัน​ว่า​ดึง​สำเร็จ​ก่อน​ข้อความ​ชุด​นั้น​จะ​ออก​จาก​คิว ถ้า​เปิด​สิทธิ์​ดึง​ข้อความ​ใน​หลาย​บัญชี​ที่​มี​ที่พัก​ซ้ำ​กัน ข้อความ​อาจ​ซ้ำ​อยู่​หลาย​คิว เอกสาร​จึง​แนะนำ​ให้​มี​งาน​ตั้ง​เวลา​คอย​คัด​ข้อความ​ซ้ำ​ออก

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

ถ้า​ผู้​วาง​ระบบ​บอก​ว่า​เชื่อม Booking.com ได้ ควร​ถาม​อะไร

ถาม​ว่า​เชื่อม​ผ่าน​ผู้​ให้​บริการ​ราย​ไหน ราย​นั้น​ผ่าน​การ​รับรอง Messaging API แล้ว​หรือ​ยัง และ​ใช้​เวอร์ชัน​ไหน เอกสาร​ระบุ​ว่า​คำขอ​แบบ​บริการ​ตัว​เอง​ดึง​ผ่าน API ได้​ตั้งแต่​เวอร์ชัน 1.2 และ​ต้อง​เปิด​ฟีเจอร์​แยก​ไว้​ก่อน ถ้า​ระบบ​ยัง​อยู่​เวอร์ชัน​แรก คำขอ​กลุ่ม​นี้​จะ​ไม่​ถูก​ดึง​มา

Booking.com เรียก​คำขอ​กลุ่ม​นี้​ว่า self-service request แขก​ส่ง​ได้​หลัง​การ​จอง​ยืนยัน​แล้ว และ​เป็น​คำขอ​ที่​มี​โครงสร้าง​ตายตัว ไม่ใช่​ข้อความ​พิมพ์​อิสระ

สอง​แถว​ล่าง​คือ​จุด​ที่​บอ​ท​หยุด​แน่นอน เอกสาร​เขียน​ว่า​โรงแรม​ต้อง​ตอบ​สอง​คำขอ​นี้​ใน​เอ็กซ์​ทรา​เน็ต​โดย​เลือก​คำ​ตอบ​จาก​ตัว​เลือก​ที่​มี​ให้ ระบบ​ภายนอก​ที่​ต่อ​ผ่าน API จึง​ทำได้​แค่​แจ้ง​พนักงาน​ว่า​มี​คำขอ​เข้า​มา

ตอบ​ผ่าน API แล้ว พนักงาน​ยัง​แก้​คำ​ตอบ​ใน​เอ็กซ์​ทรา​เน็ต​ได้​ไหม

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

หน้า Rates & Availability แยก​คำ​สอง​คำ​ไว้ inventory คือ​จำนวน​ห้อง​ทั้งหมด​ที่​โรงแรม​เปิด​ขาย รวม​ประเภท​ห้อง แผน​ราคา ข้อ​จำกัด และ​ราคา ส่วน availability คือ​ส่วน​ที่​แขก​จอง​ได้​จริง​ตาม​เงื่อนไข​ที่​แขก​ค้นหา ตัวอย่าง​ใน​เอกสาร​เป็น​ห้อง​ดับเบิล​ห้า​ห้อง รับ​ได้​ห้อง​ละ​สาม​คน เปิด​จอง​วัน​ที่ 1 ถึง 15 มกราคม แขก​ที่​ค้นหา​สำหรับ​สี่​คน หรือ​ค้น​ช่วง​วัน​ที่ 14 ถึง 16 มกราคม จะ​ไม่​เห็น​ห้อง​ชุด​นี้

บอท​ที่​ตอบ​ว่า "ยัง​มี​ห้อง​ว่าง" จาก​จำนวน​ห้อง​คง​เหลือ​อย่าง​เดียว จึง​พลาด​ได้​สาม​ทาง

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

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

บอท​ควร​ตอบ​เรื่อง​ห้อง​ว่าง​อย่างไร

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

เอกสาร​มี​สอง​กลไก​ที่​กระทบ​ระบบ​ที่​ดึง​ข้อความ​ไป​ให้​บอ​ทอ่าน

1. ข้อความ​ที่​ตรวจ​พบ​ฟิช​ชิง Booking.com แทน​เนื้อหา​ด้วย​คำ​ว่า "This message was deleted" และ​ลบ​ไฟล์​แนบ แต่​ยัง​ส่ง​ข้อความ​นั้น​มา​ใน API ตั้งแต่​เวอร์ชัน 1.3 มี​ค่า is_redacted บอก​ว่า​ข้อความ​ถูก​ลบ​เนื้อหา​หรือ​ไม่
2. ลิงก์​ที่​ไม่​ได้​อนุมัติ โรงแรม​ตั้ง​ค่า​ใน​เอ็กซ์​ทรา​เน็ต​ได้​ว่า​ลิงก์​ใด​ส่ง​ถึง​แขก​ได้ ลิงก์​ที่​ไม่​อยู่​ใน​รายการ​จะ​ถูก​ตัด​ออก​ทั้ง​จาก​ข้อความ​ถึง​แขก​และ​จาก​ผล​ของ API

เอกสาร​เตือน​ไว้​ตรง ๆ ว่า Booking.com ตรวจ​ข้อ​ความ​ฟิช​ชิง​ไม่​ได้​ทุก​ข้อความ ข้อความ​ที่​ไม่​ถูก​ลบ​จึง​ไม่​ได้​แปล​ว่า​ปลอดภัย และ​ข้อความ​ที่​ระบบ​ดึง​ไป​เก็บ​แล้ว​อาจ​ถูก​ลบ​เนื้อหา​ใน​การ​ดึง​ครั้ง​หลัง

บอท​ควร​ทำ​อะไร​กับ​ข้อความ​ที่​มี​ลิงก์​จาก​แขก

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

บท​นี้​อ่าน​จาก​เอกสาร​สำหรับ​ผู้​พัฒนา​ของ Booking.com ค่าย​เดียว มี​หลาย​เรื่อง​ที่​เอกสาร​ชุด​นี้​ไม่​ได้​ตอบ

1. OTA เจ้า​อื่น กติกา​ของ OTA แต่ละ​เจ้า​เป็น​ของ​ตัว​เอง บท​นี้​ไม่​ได้​ตรวจ​เอกสาร​ของ​เจ้า​อื่น
2. ข้อ​ตกลง​ระหว่าง​โรงแรม​กับ Booking.com เงื่อนไข​ใน​สัญญา​ของ​ที่พัก​ไม่​ได้​อยู่​ใน​หน้า​เอกสาร​ที่​ใช้
3. ช่วง​เวลา​ที่​ส่ง​ข้อความ​ได้ เอกสาร​กำหนด​ช่วง​ที่​โรงแรม​ส่ง​ข้อความ​ถึง​แขก​ได้​หลัง​เช็ก​เอา​ต์​หรือ​หลัง​ยกเลิก​ไว้​ด้วย บท​นี้​ไม่​ลง​ราย​ละเอียด​เพราะ​เป็น​อีก​เรื่อง​หนึ่ง
4. เวอร์ชัน​ของ API เอกสาร​แจ้ง​ว่า​จะ​เลิก​ใช้​วิธี​ดึง​ข้อความ​ล่าสุด​แบบ​เดิม และ​ให้​ใช้​บริการ​แจ้ง​เตือน​แทน ราย​ละเอียด​ทาง​เทคนิค​จึง​เปลี่ยน​ได้
5. ความ​เห็น​ของ​แขก​ต่อ​บอท เอกสาร​ไม่​ได้​พูด​ว่า​แขก​ต้อง​รู้​ว่า​กำลัง​คุย​กับ​บอท ส่วน​หน้า​บริการ​แช​ทบ​อท​ของ​ฟิจิ⁠ทัล​วาง​ไว้​ว่า​บอท​ต้อง​บอกแขก​ว่า​ตัว​เอง​เป็น​บอท ไม่​แกล้ง​ทำ​เป็น​พนักงาน

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

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

เงื่อนไข​เวลา​ตอบ​ของ Messenger และ LINE ซึ่ง​บอ​ทบน​สอง​ช่อง​นั้น​ต้อง​รองรับ อยู่​ในรับ​เซ็​ตระ​บบ Chatbot AI กับ​หน้าต่าง​เวลา​ที่​แพลตฟอร์ม​กำหนด ถ้า​พนักงาน​ภายนอก​เข้า​มา​ช่วย​ตอบ​แช​ทด้วย เรื่อง​การ​ให้​สิทธิ์​อยู่​ในบริการ​รับจ้าง​แอ​ดมิน​เพจ ให้​สิทธิ์​คนนอก​ดู​แล​แช​ท​แค่​ไหน ส่วน​ราคา​สมาชิก​สำหรับ​แขก​ที่​กลับ​มา​จอง​ตรง ต่อ​ได้ที่Loyalty Program โรงแรม ราคา​สมาชิก​บน Google แสดง​ได้​แค่​ไหน ขอบเขต​งาน​วาง​บอ​ทดู​ได้ที่​หน้าบริการ Chatbot

ใคร​ใน​โรงแรม​ควร​ดูแล​รายการ​คำขอ​นี้

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

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