1. 在建立或取消任何內容之前,請先確認訂房是否存在於正確的 Traveloka TERA 物業中。
2. 追蹤從 Traveloka 到通路管理系統、對應層、飯店管理系統匯入佇列,以及抵達檢視的訂單。
3. 保護已確認的旅客與空房狀況,避免觸發重複匯入或重複的自動化訊息。
4. 只有在確認失敗步驟後才重試,然後驗證是否存在一筆飯店管理系統訂房,且空房狀況僅變更一次。
一筆 Traveloka 訂房未顯示在飯店管理系統中,並不一定代表 Traveloka 系統中斷。該訂單可能在 TERA 中已確認,但在通路管理系統延遲、被對應層拒絕、卡在飯店管理系統匯入佇列,或被抵達名單篩選器隱藏。
請將 Traveloka 記錄視為確認旅客是否擁有通路訂單的第一事實來源。接著追蹤每次的資料傳遞,避免重複匯入同一筆訂單。
在 Traveloka TERA 中確認訂房
登入 TERA,選擇正確的物業,並使用其 Traveloka 訂單或預訂 ID 搜尋該筆訂單。確認旅客姓名、入住日期、房型、房價方案、入住人數、訂單狀態、付款狀態、總額,以及建立或修改時間。
如果 TERA 中沒有該筆訂房,請勿僅憑旅客的螢幕截圖建立 飯店管理系統 訂單。請確認該訊息屬於同一物業,且來自授權的 Traveloka 通路。錯誤的飯店、取消的結帳嘗試或詐騙訊息都不應消耗您的空房狀況。
如果該訂房存在且已確認,請儲存識別碼並保護旅客權益。Traveloka 將 TERA 定位為合作夥伴監控訂單、入住登記、旅客需求與付款狀態的平台,並在營運設定中提供飯店訂房通知與通路管理系統整合功能。Traveloka 目前的 TERA 總覽 均支援這些功能。
2025 年 7 月推出的 TERA 首頁還包含「訂單總覽 (Booking Overview)」與左側導覽選單。請比對帳號中顯示的功能,而非依賴舊版的選單標籤。Traveloka 的介面更新文件已記錄該版面變更。
找出中斷的資料傳遞點
串接的訂單通常遵循單一路徑:Traveloka 確認訂單,連線供應商接收或擷取訂單,對應層識別物業、房型與房價方案,飯店管理系統匯入該訂單,最後抵達檢視顯示產生的記錄。
在每一層級檢查相同的訂單 ID。如果供應商日誌中缺少該 ID,問題指向整合上游。如果供應商成功傳遞但飯店管理系統拒絕,則指向下游。如果飯店管理系統完成匯入但未顯示在抵達名單中,則問題在於篩選條件或訂單狀態,而非資料傳輸。
請統一使用單一時區記錄時間戳記。否則,Traveloka 建立時間、供應商接收時間、飯店管理系統匯入時間與飯店當地時間,可能會讓正常的順序看起來像是延遲或錯亂。
Smart Order 的 飯店通路管理系統 將 OTA 訂房傳遞與飯店庫存記錄進行串接。當單一訂單可透過該路徑追蹤時,員工即可保護該客房,而無需維護第二個不受控制的匯入流程。
端對端追蹤單筆 Traveloka 訂單
將通路傳遞、已對應的客房庫存與飯店管理系統訂單保留在單一工作流程中,以便隔離遺漏的抵達記錄,而無需盲目重試。
檢查連線、對應與匯入規則
確認 Traveloka 針對正確物業的連線處於啟用狀態,且憑證或授權尚未過期。僅顯示綠色的帳號層級狀態是不夠的;請檢查個別的訂房傳遞方向,以及遺漏訂單前後最近一次的成功訂單。
比對 Traveloka 的物業、房型與房價方案 ID 是否與供應商的對應一致。相似的顯示名稱並不能證明兩者相等。即使房價與空房狀況持續更新,新增房型、複製房價、重新命名方案或重新連線物業,都可能導致訂單無法對應。
接著檢查飯店管理系統的匯入佇列與拒絕日誌。常見原因包括未對應的房型或方案、重複的來源 ID、無效的入住人數、缺少必填的旅客欄位、不支援的字元、已關帳的會計日期、非作用中的物業,或訂單更新早於原始預訂到達。
請勿為了強制匯入單筆訂單而隨意更改房型對應。請先確認實際庫存與商業條件;倉促的重新對應可能會將未來的 Traveloka 訂單分派到錯誤的房源池中。
檢查飯店管理系統是否隱藏了該訂房
透過 Traveloka ID、旅客姓名、抵達日期、訂房日期、電子郵件與供應商參考編號,在飯店管理系統中進行全域搜尋。該記錄可能存在於預設的抵達名單之外。
檢查物業、抵達日期範圍、訂單狀態、客房篩選、使用者權限、時區,以及該檢視是否排除了已取消、未分配、待處理或已匯入的訂單。在手動建立任何內容之前,也請搜尋重複與封存的記錄。
修改訂單可能會將入住時間移出今日的抵達視窗。取消訂單可能會將其從有效抵達名單中移除,但會保留訂房歷史記錄。時區轉換則可能將深夜的訂單歸類到前一天或次一天的營運日期。
如果飯店管理系統有來源 ID 但訂單詳細資訊不完整,請將其視為部分匯入。保留該記錄並透過整合工作流程修復缺失的欄位,而不是建立第二筆訂單。
安全地保護旅客與庫存
一旦 TERA 確認了該訂單,即使自動匯入尚未解決,也請保留正確的實際庫存。只有在飯店政策允許的情況下,才使用臨時營運保留或標示清楚的手動飯店管理系統記錄。
- 記錄 Traveloka ID 並將該項目標記為待通路核對。
- 對應已確認的房型、房價、日期、入住人數、付款狀態與旅客聯絡詳細資訊,同時避免儲存被禁止的付款資料。
- 透過指定來源鎖定一次庫存,並驗證無關的客房保持不變。
- 在任何臨時記錄上,停用重複的確認、付款、存取碼與評論自動化通知。
- 在整合恢復後,指派負責人與期限來取代、合併或撤銷臨時記錄。
請勿為了清理飯店管理系統而取消 Traveloka 訂房。請勿要求旅客重新訂房。內部的傳遞失敗不應改變有效的通路合約,也不應讓旅客面臨第二次扣款的風險。
重試時避免建立重複訂單
在重試之前,請確認供應商是否將 Traveloka 訂單 ID 作為冪等性或重複控制鍵,並確認後續的修改或取消是否已在佇列中。盲目重播可能會建立兩筆飯店管理系統記錄,或導致事件套用順序錯亂。
從最早確認失敗的點開始重試。如果供應商從未收到訂單,請使用其核准的擷取或升級通報路徑。如果飯店管理系統拒絕了該訂單,請修正特定的對應或驗證錯誤,然後將同一個來源事件重播一次。
恢復後,請再次進行全域搜尋。應有一筆飯店管理系統訂單包含 Traveloka 來源 ID、正確的房型與房價、目前狀態、付款資料以及修改歷史。空房狀況應僅變更一次—不應因為臨時保留變更一次,又因為匯入的訂單再次變更。
僅能透過核准且保留稽核軌跡的工作流程來合併或撤銷臨時記錄。轉移客房分配、備註、訂金、任務與旅客通訊記錄時,不應中斷已串接訂單未來的更新連結。
提供可重現的證據進行通報升級
將完整的事件資料包傳送給負責的供應商。內容應包含物業與 Traveloka ID、房型與房價方案代碼、訂單狀態、建立與修改時間、供應商訊息 ID、傳遞確認、飯店管理系統錯誤文字、對應截圖、搜尋篩選條件、前後的庫存狀況,以及已採取的行動。
說明預期結果與實際結果:「已確認的 Traveloka 訂單 X 應在房型 Y 與房價 Z 下建立一筆飯店管理系統訂單;截至時間 T,未看見飯店管理系統記錄或被拒絕的訊息。」這樣的描述比單純的「訂單遺失」更具可操作性。
若遇到當日抵達、最後一間庫存、付款狀況不明、多筆訂單遺失或佇列不斷增加的情況,請立即通報升級。將接待處與收益管理工作與技術調查分開,以確保旅客與庫存持續受到保護。
常見問題
員工應該先去哪裡檢查遺漏的 Traveloka 訂房?
在更改飯店管理系統之前,請先在 Traveloka TERA 中檢查正確的物業,並確認訂單 ID、狀態、日期、房型、房價、入住人數與付款狀態。
在訂房匯入失敗時,房價還能同步嗎?
可以的。輸出的房價與空房狀況可能會使用與輸入訂單不同的傳遞方向或流程。請分別測試並監控這兩個流程。
接待處應該手動輸入訂房嗎?
只有在飯店政策要求立即進行營運保護時才這麼做。將其標記為待核對,使用 Traveloka 來源 ID,防止重複的自動化作業,並規劃好匯入後要如何解決該記錄。
為什麼訂房只有在抵達名單中消失?
飯店管理系統可能將其包含在不同的物業、日期、狀態、客房、權限範圍或時區下。在診斷為傳輸失敗之前,請先進行全域搜尋。
多次重試匯入安全嗎?
不安全。請先找出失敗的步驟並確認防重複控制機制。重複重播已確認的事件可能會產生重複記錄,或導致修改處理順序錯亂。
什麼情況能證明問題已解決?
有一筆串接的飯店管理系統訂單與 TERA 吻合、目前的修改已呈現、庫存僅變更一次、臨時保留記錄已核對完成,且後續的更新皆依循同一個來源記錄。
當訂房在營運上受到保護,且在技術上可追蹤時,遺漏的 Traveloka 抵達記錄即算解決。請先確認 TERA,隔離中斷的傳遞點,僅修正該問題點,最後以一筆乾淨的飯店管理系統記錄結案。