สี่ความสามารถที่สำคัญ
หัวข้อที่มีชื่อว่า “สี่ความสามารถที่สำคัญ”| ความสามารถ | ความหมาย | ทำไมผลิตภัณฑ์ถึงหยุดชะงักหากไม่มี |
|---|---|---|
| อัตราค่าบริการและความพร้อมใช้งานแบบสด | ราคาปัจจุบันและสิ่งที่สามารถจองได้จริง ตามช่วงวันที่ | อัตราที่แคชไว้ล้มเหลวตอนยืนยันและทำให้ความน่าเชื่อถือลดลง |
| การสร้างการจอง | สร้างการจองจริงที่โรงแรมได้รับ | หากไม่มีจะเป็นแค่ลิงก์แนะนำ ไม่ใช่ผลิตภัณฑ์ |
| การชำระเงิน | รับเงินเป็นส่วนหนึ่งของการจอง | การส่งต่อไปยังเว็บไซต์อื่นทำให้การแปลงเป็นศูนย์ |
| การยืนยันและเว็บฮุค | แจ้งผู้เข้าพัก โรงแรม และระบบของคุณว่าการจองเกิดขึ้นแล้ว | รองรับภาระงานและช่องว่างในการกระทบยอดข้อมูล |
API “โรงแรม” ส่วนใหญ่ที่นักพัฒนาพบจะครอบคลุมแค่ข้อแรกและบางครั้งข้อที่สอง ธุรกรรมเป็นส่วนที่ยาก และเป็นส่วนที่ตัดสินว่าคุณมีผลิตภัณฑ์หรือไม่
ซัพพลายของใครที่คุณกำลังรวมเข้าด้วยกัน?
หัวข้อที่มีชื่อว่า “ซัพพลายของใครที่คุณกำลังรวมเข้าด้วยกัน?”คำถามนี้กำหนดทุกอย่างที่ตามมา ซัพพลายที่ขายต่อผ่านโซ่จะมาพร้อมกับมาร์กอัปในอัตรา ความพร้อมใช้งานที่ล้าสมัย และไม่มีเส้นทางกลับไปยังโรงแรมสำหรับคำถามเกี่ยวกับการจอง ซัพพลายที่มาจากโรงแรมโดยตรงจะมีอัตราของโรงแรมเอง ความพร้อมใช้งานแบบสด และโรงแรมที่รู้ว่ามีการจองเกิดขึ้น
สำหรับสิ่งใดก็ตามที่ผู้เดินทางจะเปรียบเทียบกับเว็บไซต์ของโรงแรมเอง — ซึ่งเป็นส่วนใหญ่ — ซัพพลายที่ควบคุมโดยโรงแรมจะหลีกเลี่ยงช่วงเวลาที่น่าอึดอัดใจเมื่อราคาของคุณแย่กว่า
ใครคือผู้ค้ารายหลัก
หัวข้อที่มีชื่อว่า “ใครคือผู้ค้ารายหลัก”ถ้าคุณสร้างการจองโรงแรมเอง การเป็นผู้ค้ารายหลักหมายถึงการรับผิดชอบเรื่องการชำระเงิน การเรียกเก็บเงินคืน การคืนเงิน การจัดการภาษี และบ่อยครั้งต้องมีใบอนุญาตเป็นตัวแทนท่องเที่ยวในแต่ละตลาด
บน Wink โรงแรมยังคงเป็นผู้ค้ารายหลัก และการชำระเงินจะถูกเก็บสำหรับโรงแรม ดังนั้นผู้รวมระบบจึงไม่ต้องรับภาระนี้ การจัดการผู้ค้ารายหลักมีให้ใน API integrations ที่พันธมิตรต้องการรับชำระเงินเองจริง ๆ และเส้นทางนั้นมีข้อกำหนดใบอนุญาตของตัวเอง
ระดับการรวมสามระดับ
หัวข้อที่มีชื่อว่า “ระดับการรวมสามระดับ”- เว็บคอมโพเนนต์. วางการค้นหาที่จองได้ รายการห้อง หรือเช็คเอาต์ลงในหน้าที่มีอยู่แล้ว ไม่ต้องทำงานแบ็กเอนด์; ควบคุมเลย์เอาต์ได้น้อยที่สุด
- REST API. ควบคุมเต็มที่ทั้งการค้นหา อัตรา การสร้างการจอง และการยืนยัน พร้อมการยืนยันตัวตนด้วย OAuth2 ใช้เมื่อเส้นทางการจองเป็นส่วนหนึ่งของประสบการณ์ผลิตภัณฑ์ของคุณเอง
- เซิร์ฟเวอร์ MCP. ความสามารถเดียวกันที่เปิดเผยให้เอเจนต์ AI เพื่อให้ผู้ช่วยสามารถค้นหา ตั้งราคา และทำการจองแทนที่จะส่งผู้ใช้ไปยังเว็บไซต์
ทั้งสามระดับไม่ใช่สิ่งที่แยกจากกัน — ผลิตภัณฑ์มักใช้คอมโพเนนต์สำหรับหน้าการตลาดและ API สำหรับกระบวนการหลัก
สิ่งที่ควรสร้างก่อน
หัวข้อที่มีชื่อว่า “สิ่งที่ควรสร้างก่อน”- ค้นหาและตั้งราคาในเมืองเดียวและช่วงวันที่เดียว. ให้ได้อัตราจริงก่อนออกแบบอะไร
- สร้างการจองทดสอบหนึ่งรายการตั้งแต่ต้นจนจบ รวมถึงการชำระเงินและการยืนยัน
- สมัครรับ
booking.createdและเหตุการณ์การยกเลิก ก่อนสร้าง UI ใด ๆ บนระบบ - ตัดสินใจโมเดลการอ้างอิงของคุณตั้งแต่เนิ่น ๆ — บริบทแหล่งที่มาต้องเดินทางพร้อมกับการจอง มิฉะนั้นรายงานจะเป็นการคาดเดาในภายหลัง
- จัดการกรณีล้มเหลว: ความพร้อมใช้งานหายไประหว่างการเสนอราคาและการจอง, การชำระเงินถูกปฏิเสธ, การคืนเงินบางส่วน
ราคาที่นักพัฒนาควรรู้
หัวข้อที่มีชื่อว่า “ราคาที่นักพัฒนาควรรู้”API Consumer และ Booking Engine ใช้งานฟรี ส่วน Partner API มีโควต้า 10,000 คืนโรงแรมฟรีต่อเดือน จากนั้นคิดค่าบริการตามหน่วย การจองที่ยืนยันแล้วมีค่าธรรมเนียมแพลตฟอร์ม 1.5% ของโรงแรมบวกค่าธรรมเนียมบัตรตามต้นทุน และมี ค่าคอมมิชชั่นเริ่มต้น 10% เมื่อผลิตภัณฑ์ของคุณเป็นตัวขับเคลื่อนการจอง — ซึ่งเป็นวิธีที่ผู้รวมระบบได้รับรายได้แทนที่จะจ่ายเงิน
ข้อผิดพลาดที่พบบ่อย
หัวข้อที่มีชื่อว่า “ข้อผิดพลาดที่พบบ่อย”- สร้างบนอัตราที่แคชไว้. ดูดีในระหว่างพัฒนาแต่ล้มเหลวในโปรดักชัน
- ปล่อยให้การชำระเงินเป็นการเปลี่ยนเส้นทาง. ทุกการส่งต่อทำให้การจองหายไป
- ไม่สนใจเว็บฮุคจนกว่าจะเปิดตัว. การกระทบยอดกลายเป็นงานด้วยมือ
- กลายเป็นผู้ค้ารายหลักโดยไม่จำเป็น. เป็นการตัดสินใจเรื่องใบอนุญาตและความรับผิดชอบ ไม่ใช่แค่เรื่องเทคนิค
- ไม่ส่งผ่านบริบทแหล่งที่มา. การอ้างอิงไม่สามารถสร้างใหม่ได้ภายหลัง