飯店訂房引擎中途放棄訂房：找出旅客付款前的流失環節

離開飯店訂房引擎的旅客，原因各不相同。有些人找不到合適的客房，有些人無法輸入電話號碼，還有人看到總金額時，才發現付款條件與預期不同。

經營者需要找出實際存在的障礙。全面調降房價，無法解決手機上的表單故障；重新設計首頁，也無法恢復因誤設而關閉的可售房源。

本文檢視的是付款前的訂房流程。若旅客已開始付款卻遭拒付，應調查付款問題，而非將其歸類為中途放棄訂房。

確認訂房流程已納入追蹤

請網站與訂房引擎的管理人員提供一份簡明的訂房流程報表，分別列出日期搜尋、搜尋結果出現可售方案、選擇客房或房價、開始結帳，以及抵達付款步驟等階段。

明確記錄各階段的定義。在網站上點擊訂房按鈕，不等於已選擇客房；進入付款頁面，也不代表旅客已提交付款資料、完成付款或確認訂房。

追蹤機制需要正確設定。若訂房引擎會在另一個網址開啟，請供應商確認跨網站的流程銜接是否採用一致的計數方式。瀏覽器隱私選項與同意設定，也可能限制可觀測的資料。不要將未被追蹤的訪客直接視為已確認放棄訂房。

抽樣比對已確認的直接訂房與追蹤紀錄中的完成結果。若確實有訂房，報表卻未顯示任何完成紀錄，應先修正追蹤機制。對於到店付款方案，已確認的訂房沒有線上付款紀錄，也可能是正常情況。

不要將旅客姓名、電子郵件地址、信用卡資料或付款憑證傳送至一般網站分析工具。經營者需要的是各階段的計數，以及可供授權核對使用的安全訂房識別碼，而非旅客的私人付款資訊。

逐一分析飯店訂房引擎各階段的流失情況

以下是假設案例：在一個已結束的檢視期間內，共追蹤到 240 次訂房流程。每次流程在各階段僅計算一次，且後一階段的流程均包含於前一階段之中：

• 240 次搜尋了日期。
• 180 次獲得至少一項可售客房方案。
• 72 次選擇了客房與房價。
• 36 次開始進入填寫旅客資料的結帳流程。
• 24 次抵達付款步驟。

這些數字代表訂房流程次數，不一定是 240 位不同的旅客。不能讓某個階段因重複載入頁面與搜尋客房而膨脹，另一個階段卻以不重複訪客計算。應設定一致的完成時間範圍，避免過早將較晚完成的流程計為流失。

第一個落差是 60 次搜尋沒有出現可售結果。這首先是空房狀況的問題，尚不能據此判定結帳設計有問題。從 180 次出現方案到 72 次選擇方案的落差更大，但部分訪客可能只是在比較日期與價格。

從表單到付款的階段中，36 次開始結帳的流程有 12 次未抵達付款步驟，約占 33.3%。若實際使用者無法完成必填欄位，就值得關注。這並非飯店的整體訂房放棄率，此案例也不是產業基準。

在資料量足夠的情況下，比較行動裝置與桌上型電腦、流量來源及入住日期。小樣本可以提供測試方向，卻不足以確認持續存在的轉換問題。

核對已確認的訂房結果

訂房引擎顯示旅客可以選擇哪些方案；飯店的營運紀錄則顯示哪些流程最終成為訂房。解讀缺少完成紀錄的情況時，應分清楚兩者的用途。

透過串接飯店管理系統的飯店訂房引擎，完成的直接訂房會進入飯店的物業管理軟體。在 Smart Order 中，直訂方案以目前的空房狀況與房價為依據，產生的訂房則會顯示於接待處供人員查看。運用這項串接核實最終結果，避免將每一筆缺少網站確認紀錄的情況都視為旅客流失。

依流失環節採取可執行的檢查

搜尋結果沒有合適的客房

使用旅客實際搜尋的日期與人數重新查詢。檢查客房容納人數、兒童年齡、最少入住晚數、已關閉的房價方案，以及未開放銷售的客房。即使飯店仍有空房，特定搜尋條件下仍可能沒有可訂方案。

將公開搜尋結果與經核准的可售房源核對。若飯店確實已客滿，顯示無空房就是正確結果。若設定有誤，應修正特定限制或客房方案，而非一律開放所有房源。

若系統支援，可提供其他日期或合適客房作為替代選項。不要宣傳實際上無法預訂的替代方案。

旅客看到客房，卻未選擇房價方案

檢查旅客是否無須開啟多個頁面，就能了解方案內容。床型配置、入住人數、早餐、取消條款與住宿總金額，都應方便比較。

依照廣告或客房頁面中的條件重新搜尋。若找不到宣傳中的方案，應先修正落差，再判斷是否為價格過高。刪除容易造成混淆的重複方案前，先確認保留的房價選項仍能滿足旅客的實際需求。

旅客開始填寫表單，卻未抵達付款步驟

使用一般手機完成表單。測試不同國家的姓名與電話號碼格式、日期變更、錯誤訊息，以及返回上一步時已輸入的資料是否會消失。

與供應商一起找出非必要的必填欄位，同時保留飯店處理訂房或遵循適用規範確實需要的資訊。不要只為縮短結帳流程，就移除必要的身分驗證或付款安全措施。

在一般行動網路連線下檢查載入情況。回報修正需求時，應提供具體畫面、欄位、裝置與測試結果，而非只說整個訂房引擎很慢。

旅客在查看總金額或轉至付款時離開

以首次訂房旅客的角度檢視最終確認頁面。頁面應說明扣款幣別、必付費用、目前應付金額、之後需支付的任何餘額，以及取消條件。訂金不應突然看起來像一筆未經說明的全額預付款。

確認畫面顯示的飯店線上付款選項，確實適用於受測市場與該筆訂房。若旅客提交付款後無法完成驗證或遭拒付，應另行記錄，交由付款團隊處理。

以完整訂房測試驗證一項修正

設定明確的測試住宿條件，並遵循供應商核准的測試程序。未事先議定計畫前，不要反覆產生實際扣款，或占用所剩不多的可售客房。

1. 使用相同日期、入住人數、方案與裝置，重現已識別的問題。
2. 進行一項範圍明確的調整，例如修正電話欄位，或讓訂金說明更清楚。
3. 重新操作訂房流程，通過受影響的階段，並在獲得授權的情況下完成測試訂房。
4. 核實訂房確認資訊與產生的接待處訂房紀錄，包括日期、客房、房價、付款安排，以及任何必要的房源庫存調整。

接著比較調整前後條件相近的訂房流程，並同時考量流量品質、裝置組成、各日期的空房狀況與促銷活動。若同期間有大型新行銷活動改變了訪客組成，就不能將成效改善歸因於按鈕的優化。

不要聯絡每一位曾輸入電子郵件地址的訪客。任何挽回訂房的訊息，都需要具備獲准聯絡的依據、正確的訂房狀態，以及清楚的後續行銷退訂方式。切勿透過一般電子郵件索取信用卡資料。

有用的結果應是具體發現：具備訂房條件的流程在哪個階段流失、確認了什麼障礙、做了哪些調整，以及是否有更多旅客順利完成該階段，同時未產生訂房或付款錯誤。