Tiket.com 訂房未顯示在您的飯店管理系統中：疑難排解指南

一筆 未顯示在飯店管理系統中的 tiket.com 訂房，只要 tiket.com 已確認，它仍然是一筆有效的訂房。錯誤可能發生在 Extranet 與 通路管理系統 之間，通路管理系統與飯店管理系統之間，或是位於飯店管理系統的匯入佇列中。這筆訂房也可能已經存在，只是在入住檢視中被隱藏了。

不要一開始就重新發送或手動輸入訂房。請確認通路紀錄，在每個系統中追蹤相同的識別碼，並在不建立第二筆訂單的情況下保障旅客權益。

在 Tiket.com Extranet 中確認訂房

登入 正確的桌面版 Extranet 飯店帳號。開啟 訂房 > 搜尋訂房，然後透過行程 ID 或旅客姓名進行搜尋。擴大日期範圍，並查看已確認、已修改和已取消的狀態，而不是僅依賴今天的儀表板。

Lignum by tiket.com 行動應用程式提供了另一種驗證途徑。開啟 訂房，在 入住登記 與 訂房 之間切換，選擇相關的日期範圍，並透過旅客姓名或行程 ID 進行搜尋。Tiket.com 的訂房搜尋指南與 Lignum 訂房指南說明了這些目前合作夥伴端的檢查步驟。

開啟該筆訂房並記錄飯店、行程 ID、訂房狀態、建立與修改時間、入住日期、房型、房價專案、入住人數、旅客詳細資訊、付款指示與特殊要求。使用通路紀錄來確認旅客是否擁有有效的訂房；將飯店管理系統作為營運操作的目的地。

如果 tiket.com 找不到該筆訂房，在根據旅客截圖或轉寄電子郵件採取行動前，請重新檢查飯店和識別碼。如果 tiket.com 顯示其為已確認，即使傳遞問題尚未解決，也應保障旅客的住宿權益。

追蹤訂房交接過程

一筆已連線的訂房通常會從 tiket.com 傳遞至通路管理系統或連線供應商，透過產品對應，進入飯店管理系統的匯入服務，最後進入入住檢視。請使用一個行程 ID 來測試該傳遞鏈。

1. 在連線供應商系統中搜尋 tiket.com 的行程 ID 與訂房時間戳記。
2. 檢查它是否已被接收、排隊中、已傳送、遭拒絕或重試。
3. 擷取供應商的訊息 ID、目的地飯店、回應與錯誤文字。
4. 透過行程 ID、供應商參考編號、旅客姓名、訂房日期與入住日期，在整個飯店管理系統中進行搜尋。
5. 檢查待處理、失敗、重複、隔離、已取消、已封存與未分配的紀錄。
6. 在決定延遲發生在哪裡之前，請在同一時區下比較所有時間戳記。

如果 tiket.com 有該筆訂房但供應商沒有，則中斷點位於供應商上游。如果供應商已傳送但飯店管理系統拒絕了它，請調查匯入錯誤。如果飯店管理系統包含該訂單但不在入住名單中，請修正篩選條件或營運狀態，而不是再次匯入。

Smart Order 的 飯店通路管理系統 將傳入的 OTA 參考編號與對應的房況庫存以及飯店管理系統訂房路徑綁定，讓您能更輕鬆地定位最後一次成功的交接。

檢查連線與產品對應

確認 tiket.com 連線對於正確的飯店是啟用狀態，並且已啟用訂房傳遞方向。近期成功的房價更新並不能證明傳入的訂房功能正常；這兩個流程可能使用不同的服務。

比較 tiket.com 飯店、房型與房價專案識別碼與通路管理系統對應及啟用中的飯店管理系統產品。在房型被重新命名、專案被複製、產品被停用或飯店重新連線後，請特別注意。僅顯示名稱相符是不夠的。

檢查入住人數、兒童設定、餐飲、取消條款、定價模式與幣別。供應商可能會收到訂房，但因為組合的房型專案產品沒有有效的飯店管理系統目的地，或因為不支援某個必填數值而拒絕它。

不要單純為了強行讓一筆訂房通過而重新對應上線中的房間。請確認實體房況庫存池與商業條件，儲存舊的對應，取得批准，並在低風險的產品上測試修正後的對應。

檢查飯店管理系統匯入與入住規則

在更改資料之前，請閱讀確切的飯店管理系統拒絕原因。常見原因包括停用的飯店、缺少房型或房價對應、無效的入住人數、重複的外部 ID、不支援的字元、缺少必填的旅客欄位、已結帳的營業日，或是修改通知在原始訂單之前到達。

如果未顯示拒絕訊息，請在預設的入住名單之外進行搜尋。檢查飯店範圍、入住範圍、營業日、時區、訂房狀態、房間分配、來源篩選條件與使用者權限。一筆已修改的訂單可能已移出今天的視窗，而取消的訂單可能只保留在歷史紀錄中。

如果來源 ID 已經存在，請保留部分匯入紀錄。修復或重播該筆已連線的紀錄，而不是建立第二筆無法接收後續修改或取消通知的訂房。

保障旅客與房況庫存

當 tiket.com 確認訂房時，接待處在技術調查持續進行期間需要一個營運保障措施。

1. 使用行程 ID 最後一次搜尋每個系統。
2. 透過飯店批准的例外處理程序保留正確的實體房間。
3. 僅在因應即將入住而符合政策規定的情況下，才建立臨時的飯店管理系統紀錄。
4. 將其標示為 待處理 tiket.com 同步核對 並包含外部參考編號。
5. 準確複製日期、房型、房價、入住人數、付款方式、取消條款與包含項目。
6. 在臨時紀錄上停用重複的確認、付款、存取碼與評論自動化作業。
7. 指派負責人與截止日期，以便在復原後進行合併或撤銷。

不要因為內部交接失敗而取消已確認的通路訂房，或要求旅客重新預訂。不要在多個系統中獨立減少房況庫存。記錄一筆臨時管控，然後在連線的訂單抵達時進行核對。

電子郵件是有用的備用警報，但不能作為飯店管理系統已成功接收的證明。Tiket.com 會向具有管理員或訂房權限的使用者發送新訂房電子郵件；其訂房電子郵件指南說明了權限、地址或黑名單問題可能如何阻擋這些訊息。請將修正電子郵件路由問題與整合事件分開處理。

重試一次並證明已復原

向連線供應商詢問其是否接收推播通知、擷取訂單或使用其他批准的方法。復原動作必須與該連線方式相符。

請先修正特定的錯誤。然後使用相同的行程 ID，重播或擷取原始事件一次。在重試之前，請確認沒有延遲傳遞或後續修改正在排隊。多名員工重複相同的動作可能會產生重複的飯店管理系統紀錄，或導致訊息處理順序錯誤。

僅在以下情況下才算完成復原：

• 一筆飯店管理系統訂房包含正確的 tiket.com 與供應商參考編號；
• 房型、專案、日期、入住人數、價格、付款指示與狀態與 Extranet 相符；
• 共用池中的房況庫存確實只減少了一次；
• 臨時保留或手動紀錄已被核對，且沒有遺失備註或任務；並且
• 後續的修改或取消仍可更新相同的連線紀錄。

提交升級處理時請附上飯店 ID、行程 ID、房型與專案識別碼、包含時區的時間戳記、供應商訊息 ID、對應設定截圖、飯店管理系統錯誤文字、前後的房況庫存，以及已採取的每一個動作。對於當日入住、最後一間空房庫存、多筆遺失的訂單或不斷增加的排隊佇列，請在營運端保障旅客權益的同時立即向上升級處理。

常見問題

員工應該先在哪裡檢查遺失的 tiket.com 訂房？

在 訂房 > 搜尋訂房 或 Lignum 的 訂房 區域檢查正確的飯店。在變更飯店管理系統之前確認行程 ID 與狀態。

當訂房失敗時，房價還能同步嗎？

可以。輸出的房價與空房狀況可能與傳入的訂房傳遞使用不同的方向或服務。請獨立驗證這兩個流程。

接待處應該手動建立訂房嗎？

僅在經過批准的例外處理程序需要立即保護時才這麼做。將其標記為待核對，防止重複的自動化作業，並在夜間稽核前搜尋延遲連線的訂房。

為什麼訂房只有在入住名單中遺失？

它可能位於其他飯店、日期、狀態、房間分配、時區或權限範圍之下。請透過外部參考編號與旅客姓名搜尋整個飯店管理系統。

什麼能證明問題已解決？

一筆連線的飯店管理系統訂房與 tiket.com 相符，空房狀況只更改過一次，臨時管控已被核對，且未來的訂房事件能更新同一筆紀錄。

當旅客權益受到保障，且訂房可端到端追蹤時，遺失的 tiket.com 訂房問題才算解決。請先確認通路紀錄，僅修復失敗的交接點，並以一筆乾淨的飯店管理系統訂房結案。