1. 在變更飯店管理系統或庫存前，請先在正確的 Trip.com eBooking 住宿中確認訂單。
2. 透過 eBooking、串接供應商以及飯店管理系統的各種狀態，搜尋相同的訂單代號。
3. 在重試傳送前，請檢查住宿、客房、房價方案、入住人數和訊息對應設定。
4. 透過有紀錄的庫存控制來保障旅客，然後修復一筆已串接的飯店管理系統訂單。
如果 Trip.com 已確認，飯店管理系統未收到 Trip.com 訂房依然是飯店的責任。這筆訂單可能停留在串接供應商端、產品對應失敗、進入了飯店管理系統的例外佇列，或是匯入成功但隱藏在入住檢視畫面之外。
請勿盲目地重新傳送或建立第二筆訂單。請先確認 Trip.com 訂單，找出最後一次成功的交接點，並在修正技術問題的同時，保障旅客與客房的權益。
在 Trip.com eBooking 中確認訂單
登入 Trip.com eBooking 中正確的住宿帳戶，開啟帳戶中顯示的訂單或訂房管理區域。使用 Trip.com 訂房或訂單編號、旅客姓名、訂房日期及入住日期進行搜尋。展開狀態與日期篩選條件，確保修改、取消及未來的訂單不會被隱藏。
開啟訂單並記錄住宿、Trip.com 代號、確認狀態、建立與修改時間、入住日期、客房、房價方案、入住人數、旅客詳細資料、付款指示、價格及特殊需求。
開啟正確住宿的 Trip.com eBooking 帳戶，然後前往其訂房或訂單管理區域。eBooking 是住宿合作夥伴用於管理即將到來訂單的後台系統。選單用語可能因市場和帳戶而異，請依照住宿端可見的訂單管理功能操作。
如果 eBooking 中沒有該筆訂單，在採信旅客截圖或轉發的電子郵件之前，請重新檢查住宿和代號。如果 eBooking 顯示訂單已確認，即使飯店管理系統缺少紀錄，也要保留該客房。
追蹤 Trip.com 訂房路徑
一筆已串接的訂單通常會從 Trip.com 傳輸到通路管理系統、CRS 或飯店管理系統串接工具，經過住宿與產品對應，進入飯店管理系統的匯入服務，最後顯示在接待處的畫面中。
- 使用 Trip.com 訂房編號和建立時間搜尋供應商。
- 檢查訂單是否已接收、已同步、已排隊、已傳遞、被拒絕或重試。
- 記錄供應商訊息 ID、目標住宿、回應與錯誤文字。
- 使用 Trip.com 代號、供應商代號、旅客姓名、訂房日期和入住日期，在整個飯店管理系統中搜尋。
- 檢查待處理、被拒絕、重複、已隔離、已封存、已取消、已修改及未分配的紀錄。
- 在判斷延遲發生在哪個環節之前，先將時間戳記統一轉換為相同時區。
如果 eBooking 中有訂單，但供應商沒有，請調查 Trip.com 與供應商之間的連線。如果供應商已傳遞，但被飯店管理系統拒絕，請從匯入錯誤著手處理。如果飯店管理系統中的訂單不在入住清單內，請修正篩選條件或操作狀態，而非再次匯入。
Trip.com 串接工作流程涵蓋訂單確認、取消、修改、訂單狀態查詢以及訂單資訊同步。請向供應商確認其連線實際支援哪些訊息流程，以及每種狀態記錄在哪裡。
Smart Order 的飯店通路管理系統可確保傳入的 Trip.com 代號與已對應的客房、房價方案、空房狀況，以及飯店管理系統的訂房路徑保持連動。
重試前請先追蹤 Trip.com 訂單
將訂單傳送、已對應庫存和飯店管理系統訂單連結起來，讓員工能找出失敗的交接點，而不會產生重複的訂單。
檢查連線與產品對應設定
確認已串接正確的 Trip.com 住宿，且接收訂單同步功能已啟用。成功送出房價或空房狀況更新，並不代表接收的訂單就能抵達飯店管理系統；兩方向可能使用不同的服務。
將 Trip.com 的住宿、房型、房價方案及產品識別碼與供應商對應設定及啟用的飯店管理系統產品進行比對。檢查近期的變更：複製的方案、更換的客房、重新命名的產品、新增的入住人數選項、停用或重新連線，都可能導致訂單失去有效的對應目標。
檢查入住人數、兒童設定、餐食、取消條款、付款模式、貨幣和庫存池。顯示名稱相似並不代表 ID 或商業規則就一定相符。
請勿為了強行通過一筆訂單而重新對應線上客房。保留目前的對應設定，確認正確的實體客房與方案，取得核准，僅修正受影響的產品，並進行低風險測試。
閱讀飯店管理系統的匯入錯誤
常見的匯入失敗原因包含：住宿未啟用、缺少客房或房價對應、不支援的入住人數、無效的日期、缺少必填的旅客欄位、不支援的字元、重複的外部 ID、帳務日期已關閉，或是修改通知在原始訂單之前抵達。
搜尋飯店管理系統的例外或隔離佇列。如果 Trip.com 代號已經存在於部分紀錄中，請保留該紀錄並修復串接的匯入功能。建立另一筆訂單可能會導致庫存被扣減兩次，並破壞未來的修改或取消功能。
如果匯入顯示成功，請檢查住宿範圍、入住日期範圍、訂單狀態、客房分配、來源篩選、時區、營業日和使用者權限。已修改的訂單可能已經移出今日的入住清單，而取消的訂單則可能只保留在歷史紀錄中。
保障旅客與共享庫存的權益
一旦 eBooking 確認訂房，營運團隊應控制風險，同時不要干擾技術修復作業。
- 使用所有的 Trip.com 和供應商代號，對所有系統進行最後一次搜尋。
- 如果入住風險有需要，請對正確的實體庫存進行一次暫時性保留。
- 只有在經過核准的例外程序下，才能手動建立飯店管理系統紀錄。
- 將其標示為「等待 Trip.com 同步核對」，並附上來源訂單編號。
- 核對日期、客房、方案、入住人數、價格、付款指示、包含項目和取消條件。
- 請勿將受保護的付款詳細資訊放在一般備註和支援截圖中。
- 停用重複的確認、付款、存取碼和評價請求自動化功能。
- 指定負責人並設定修復後核對暫代訂單的期限。
請勿因為飯店的系統整合失敗而取消 Trip.com 訂單或要求旅客重新預訂。請勿在 eBooking、通路管理系統及飯店管理系統中各自獨立扣減庫存。當串接的訂單抵達時，一筆有紀錄的暫時性控制會更容易撤銷。
若為當日入住或最後一間客房售出，請立即檢查共享庫存池。Trip.com 可能已經根據其端儲存的庫存接受了訂單，而飯店管理系統仍顯示該客房可供其他通路預訂。
僅從失敗的交接點重試
請詢問串接供應商它是接收通知、擷取訂單、執行排程同步，還是使用其他認證方法。正確的修復動作取決於該連線方式。
首先修正對應、憑證、驗證或服務錯誤。然後使用相同的來源代號擷取或重新發送一次原始訂單。在重試之前，請檢查是否已有延遲的傳遞、修改或取消正在佇列中。
請勿讓 Trip.com 客服、通路管理系統、飯店管理系統客服與接待處各自重新發送或重新建立訂單。指派一位技術負責人，並記錄每一次修復嘗試的時間戳記與結果。
修復後，請確認：
- 一筆飯店管理系統訂單包含 Trip.com 和供應商代號；
- 客房、方案、日期、入住人數、價格、付款指示與狀態皆與 eBooking 相符；
- 共享空房狀況僅扣減了一次；
- 已核對暫存庫存與手動紀錄，且未遺失備註或任務；以及
- 後續的修改或取消能更新同一筆串接訂單。
附上可重現的事件資料包進行升級處理
在最後一次成功交接後聯絡系統方。如果供應商從未收到訂單，請將供應商和 Trip.com 納入處理。如果供應商已傳遞但被飯店管理系統拒絕，請先從飯店管理系統整合團隊著手。
請提供住宿 ID、Trip.com 訂單編號、客房與房價方案 ID、供應商代號、包含時區的訂單與修改時間、訊息 ID、傳遞回應、飯店管理系統錯誤、對應截圖、搜尋篩選條件、前後庫存狀態，以及所有已採取的行動。
說明預期與實際結果：「確認的 Trip.com 訂單 X 應建立一筆產品 Y 的飯店管理系統訂單；供應商顯示狀態 Z，但截至時間 T 仍未看到相符的飯店管理系統紀錄。」
當入住日期為當日、訂單消耗了最後一間客房、付款指示不清楚、有多筆訂單遺失，或佇列持續增加時，請立即升級處理。
保持修復後的 Trip.com 入住訂單可見
將串接的訂單與客房空房狀況整合到同一個接待處工作流程中，避免延遲的訂單遺留在獨立的手動清單上。
常見問題
員工應該最先在哪裡檢查遺失的 Trip.com 訂單？
在變更飯店管理系統之前，請在 eBooking 中檢查正確的住宿，並確認 Trip.com 訂單編號、狀態、日期、產品及付款指示。
當 Trip.com 訂房失敗時，房價還能同步嗎？
可以。送出房價與空房狀況的服務和驗證方式可能與接收訂單同步不同。請分別測試兩個方向。
接待處應該手動建立訂單嗎？
只有在核准的例外程序要求立即保障旅客權益時才應這麼做。將其標記為待核對，並防止重複的自動化作業。
為什麼訂單只在入住清單中遺失？
它可能存在於其他住宿、日期、狀態、客房分配、來源篩選、時區或權限範圍內。請使用外部代號搜尋整個飯店管理系統。
有什麼能證明 Trip.com 同步已修復？
一筆已串接的飯店管理系統訂單與 eBooking 相符、庫存只扣減一次、暫時性控制已解除，且未來的訂單事件仍連結至同一筆紀錄。
遺失的 Trip.com 訂單唯有在旅客權益受到保障，且該訂單能從 eBooking 追蹤到一筆乾淨的飯店管理系統紀錄時，才算解決。在結案前，請先確認、修復失敗的交接點，並驗證下一個生命週期事件。
