1. 變更限制前，請先確認旅客確切的入住日期、退房日期、房型、入住人數與房價方案。
2. 入住日規則、退房日規則與最少住宿晚數各有不同作用，請一併檢查。
3. 恢復您希望銷售的住宿安排後，再測試仍需限制的住宿安排是否維持無法預訂。
即使 Booking.com Extranet 中的客房有庫存，也已設定房價，仍可能無法接受某位旅客選定的日期。問題可能出在住宿日期與晚數的組合，而非客房數量。
清除限制前，請先寫下您希望接受的訂房條件。「兩位成人，週五入住、週日退房，入住標準雙人房，選擇可彈性取消的純住宿方案」是實用的測試條件；「重新開放週末訂房」則過於籠統。
記錄無法預訂的搜尋條件，確認規則由哪個系統管理
使用相同的入住日期、退房日期、旅客人數與年齡、客房數量及房價適用資格重新搜尋。記錄是整個房型都未顯示，還是只有預期的房價方案未出現。
確認每個住宿晚間都有實際可售庫存。編輯房價方案前，先檢查房型是否已關閉銷售：即使開放其中一個方案，也無法讓已關閉的房型恢復銷售。若未設定房價或可售客房數為零，移除最少住宿晚數限制也無法解決問題。
接著，確認飯店是在 Extranet 中管理這些限制，還是透過已串接的飯店管理系統與通路管理系統管理。若住宿業者已完成系統串接，請確認具體有哪些規則由串接系統管理。避免在兩個系統中進行互相衝突的修改。
保留目前設定與原定的營運規則。為活動期間刻意設定的限制，即使會拒絕短期住宿，也不代表設定有誤。變更飯店可接受的銷售條件前，請先取得核准。
限制設定分散在不同位置時，員工可能會修改到錯誤的銷售方案。請使用飯店通路管理系統確認已連結的房型與房價，再進行系統支援的通路設定變更。Smart Order 將房價、空房狀況與已串接的訂房整合於同一作業流程，讓團隊能對照預期銷售的方案與正確的客房庫存，減少憑相似名稱猜測造成的錯誤，提升作業效率。
確認受限方案對應的房型
變更通路規則前，先檢查已連結的客房庫存與房價，再驗證您希望在 Booking.com 銷售的確切住宿安排。
對照實際日期，判讀 Booking.com Extranet 限制
以下列假設的週末情境，了解搜尋為何無法找到可預訂方案。每個範例皆假設庫存充足、房價有效，且沒有其他阻擋訂房的條件。
CTA 限制當日開始入住，並非所有涵蓋該日期的住宿
CTA 指禁止當日入住。週六的入住限制會阻止週六開始的新住宿，但單憑這項限制，並不會阻止週五入住的旅客續住至週六晚間。
若預期銷售的是週五入住、週日退房的方案，清除週六的入住限制可能不會帶來任何改變。此時應檢查週五的入住設定，以及影響該次住宿的其他規則。
CTD 適用於退房日期
CTD 指禁止當日退房。即使該次住宿不包含週日晚間，週日的退房限制仍會阻擋以週日為退房日的搜尋。
週五入住、週日退房的搜尋會占用週五與週六晚間的客房。若週日禁止退房，這項搜尋可能無法預訂，但週五入住、週一退房則可能符合條件。請勿將禁止週日退房與關閉週日晚間客房庫存混為一談。
最少住宿晚數可依入住日或住宿涵蓋日期判定
MinLOS 指最少住宿晚數。若週五設定依入住日判定、至少住宿三晚，便會拒絕週五入住、週日退房的兩晚住宿。
依住宿涵蓋日期判定的最少晚數規則則不同：只要實際住宿包含受限日期，即使更早入住，規則仍會生效。若涵蓋週六的住宿須至少入住三晚，即使週五依入住日判定的最少晚數僅為一晚，同樣的週五入住、週日退房搜尋仍可能無法預訂。
請檢查規則的判定依據，而不只是晚數。針對旅客實際住宿晚間設定的限制，與入住日規則不同；退房日不會額外計為一個住宿晚數。
各自有效的規則，組合後可能導致方案無法銷售
若同一筆預期住宿同時受到最少三晚與最多兩晚的限制，就沒有任何符合條件的住宿晚數。清除 CTA 也無法解決這項衝突。
處理方式是在核准範圍內，對衝突規則進行最小幅度的修正，無須清除整個日曆的限制。更新獲系統接受，僅代表設定已儲存或傳送，並不代表規則組合後就能讓旅客完成訂房。
修正日曆，同時保留有效的管控規則
請使用飯店平時進行設定修改的系統。在 Extranet 中，開啟受影響住宿的日曆，找到房型、房價方案與相關限制欄位。版面配置與可用的控制選項會因帳戶及日曆檢視方式而異。
- 選取確切的相關日期，包括該規則涉及的入住日、實際住宿晚間或退房日。
- 確認您正在編輯的是房型，還是特定的房型與房價組合方案。
- 將已儲存的入住日、退房日、最少與最多住宿晚數規則，與核准的銷售條件進行比對。
- 僅修改造成衝突的數值或關閉設定。儲存前，請再次確認受影響的日期範圍。
- 依照該系統支援的流程儲存，再重新開啟日曆，確認已儲存的數值，而非尚未儲存的輸入內容。
若無法使用該欄位，請由通路負責人向 Booking.com 或串接服務供應商確認支援的控制方式。請勿以全面停售取代僅針對入住日的限制，也不要為了清除欄位而自行填入未經確認的數值。
擴大開放銷售前，請使用接待處訂房日曆確認實際已承諾的訂房與客房安排。切勿忽略維修中的客房或已售罄的晚間，貿然放寬原本刻意設定的限制。
逐一檢查相關房價方案，別只看最低房價
可彈性取消的純住宿方案與含早餐方案，可能顯示不同的搜尋結果。請比對旅客實際嘗試預訂的方案，以及其可預訂日期、入住人數與適用條件。
若某個房價由另一房價衍生，請檢查哪些規則會繼承，哪些則獨立管理。房價相互連結，不代表所有限制都相同。請檢查適用的上層方案與該特定方案，避免開放不相關的產品。
促銷活動同樣需要符合資格的基礎方案，以及活動本身有效的適用條件。若相關規則仍不接受某種住宿安排，請勿試圖透過折扣繞過限制。
請保留刻意設定的差異。若飯店希望彈性取消方案接受兩晚住宿，而促銷方案要求三晚，較短晚數的搜尋就不應顯示促銷房價。目標是讓方案條件清楚易懂，而非讓所有設定完全一致。
同時驗證應允許與應阻擋的搜尋
重新開啟已儲存的設定後，再次執行原本的搜尋。確認旅客能選取預期的房型與房價，且價格、入住人數、餐食及取消條款均符合預期。
接著執行另一組應維持無法預訂的搜尋。若核准的最少住宿晚數為三晚，請在其他相關條件皆相同的情況下，測試三晚可預訂、兩晚無法預訂。若另一項合理規則會阻擋較長晚數的搜尋，請改用能單獨驗證目前規則的測試條件。
在飯店的直訂引擎中成功搜尋到可預訂方案，並不能證明 Booking.com 套用了相同規則。請直接驗證 Booking.com 上的方案。
若已儲存的設定看來正確，但預期的搜尋仍無法預訂，請向客服提供確切的房型與方案識別資料、日期、入住人數、預期接受的住宿安排、已儲存的規則及測試時間。調查其他原因期間，請保留有效的限制。只有在預期方案可正常預訂，且需管控的日期或住宿安排仍維持受限時，才算完成處理。
