避免電話、OTA與自家預訂造成重複預訂｜小型旅宿房量管理步驟

小型旅宿可能在接電話時收到OTA通知，自家網站也有預訂進來。即使每個管道都正常運作，只要人工輸入延遲或整合停止，就可能發生重複預訂。

結論很簡單。

選定一本顯示正確空房狀況的台帳；受理電話預訂、變更、取消、包場的人，當場更新。

即使導入通路管理系統，也需要這套流程。本文將它整理成不熟悉IT的旅宿主人也能與家人、員工分享的形式。

重複預訂的五個原因

1. 電話預訂留待稍後輸入

只留下便條就回去接待客人，期間又有線上預訂進來。「稍後」是最危險的時間。

2. 房量有兩份權威原始記錄

若把紙本台帳與電腦、OTA管理畫面與預訂系統兩者都當成正確房量，就會產生差異。

3. 整合有時間差

收到預訂後，其他銷售管道可能需要一段時間才關閉銷售。iCal整合與API方式的同步範圍、反映方式不同。

4. 變更或取消只修正一邊

例如預訂台帳已修改日期，OTA或付款系統卻仍保留舊內容。

5. 只看預訂件數，不看房間

若不考量連住、房型、換房、清潔造成的暫停銷售，可能只有中間某天重疊。

預訂引擎、通路管理系統、PMS的角色，整理在這篇文章。

先選定一份「權威原始記錄」

權威原始記錄，是所有人判斷「這個畫面顯示空房，就可以銷售」的基準。

候選包括以下任一項。

通路管理系統的房量畫面
PMS或預訂管理系統的客房台帳
整合OTA與自家預訂的管理畫面

紙本台帳可作為系統停止時的臨時記錄或當天確認，但在線上銷售期間，只以紙本作為權威原始記錄很危險。

選定權威原始記錄時要問的問題

能否立即登錄電話預訂
OTA與自家網站預訂是否自動匯入
連住的所有日期能否一次停止銷售
能否封鎖包場、休館、維修中房間
能否從記錄確認由誰變更
能否用智慧型手機緊急操作
如何通知故障

選定後，要將紙本台帳、共用行事曆、各OTA畫面明確標示為「確認用」或「銷售管道」。

電話預訂用「30秒規則」先封鎖房量

受理電話預訂後，在詳細顧客資訊之前先封鎖客房房量。

確認旅宿名稱、希望日期、人數、晚數
用權威原始台帳確認空房
通話中登錄暫訂或正式預訂
輸入住客姓名與電話號碼
輸入方案、餐飲、房價、付款方式
複誦內容，傳送確認電子郵件或書面文件

若無法立即開啟管理畫面，應告知「確認空房後會回電」。不要只憑記憶或昨天列印的紙本就承諾。

放在電話旁的一張說明

開啟權威原始台帳的方法
新增預訂按鈕的位置
暫時保留期限
必填項目
故障時的記錄用紙
有疑問時的聯絡窗口

讓新人也能按同樣順序操作。

暫時保留一定要有期限

「與家人商量後回電」「團體人數未定」的預訂，若無限期封房，會失去銷售機會；但若不封鎖房量就等待，也可能重複預訂。

暫時保留應記錄下列項目。

住客姓名與聯絡方式
對象日期與客房
暫時保留原因
回覆截止日期與時間
負責人
到期後自動解除，還是由人確認

到期後改為「確定」「延長」「解除」其中一種，不要放著不管。

收到OTA預訂時的確認

即使有自動整合，看到通知的人仍要確認下列項目。

預訂已進入權威原始台帳
從抵達日至出發前一天的房量已封鎖
房型、人數、餐飲、房價正確
同一時間沒有其他管道的預訂
變更與取消也已反映到權威原始記錄

「收到預訂電子郵件」本身不能證明其他銷售管道已關閉房量，要查看權威原始記錄的客房行事曆。

自家網站預訂的確認

自家網站應區分預訂表單送出與預訂確定。

受理預訂請求：旅宿確認後才確定
即時預訂：符合空房與付款條件時自動確定

若將請求受理顯示成即時預訂，住客會以為已確定。畫面與電子郵件應明確標示「已受理」「確認中」「已確定」。

即時預訂也要測試付款成功與預訂確定的順序。不要漏看付款失敗卻只封鎖房量，或已付款卻沒有建立預訂的狀況。付款方式的選擇請參閱Stripe、Square與預訂系統標準付款功能比較。

變更與取消同時確認入口與權威原始記錄

受理變更後，先確認是否有能保留歷史的變更功能，再考慮刪除舊預訂重新建立。

日期變更

在權威原始記錄確認新日期的空房
先確保新房量
向住客說明房價與取消條件
變更預訂
確認舊日期已恢復可售
也確認OTA、電子郵件與付款的顯示

取消

確認預訂編號與本人資訊
判斷取消費
將預訂改為取消狀態
確認房量是否恢復可售
必要退款由人核准後執行
向住客傳送完成通知

避免只刪除預訂卻留下付款，或只退款卻繼續封房等單邊處理。

停售也要像預訂一樣登錄

下列情況也會占用客房房量。

維修或檢查
清潔來不及完成的日期
旅宿主人的休息日
整棟包場
領隊或員工使用的房間
災害或交通障礙造成休館

不要只用口頭或便利貼傳達，應在權威原始記錄登錄為「封房」，並留下原因與解除日期。

同步停止時的緊急步驟

發現整合故障後，要先控制新預訂流入，再調查原因。

儲存或列印權威原始記錄的目前房量
找出受影響的OTA與自家預訂
從可安全操作的銷售管道開始關閉房量
電話預訂按時間順序寫入緊急記錄用紙
每件新增、變更、取消逐一記錄
向服務商聯絡故障時間與症狀
恢復後，按時間順序比對權威原始記錄與各銷售管道
確認沒有問題再恢復銷售

剛恢復就批次覆寫，可能刪除故障期間的新預訂。請逐件核對。

緊急記錄用紙的項目

受理時間	管道	預訂編號	住客	住宿日期	客房	新增、變更、取消	已反映至權威原始記錄	負責人

含真實住客資訊的紙本應上鎖；恢復後輸入權威原始記錄，再按保管與銷毀規則處理。

每天早晚比對兩次

小型旅宿也至少要在開始營業時與預訂受理結束前比對。

早上確認

當天抵達、出發、連住
未付款、未確定、暫時保留
房間分配與清潔狀況
夜間收到的OTA與自家預訂
同步錯誤通知

傍晚確認

今天受理的電話預訂都在權威原始記錄中
變更與取消已反映到各銷售管道
明天以後的暫時保留期限
付款與預訂狀態一致
沒有漏解除停售

即使預訂很少，也留下已確認「沒有發生任何事情」的記錄，才能區分是否漏查。

每週一次確認的數字

各管道的新預訂件數
手動輸入的電話預訂件數
同步錯誤件數
從輸入到房量反映的時間
已到期暫時保留件數
未處理的變更、取消件數
發現房量差異的次數

只要發現一次差異，就應重新檢視哪種步驟能當場封鎖房量，而非責怪負責人。

決定家人與員工的角色

作業	主要負責人	不在時	最終確認
登錄電話預訂	受理者	接電話的人	傍晚負責人
確認OTA通知	預訂負責人	值班人員	早晚負責人
變更與取消	有權限的負責人	旅宿主人	旅宿主人
退款	旅宿主人或責任人	指定代理人	另一人核對
同步故障處理	系統負責人	服務商窗口	旅宿主人

避免「只有熟悉的人懂」的狀態，至少讓兩人能執行電話預訂、變更、取消、停止銷售。

請AI製作營運步驟的提示詞

為客房數［房間數］的旅宿製作防止重複預訂的步驟。
預訂管道為［電話、OTA名稱、自家網站］。
房量的權威原始記錄為［系統名稱］。

請將以下內容整理成一張步驟說明，讓不熟悉IT的員工也能使用。
- 通話中登錄電話預訂的步驟
- 暫時保留與期限管理
- 確認OTA與自家預訂的反映
- 日期變更與取消
- 封房
- 同步故障時的緊急記錄與停止銷售
- 早晚比對

不知道系統專用操作名稱時，不要推測，請保留為待確認事項。
不要使用真實顧客資訊或密碼作為例子。

AI製作的步驟，應由人用虛構預訂從頭到尾試做。