重試 OTA 匯入產生了重複的訂房：如何安全地修復

重試後出現重複的 OTA 訂房看起來似乎很容易修復：找到兩筆相似的記錄並刪除其中一筆。但這是有風險的。一筆記錄可能是已連結的訂房，將接收未來的 OTA 變更，而另一筆則可能包含接待處已完成的排房、付款、備註或入住登記作業。

安全的應對方式是暫停自動化操作，證明這些記錄為重複項，選擇一筆主要訂房，轉移或保留營運數據，然後使用飯店管理系統批准的操作來撤銷多餘的記錄。由於移除記錄可能會釋出房間或改變餘額，因此必須立即進行庫存與付款檢查。

為什麼 OTA 重試會建立重複的訂房

重試通常應重複使用 OTA 的外部訂房 ID，以便 飯店管理系統 識別出是同一筆訂單。當最初的匯入部分成功但傳回錯誤、重試時沒有相同的識別碼，或是手動佔位記錄在延遲的自動訂房進入飯店管理系統之前建立時，就可能會出現重複的情況。

另一種常見的情況始於手動匯入的未來訂房。如果手動記錄不包含有效的來源訂房 ID，後續的 OTA 修改可能無法與之匹配。飯店管理系統可能會建立一筆新的已連結記錄，而不是更新現有的手動記錄。

這兩筆飯店管理系統記錄看起來可能完全相同，但運作方式卻不同。可能只有一筆仍與 OTA 的修改、取消、旅客訊息、付款指示或虛擬信用卡資料保持連結。這就是為什麼僅憑旅客姓名和入住日期不足以決定要移除哪一筆記錄。

一旦發現重複，應立即停止重複的匯入、重發及手動更改空房狀況。在其他訊息改變證據之前，截取並記錄兩筆訂房編號、建立時間、來源 ID、目前狀態及對庫存的影響。

證明這兩筆記錄實際上是重複的

同一位旅客和相同日期的兩筆訂單只能算是疑似重複。旅客可能有意預訂兩間客房，或者兩位同姓氏的旅客可能一起抵達。不同的 OTA 確認號碼通常意味著兩筆獨立的訂單，除非 OTA 證明並非如此。

逐一欄位比較兩筆記錄：

• OTA 確認號碼與通路管理系統或 CRS 參考編號
• 飯店管理系統訂房編號、建立時間、匯入方法及來源
• 住宿、房型、抵達、退房、入住人數及房價專案
• 總價、稅金、付款模式、訂金及取消政策
• 最新的修改、取消、訊息及同步狀態
• 排房、帳單、備註、任務及入住登記活動

開啟 OTA 後台並確認有多少筆有效的訂房。然後檢查通路管理系統或 CRS 佇列。如果 OTA 和中介平台顯示一筆訂單，但飯店管理系統顯示兩筆具有相同外部參考編號的記錄，則這些飯店管理系統記錄很有可能就是重複項。

如果這些記錄具有不同的 OTA 確認號碼，請停止操作。在 OTA 或旅客確認是否兩筆都是有意預訂之前，請勿合併、取消或刪除其中任何一筆。短暫保留庫存的成本通常低於取消一筆有效訂房的代價。

連貫的工作流程使這種比較變得更容易。Smart Order 的 飯店通路管理系統 會將傳入的 OTA 參考編號與飯店管理系統的空房狀況連結起來，讓員工能夠追蹤重試是更新了現有的訂單，還是建立了另一筆營運記錄。

選擇主要記錄並安全地修復重複項

主要訂房是指飯店將保留作為該次住宿單一來源的記錄。它應該能夠接收未來的 OTA 變更，並保留退房登記前所需的營運與財務歷史記錄。

請使用下方的矩陣作為決策輔助。由於各供應商的運作方式不同，在合併、刪除、作廢或取消記錄之前，可能仍需要主管或客服的批准。

在許多重試事件中，帶有有效 OTA 來源 ID 的自動化記錄是較安全的主要記錄，因為後續的修改和取消可以與之匹配。沒有該來源 ID 的手動佔位記錄通常是要被撤銷的記錄——但必須在其有用的數據被保留之後才能進行。

請遵循以下順序：

1. 凍結這兩筆記錄的進一步重試、編輯、入住登記操作及付款嘗試。
2. 根據有效的來源連結和未來的更新路徑選擇主要記錄。
3. 保留或轉移排房、旅客備註、任務、帳單項目、訂金及已授權的付款參考。
4. 使用飯店管理系統批准的狀態、合併、作廢、取消或刪除操作，將多餘的記錄標記為重複項。
5. 當系統保留重複項的歷史記錄時，在兩筆記錄中新增交叉引用備註。
6. 重新開啟 OTA、通路管理系統及飯店管理系統，以確認只剩下一筆有效的營運訂房。

請勿僅為了清理飯店管理系統而取消 OTA 訂房。未經財務和管理階層審查，請勿刪除包含已入帳收益、付款授權、已入住登記狀態、房間權限或財務文件的記錄。某些系統需要客服協助才能安全合併，因為可見的訂房與隱藏的交易及訊息記錄相關聯。

核對庫存、付款與接待處工作

直到飯店的營運總數正確無誤之前，移除重複項的工作都不算完成。如果兩筆記錄都減少了空房狀況，撤銷其中一筆可能會返還一間客房。如果只有一筆減少了空房狀況，手動增加庫存可能會額外釋放一間客房供銷售，進而造成超額訂房。

在修正前記錄空房狀況，完成已批准的重複項操作，然後將飯店管理系統的房間數量與通路管理系統及 OTA 進行比較。最終的數量應該反映一次已確認的住宿——而不是零次，也不是兩次。

分別審查付款與帳單活動。確認是否有任何一筆記錄包含訂金、預授權、扣款、退款、OTA 代收餘額、虛擬信用卡指示、稅務發票或佣金基數。切勿將完整的信用卡或安全資料複製到一般的訂房備註或客服電子郵件中。

同時核對每筆記錄已經觸發的工作。檢查旅客訊息、抵達前的自動化操作、排房、房務管理備註、機場接送、餐飲需求、存取碼及入住登記表。抑制重複的工作流程，以免旅客收到兩份確認信、兩次付款要求或相互衝突的指示。

在夜間稽核之前，再次透過旅客姓名和每個外部參考編號進行搜尋。確認有一筆有效的住宿、一次排房、一個營運餘額以及正確的通路歸屬。保留稽核軌跡，以顯示保留了哪一筆記錄及其原因。

升級處理事件並防止再次發生重試重複

當團隊無法識別已連結的記錄、當兩筆記錄都包含交易，或是當取消一筆記錄會意外改變庫存時，請升級處理。飯店管理系統或連線服務供應商可能需要檢查訊息 ID、傳遞確認、匯入日誌及重試行為。

傳送給客服：

• 住宿 ID 與連線服務供應商
• OTA、通路管理系統及兩筆飯店管理系統的訂房參考編號
• 包含時區的原始匯入、錯誤、重試及重複建立的時間戳記
• 目前的狀態、房間與房價映射，以及前後的空房狀況
• 隱藏敏感付款資料的訊息與錯誤截圖
• 已採取的行動，包含付款、入住登記、排房或取消

永久的修復方法取決於原因。如果缺少外部來源 ID，則需要更好的 ID 保存機制。如果是成功匯入後發生逾時，則需要在重試前進行狀態檢查。手動佔位記錄需要一個核對標記。如果是並行處理缺陷或重複的 Webhook，則需要供應商端的重複保護，而不是另一個接待處的權宜之計。

將此規則納入飯店的事件處理程序中：在員工確認第一則訊息是否已建立訂房之前，請勿進行重試。利用新的訂單、修改和取消來測試新的 OTA 連線。修改應更新同一筆飯店管理系統記錄，而取消應歸還庫存一次。

當接待處可以同時看到訂房來源、營運狀態及空房狀況時，清理重複項會更安全。Smart Order 的 飯店櫃台管理系統 為員工提供了一個日曆來檢視已連結的訂房及其對房間的影響，降低了臨時佔位記錄變成第二筆有效住宿的機率。

常見問題

飯店應該保留哪一筆重複的 OTA 訂房？

通常應保留帶有有效 OTA 來源 ID 以及有效修改或取消連結的記錄。在撤銷另一筆記錄之前，請保留其中包含的任何付款、帳單、排房、備註、任務及入住登記工作。

接待處可以直接刪除較新的訂房嗎？

不可以。較新的記錄可能是由恢復的匯入所建立的自動化、已連結訂房。刪除它可能會中斷未來的 OTA 更新，同時留下一個未連結的手動記錄。

飯店應該在 OTA 後台取消其中一筆訂單嗎？

當 OTA 只顯示一筆已確認的訂單時不應該這麼做。重複項可能只存在於飯店管理系統內部。取消真實的 OTA 訂房可能會影響旅客、付款、佣金及取消條款。

如果兩筆記錄都已包含扣款怎麼辦？

請停止進一步的付款活動並讓主管或財務團隊介入。確認哪些扣款已獲授權、是否發生了任何重複請款，以及飯店管理系統是否需要作廢、退款、帳單轉移或供應商協助的合併。

為什麼重試會建立新的飯店管理系統記錄，而不是更新第一筆？

常見原因包含遺失或變更的外部訂房 ID、原始匯入成功但傳回錯誤、沒有來源參考編號的手動佔位記錄、重疊的重試處理程序，或是無法與第一筆記錄匹配的修改。

飯店應如何驗證修正結果？

確認飯店管理系統中有一筆有效的訂房、OTA 中有一筆已確認的訂單、一個已連結的參考路徑、一次正確的房間扣除，以及一個營運餘額。然後測試未來的修改是否會針對保留的記錄進行。

安全的重複項修復方法會在清理資料庫之前保留旅客的真實訂房。識別已連結的記錄、保護資金與營運、正確修正一次庫存，並留下稽核軌跡，以防止下一次重試變成另一個接待處的緊急事件。