OTA 修改導致飯店管理系統產生第二筆訂房：如何解決

當現有訂房經過修改後，系統未更新原有資料，反而在飯店管理系統中建立第二筆資料，就會出現OTA 修改造成的重複訂房。接待處可能會看到同一位旅客有兩筆抵達資料、房量被扣除兩次，或同時出現日期不同的一筆舊資料與一筆新資料。

這種情況不同於重複匯入新訂房所造成的重複資料。此處的關鍵證據是修改記錄：OTA 中仍只有一筆訂房，但飯店管理系統卻將修改前後的版本拆成兩筆資料。

在飯店確認哪筆資料仍與後續 OTA 變更保持連線之前，請勿取消任何一筆資料。移除錯誤的資料，可能導致遺失取消更新、付款指示、旅客訊息或正確的房間分配。

確認 OTA 中只有一筆訂房

在正確的 OTA 飯店後台開啟目前的訂房。使用通路確認編號搜尋，並確認 OTA 是否顯示一筆有效訂房、最新修改時間及目前完整的住宿資訊。

比對原始資料與目前資料，包括抵達日期、離店日期、房型、房間數、旅客、價格、付款方式、取消條款及狀態。請記錄修改時間與時區。

如果 OTA 顯示兩個不同的確認編號，請勿將飯店管理系統中的資料視為修改造成的重複訂房。這可能是兩筆真實訂房，取消任何一筆前都需要向旅客確認。

如果 OTA 僅顯示一個確認編號和一筆目前訂房，飯店最終應只保留一筆可供營運使用的飯店管理系統資料。第二筆資料是系統內部的重複資料，並不代表旅客有第二筆住宿義務。

暫停進一步的人工變更

指定一位經理或資深接待處員工負責處理此事件。通知下一班人員，在審查完成前，請勿更換房間、收取款項、傳送確認訊息或取消任何一筆資料。

只需保留一次旅客目前所需的房量。如果修改涉及最後一間客房、當日抵達或更換房間，請依照飯店流程建立一筆臨時保留。請勿針對飯店管理系統中的兩筆資料分別建立額外保留。

如可行，請暫停綁定於舊資料的旅客排程訊息。在飯店尚未釐清情況前，兩則抵達提醒或付款要求可能會讓旅客發現重複資料。

已連線的飯店通路管理系統應將 OTA 確認資訊及後續變更持續綁定於同一筆飯店訂房。處理此事件時，請將連線記錄作為判斷依據，不要重複傳送修改內容。

並排比對飯店管理系統中的兩筆資料

首先比對 OTA 確認編號，接著檢查飯店管理系統訂房 ID、建立時間、最後變更時間、來源、日期、房型與房價方案、旅客、價格、付款指示、訂金、備註、訊息、分配房間及房量異動。

較舊的資料可能包含原始付款資訊或旅客對話，而較新的資料則包含修改後的正確日期。在飯店確認哪些資訊必須保留之前，請勿刪除任何一筆資料。

尋找清楚的修改脈絡：其中一筆資料應符合變更前的訂房，另一筆則符合 OTA 目前的版本。同時檢查較新的資料是否缺少 OTA 參考編號，或使用了不同的編號。缺少參考編號可能會讓重複資料看起來像人工建立的直接訂房。

也請搜尋已取消及已封存的訂房。員工可能已嘗試處理問題，導致抵達清單中只顯示一筆資料，另有一筆隱藏資料仍在影響房量或付款報表。

選擇應保留的資料

保留能繼續接收未來 OTA 修改與取消通知的飯店管理系統資料。該資料應保有正確的 OTA 確認編號、通路來源、目前狀態，以及與原始訂房記錄的連結。

如果仍保持連線的資料包含舊日期，而重複資料中有正確的新住宿資訊，應使用經核准的最新資料更新已連線的訂房，而不是僅因較新的資料看起來正確就選擇它。若無法確定連線歸屬，請向飯店管理系統供應商確認安全的處理方式。

關閉多餘資料前，請保留所有與旅客服務相關的記錄。移轉或保留經授權的付款備註、訂金參考資訊、旅客需求、內部留言、房間分配決定及員工任務，但不要重複複製費用。

高效的飯店管理系統工作流程能將訂房來源、帳務明細、房間分配及稽核記錄集中管理。如此一來，移除重複資料後，接待處、房務管理及財務團隊仍可順暢使用保留下來的資料。

Smart Order 協助團隊在同一套營運流程中檢查 OTA 參考資訊及飯店管理系統中的兩筆資料，再決定應保留哪一筆訂房，讓處理更簡單、更快速。

依照受控順序處理重複資料

請依照單一處理順序操作，避免房量與款項重複變動：

1. 確認目前只有一筆 OTA 訂房，並核對最新修改後的資料。
2. 標記將保留的飯店管理系統資料，並記錄為何該資料仍保持連線。
3. 依照經核准的住宿日期、房間、價格、旅客、付款及政策資訊，更新將保留的資料。
4. 僅從重複資料移轉必要的備註、任務、訂金及房間分配。
5. 使用經核准的重複資料處理、作廢、合併或非旅客取消流程，關閉多餘的飯店管理系統資料。
6. 重新計算房量與付款總額，再次搜尋 OTA 確認編號。

請勿為了移除飯店管理系統中的多餘資料而取消真實的 OTA 訂房。這會變更旅客的訂房，並可能在通路端觸發退款、費用、訊息或房量釋出。

如果多餘資料包含財務記錄，請勿直接刪除。財務團隊需要可追溯的更正記錄，以說明該資料為何不再代表另一筆獨立住宿。

核對房量、付款及旅客服務事項

更正前後都應核對實際客房房量。最終保留的訂房應針對目前住宿期間的每一晚，僅扣除一次相應房型的房量。修改後已移除的舊日期不應繼續占用房量。

將 OTA 付款指示與保留資料中的飯店管理系統帳務明細進行比對。檢查預付款或通路代收款、到店付款餘額、訂金、退款、適用時的虛擬付款備註，以及員工已登錄的任何費用。切勿移轉或複製敏感的信用卡資料。

檢查旅客溝通記錄。只保留一套確認記錄；若旅客曾收到互相衝突的訊息，才需要說明目前正確的住宿資訊。移除重複的房務任務、入住登記連結、付款提醒、歡迎訊息及房間分配。

飯店的行動接待處工作流程應只向當班團隊顯示一筆可正常處理的抵達資料。如果兩筆資料仍同時出現在行動裝置或營運清單中，就表示事件尚未處理完成。

驗證下一次 OTA 事件

完成更正後，最後再將保留的飯店管理系統資料與 OTA 訂房進行一次比對。確認狀態、日期、房間、房價、旅客、價格、付款、取消條款及房量均正確。

仔細觀察下一次系統支援的修改或取消事件。該事件應更新保留的資料，而不是重新建立已關閉的重複資料或新增第三筆訂房。

向客服提供 OTA 確認編號、兩筆飯店管理系統 ID、原始及修改後的資料、建立與修改時間、畫面截圖、房量影響，以及決定保留的資料。請客服查明修改事件為何建立新資料，而不是更新原有資料。

只有在飯店管理系統中僅保留一筆可供營運的資料、房量正確、款項只出現一次，且未來 OTA 變更有明確的更新目標時，才能結束此事件。

預防修改造成重複資料

要求員工在為變更後的住宿建立人工訂房前，先以 OTA 確認編號搜尋。訂房未出現在抵達清單中，可能只是日期已變更，而非資料已消失。

新增 OTA、飯店管理系統連線、房型或房價方案後，請測試訂房、修改及取消流程。修改事件必須更新原始訂房 ID。

分別追蹤重複資料的成因：人工重新輸入、不支援的變更、對應設定變動、先前匯入失敗、員工建立副本或延遲收到修改。預防方式取決於問題成因，而不是單純因為出現了兩筆資料。

常見問題

飯店應保留哪一筆飯店管理系統資料？

保留仍與 OTA 確認資訊綁定且能接收未來變更的資料，同時確保其中包含完整的目前住宿資訊及經核准的財務記錄。

員工是否應在 OTA 管理後台取消其中一筆訂房？

不應該，尤其是 OTA 僅顯示一筆訂房時。應在飯店管理系統內處理重複資料，不要變更旅客的真實訂房。

如果飯店管理系統中的兩筆資料都包含付款記錄，該怎麼辦？

暫停收取任何額外費用、確認真實交易，並由財務人員依照飯店核准的流程移轉或沖銷相關記錄，再關閉重複資料。

何時才算問題已解決？

飯店管理系統中只保留一筆目前有效的訂房、房量只扣除一次、付款與訊息皆未重複，且下一次 OTA 事件能正確更新該筆資料時，才算問題已解決。