1. 首先確認 Booking.com 是已建立訂房、留下待處理的請求，還是已完全拒絕此次訂房嘗試。
2. 比對 Booking.com 與飯店管理系統中的確切住宿物業、房型、入住日期及房間數量。
3. 在確認訂房是否成立以及庫存是否已變更前，請勿將房間重新上架銷售。
4. 若已確認的訂房未出現在飯店管理系統中，請先保留房間並保障旅客權益，再要求復原訂房資料。
關於 Booking.com 訂房失敗的庫存問題，通常源自一則語意不清的訊息：旅客表示付款失敗、Booking.com 顯示訂房請求未完成，或飯店系統回報無法接收該筆訂房。
這些情況造成的庫存結果並不相同。遭拒絕的訂房嘗試可能完全不會產生訂房；待處理的請求可能暫時影響空房狀況；而已確認的 Booking.com 訂房即使從未出現在飯店管理系統中，仍是飯店必須履行的有效訂房。
最安全的處理方式是先核實訂房，再清點房間。請勿只依賴電子郵件的措辭、旅客提供的螢幕截圖，或飯店管理系統內的警告訊息。
確認「失敗」實際代表的情況
在 Booking.com 後台中開啟正確的住宿物業，並使用旅客姓名、入住日期、訂房日期及任何可用的確認編號搜尋訂房區域。擴大日期與狀態篩選範圍，以免待處理、已取消、已修改或未來的訂房遭到隱藏。
若已有確認訂房編號，在該筆訂房正式取消前，應將房間視為已售出。飯店管理系統匯入失敗並不會取消旅客在 Booking.com 上的訂房。
若帳戶顯示待處理的訂房請求，在請求進入最終狀態前，請勿將房間承諾給其他旅客。飯店也應避免在該請求獲接受前，先於飯店管理系統中建立已確認的訂房。
若 Booking.com 中沒有任何訂房，也沒有確認編號，請重新檢查住宿物業與日期。旅客的付款嘗試或結帳錯誤，不足以證明飯店訂房已成立。
檢查 Booking.com 上確切產品的庫存
必須依照旅客實際選擇的房間檢查庫存。飯店可能設有數個名稱相近的房型，或在同一實體庫存池中連結多個房價方案。
開啟 Booking.com 日曆並查看受影響的入住日期。選擇相同房型，記錄目前每一晚顯示的空房數量。若旅客要求多間客房，應核對完整數量，而不能只確認該日期是否仍可預訂。
接著檢查其他房價方案、入住人數選項或房間類別是否仍在銷售。即使受影響房型的庫存已正確扣除，公開搜尋頁面仍可能顯示飯店尚有空房。
請勿將公開訂房頁面視為唯一的庫存紀錄。它適合用於最後的銷售檢查，但空房狀況也可能受到銷售限制、最短住宿天數、旅客人數及搜尋條件影響。
比對 Booking.com 與飯店管理系統的房間數量
使用 Booking.com 確認編號、旅客姓氏、訂房日期、抵達日期及房型搜尋整個飯店管理系統。搜尋範圍應包含已取消、待處理、未分配、已修改、已匯入及錯誤紀錄。
請依照以下作業順序處理：
- 進行任何修正前，先記錄飯店管理系統中的實際可用客房數量。
- 確認失敗或已確認的 Booking.com 訂房是否已存在於飯店管理系統的任何位置。
- 確認受影響房型在每一個入住晚間是否已扣除正確的房間數量。
- 針對相同房型與日期，比對 Booking.com 日曆與飯店管理系統的空房狀況。
- 釐清 Booking.com 與飯店管理系統的數字後，再檢查其他通路。
- 記錄處理結果，以及核准任何手動調整的員工姓名。
若 Booking.com 顯示已確認訂房，但飯店管理系統中沒有紀錄，請依照飯店政策建立一項臨時庫存管控措施。請勿在多個系統中分別重複扣除同一間客房。
當管理人員能在同一套作業流程中查看 OTA 訂房及其造成的房間數量變化，就能更快速判斷房間是被扣除一次、兩次，還是完全未扣除。Smart Order 的飯店通路管理系統可將新進訂房與共享空房狀況連結，協助員工在其他通路售出客房前，快速保留正確房間並降低超額訂房風險。
讓 Booking.com 庫存與每筆訂房保持連動
查看新進訂房如何即時改變空房狀況，並有效處理例外情況，避免同一間客房遭到重複新增或扣除。
根據檢查結果選擇安全的處理方式
訂房已確認，且庫存已扣除一次
保持房間關閉銷售。若該筆訂房未出現在飯店管理系統的抵達名單中，請搜尋所有狀態，並要求飯店管理系統或通路管理系統供應商復原原始訂房。請勿恢復空房數量。
訂房已確認，但庫存未扣除
立即透過飯店平常使用的庫存系統保留該房間。依照飯店核准的例外處理流程，將已確認訂房加入營運抵達名單，接著要求復原原始訂房，同時避免建立重複紀錄。
沒有訂房，但庫存已減少
檢查相同日期是否存在其他已確認訂房、維修封房、團體保留房、手動調整或待處理請求。只有在確定庫存減少的原因後，才能恢復庫存。
訂房嘗試失敗，且庫存沒有變化
通常無須進行任何飯店訂房處理。若旅客仍希望預訂該房間，請他們透過 Booking.com 的正常流程重新完成訂房。請勿僅依據付款失敗的螢幕截圖手動建立 OTA 訂房。
庫存遭重複扣除兩次
搜尋飯店管理系統中的重複紀錄及重複的手動封房。保留真正有效的訂房，只移除已確認重複的管控項目，並確認所有已連接通路目前皆顯示正確的剩餘空房數量。
避免代價最高的兩種錯誤修正
第一個錯誤，是因飯店管理系統顯示匯入失敗便將房間重新上架銷售。Booking.com 可能仍保有已確認訂房，使飯店面臨超額訂房風險。
第二個錯誤，是在延遲傳入的原始訂房仍可能抵達時，先建立新的飯店管理系統訂房並手動扣除庫存。飯店最終可能因同一位旅客產生兩筆紀錄及兩次庫存扣除。
請指定一位管理人員核准修正作業。接待處、收益管理人員、Booking.com 客服及系統供應商不應各自重建或重新傳送同一筆訂房。
若旅客將於當日抵達，或涉及最後一間可售客房，請優先保障旅客。臨時保留房間比處理已確認 OTA 旅客的超額訂房更容易撤銷與補救。
確認所有系統中的庫存皆正確
完成任何修正後，請重新開啟 Booking.com 訂房與日曆，確認目前的訂房狀態、房型、房間數量及日期。
接著重新開啟飯店管理系統日曆，確認該筆訂房只存在一筆，且空房數量只變更一次。使用相同日期與入住人數進行旅客端搜尋，確認目前仍可銷售的房間。
若飯店使用多個 OTA，請確認其他已連接通路上的共享房間數量。重點並非讓每個畫面顯示完全相同的文字，而是確保每個通路都從正確的剩餘實體庫存中銷售。
在下一次訂房變更（例如取消或修改）正確傳入同一筆飯店管理系統紀錄前，請勿結束此事件的追蹤。
需要支援時應提供哪些資料
請向負責的供應商提供一份精簡且便於處理的紀錄，包括住宿物業名稱、Booking.com 確認編號（如有）、旅客姓名、房型、入住日期、房間數量、目前的 Booking.com 狀態、飯店管理系統搜尋結果、調整前後的庫存，以及顯示差異的螢幕截圖。
請用清楚直接的語言說明預期結果。例如：「這筆已確認訂房應占用一間豪華雙人房，但飯店管理系統仍顯示所有房間皆可預訂。」這比要求多個團隊「檢查同步狀況」更有助於快速解決問題。
常見問題
Booking.com 付款失敗是否一定代表沒有訂房？
不一定。請在住宿物業的 Booking.com 後台確認訂房狀態。付款問題、待處理請求、修改失敗及訂房傳送至飯店管理系統失敗，都可能產生不同結果。
飯店是否應立即將房間重新上架銷售？
不應。請先確認沒有任何有效或待處理的 Booking.com 訂房占用該房間，並確認庫存減少並非來自其他訂房或飯店封房。
若 Booking.com 的資料正確，但飯店管理系統的數量有誤，該怎麼辦？
先保障已確認的訂房，透過飯店平常使用的管控節點修正共享庫存，並要求負責的系統供應商復原原始訂房紀錄。
飯店如何確認事件已處理完成？
系統中應只有一筆目前有效的訂房，庫存應只反映一次扣除，且 Booking.com、飯店管理系統及所有已連接銷售通路都應顯示正確的剩餘房間數量。
