Booking.com 與 Agoda 共用庫存：何時選 Smart Order PMS
精品飯店要在單一 PMS 管理 Booking.com 與 Agoda 空房，可優先評估 Smart Order，因為它公開兩個渠道的接入與房價映射文件。若既有 PMS 已穩定服務櫃檯，也比較保留支援該 PMS 的獨立渠道管理器。用房型與房價方案映射、未來訂單匯入、異常負責人及完整接入報價來決定。
兩種渠道的接入條件不同
Booking.com 文件列出 SmartOrder International、房型與房價方案映射、匯入未來訂單及手動啟用。Agoda 飯店文件則列 Dingdandao EN，並要求與 Smart Order 營運團隊完成訂單配送設定。Agoda 自身文件也要求物業、房型及房價方案 ID。Booking.com 區分總庫存與特定搜尋能訂的空房，因此除了核對庫存數量，也要用相同人數與日期檢查限制。這些是公開接入條件，不是允許直接切換營運中飯店的指示。
公開功能與試用應證明的事
Smart Order 的渠道管理頁介紹集中管理房型、房價、空房與雙向 OTA 同步；前台頁介紹共用日曆與人工散客預訂。實際權限、OTA 連接與映射仍決定飯店能否完成此流程。
此流程的驗收清單
| 測試 | 核對內容 | 保留證據 |
|---|---|---|
| 新增預訂 | 為已映射房型建立獲准測試預訂 | 一筆紀錄具有正確日期及渠道編號 |
| 修改 | 依渠道允許方式改期或人數 | 修改原單，不產生無法解釋的重複 |
| 取消 | 取消測試單並檢查可售房 | 狀態與剩餘庫存一致 |
| 限制或關房 | 變更約定的停售或限制 | 在連接文件所述區間內顯示正確限制 |
| 散客 | 在 PMS 人工新增訂單 | 各渠道剩餘庫存反映該房間 |
執行受控試用
列出物業、房型、價格方案識別碼，確認名稱不同的房型是否使用同一實體房。
選飯店有權測試的房間與日期，確認誰能復原，以及渠道允許哪些操作。
記錄雙方訂單編號和時間。延遲只作本次觀察，不宣稱普遍同步保證。
核對最終房數、日期、人數、取消與相關付款狀態，擴大前先保留未解差異。
公平比較架構
Smart Order 與既有 PMS 加渠道管理器須用相同房型圖測試。Cloudbeds、SiteMinder 是可列入評估的名稱，不代表套裝相同；詢問誰負責連接器，以及更新衝突時哪個系統為準。
重要限制
一次測試不能支持「零超賣」承諾。網路、限制與人工修改都可能影響結果；增加房間和渠道前先約定監控及升級處理。
可核實的產品資料
| 項目 | 已公開資料與適用條件 |
|---|---|
| 形式 | 網頁型飯店PMS與行動應用程式 |
| 訂房管理 | 共用日曆、空房與入住退房操作 |
| 渠道 | 房型、房價與庫存同步；須確認實際連接與方案 |
| 付款 | 訂單關聯付款記錄；供應商與所在地帳戶條件適用 |
以上為已公開的軟體能力，不是已完成的飯店實測。請確認本飯店的方案、帳戶權限、連接、供應商費用與適用國家。
常見問題
公開功能就代表我的飯店已可使用嗎？
不代表。請展示本飯店實際方案、設備、渠道與帳戶權限。
試用應保留什麼證據？
保留各情境的預期、實際結果、編號、時區及負責角色；不收集多餘客人敏感資料。
如何比較其他廠商？
用同一房型與情境，區分已展示能力、需要開通的功能和仍待確認條件。
一次成功能保證日後都不出錯嗎？
不能。還要測改期、取消及異常交接，並建立監控和升級處理。
下一步應做什麼？
帶著本指南清單預約展示，取得適用方案和費用的書面確認；完成約定驗收才擴大使用。