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

> ที่มา: https://phygital.co.th/insights/chatbot-hotel-resort-channel-manager-ota-agency · เผยแพร่ 18 สิงหาคม 2567 · อ่าน 12 นาที · โดย PARANATH PANARATANA

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

## Key Takeaways

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

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

แหล่งที่ใช้คือเอกสาร Connectivity APIs ของ Booking.com สองหน้า ได้แก่ [หน้าอธิบาย Messaging API](https://developers.booking.com/connectivity/docs/messaging-api/understanding-the-messaging-api) และ [หน้าการจัดการข้อความ](https://developers.booking.com/connectivity/docs/messaging-api/managing-messages) กับ [หน้า Rates & Availability](https://developers.booking.com/connectivity/docs/ari) ผู้เขียนเปิดอ่านทั้งสามหน้าในวันที่ 27 กันยายน 2569 ส่วนผู้เขียนเอง บริษัท ฟิจิทัล เอเจนซี จำกัด (PHYGITAL AGENCY) ทำงานวางบอทบนแชทของธุรกิจ แต่ไม่ได้เป็นผู้ให้บริการเชื่อมต่อของ Booking.com และไม่ได้รับเชื่อม Channel Manager ส่วนที่เชื่อมกับ OTA จึงเป็นงานของผู้ให้บริการระบบที่โรงแรมใช้อยู่

## ข้อความจาก Booking.com เข้าถึงบอทของโรงแรมได้ทางไหน

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 ได้ไหม                | ใครควรเป็นคนตัดสิน                         |
| -------------------------------------- | ----------------------------------- | ---------------------------------------------- |
| เวลาเช็กอินหรือเช็กเอาต์         | ได้ ตอบเป็นข้อความ                | พนักงาน ถ้าต้องดูห้องที่แม่บ้านทำเสร็จ |
| ที่จอดรถ                             | ได้ ตอบเป็นข้อความ                | บอทตอบได้ถ้าโรงแรมมีกติกาชัด            |
| ประเภทเตียงที่ต้องการ               | ได้ ตอบเป็นข้อความ                | พนักงาน เพราะขึ้นกับห้องที่เหลือ          |
| เตียงเด็กอ่อนเพิ่ม                  | ได้ ตอบเป็นข้อความ                | พนักงาน เพราะขึ้นกับของที่มีจริง         |
| เตียงเสริม                            | ได้ ตอบเป็นข้อความ                | พนักงาน เพราะอาจมีค่าใช้จ่าย              |
| เลื่อนวันเข้าพัก                    | ไม่ได้ ต้องตอบในเอ็กซ์ทราเน็ต | พนักงานหรือผู้จัดการ                        |
| ขอยกเว้นค่ายกเลิก (Cancel for less) | ไม่ได้ ต้องตอบในเอ็กซ์ทราเน็ต | ผู้จัดการ เพราะเป็นเรื่องเงิน              |

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

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

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

## ห้องว่างในระบบกับห้องที่แขกจองได้

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

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

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

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

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

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

## ข้อความที่ Booking.com ลบหรือตัดลิงก์ออก

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

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

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

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

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

## สิ่งที่เอกสารของ Booking.com ไม่ได้ครอบคลุม

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

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

## แบ่งงานในแชทก่อนเปิดบอท

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

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

เงื่อนไขเวลาตอบของ Messenger และ LINE ซึ่งบอทบนสองช่องนั้นต้องรองรับ อยู่ใน[รับเซ็ตระบบ Chatbot AI กับหน้าต่างเวลาที่แพลตฟอร์มกำหนด](https://phygital.co.th/insights/ai-chatbot-setup-agency) ถ้าพนักงานภายนอกเข้ามาช่วยตอบแชทด้วย เรื่องการให้สิทธิ์อยู่ใน[บริการรับจ้างแอดมินเพจ ให้สิทธิ์คนนอกดูแลแชทแค่ไหน](https://phygital.co.th/insights/admin-page-customer-service-agency) ส่วนราคาสมาชิกสำหรับแขกที่กลับมาจองตรง ต่อได้ที่[Loyalty Program โรงแรม ราคาสมาชิกบน Google แสดงได้แค่ไหน](https://phygital.co.th/insights/loyalty-program-hotel-resort-pms-agency) ขอบเขตงานวางบอทดูได้ที่หน้า[บริการ Chatbot](https://phygital.co.th/solutions/chatbot)

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

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

## สรุป

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

## คำถามที่พบบ่อย (FAQ)

### ที่พักไม่ถึง 20 ห้อง ต้องใช้ Messaging API ไหม

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

### ให้บอทปฏิเสธคำขอยกเว้นค่ายกเลิกอัตโนมัติได้ไหม

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

### ถ้าแขกส่งข้อความเดียวกันทั้งใน Booking.com และใน LINE ของโรงแรม ควรทำอย่างไร

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

### แขกขอเช็กอินก่อนเวลา ให้บอทรับปากไปก่อนได้ไหม

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

### ไฟล์แนบจากโรงแรมส่งผ่าน API ได้ใหญ่แค่ไหน

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

### บอทที่ดึงข้อความผ่านผู้ให้บริการเชื่อมต่อ จะเห็นชื่อแขกไหม

ขึ้นกับเวอร์ชัน เอกสารระบุว่าเวอร์ชัน 1.2 ส่งชื่อแขกมาในข้อมูลผู้ส่ง ส่วนบทสนทนาก่อนการจองยืนยันยังไม่มีชื่อแขกจนกว่าการจองจะเกิดขึ้น

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

PHYGITAL AGENCY ไล่รายการคำขอจริงของโรงแรมร่วมกับหัวหน้าแผนกต้อนรับ แยกงานของบอทกับงานของคน แล้ววางจุดส่งต่อพร้อมสรุปคำขอบน LINE OA Messenger หรือหน้าเว็บของโรงแรม

- [นัดประชุมผ่าน Google Meet](https://calendar.app.google/DotQdE7Ca8LZG6Us5)
- [เพิ่มเพื่อนใน LINE](https://lin.ee/J8Qq8Do)