1. 更改限制前，先核对宾客具体的入住日期、退房日期、房型、入住人数和房价计划。
2. 入住限制、退房限制和最少入住晚数分别控制不同条件，需要结合检查。
3. 恢复您希望接受的住宿安排后，再测试仍需限制的住宿安排是否依然不可预订。
即使 Booking.com 商家后台显示某个房型有可售房量和价格，宾客也可能无法预订特定日期。问题可能出在住宿日期组合和晚数，而非房间数量。
清除限制前，先写明您希望接受的预订条件。例如，“两名成人，周五入住、周日退房，预订标准双人房，选择可灵活取消的不含餐房价计划”，就是一个明确的测试场景。“重新开放周末预订”则过于笼统。
记录未能显示可订结果的搜索条件，确认规则由哪个系统管理
使用相同的入住日期、退房日期、宾客人数及年龄、房间数量和房价适用资格重新搜索。记录是整个房型都未显示，还是只有目标房价计划未显示。
确认每个实际住宿晚间都有真实可售房量。编辑房价计划前，先检查房型层面的关闭销售设置：开放某个房价计划，无法绕过已关闭销售的房型。缺少价格或可售房量为零，也无法通过取消最少入住晚数限制来解决。
接下来，确认酒店是在商家后台，还是通过已连接的酒店管理系统和渠道管理系统管理这些限制。对于已连接系统的酒店，还要核实具体由该系统管理哪些规则。不要在两个系统中进行相互冲突的修改。
保留当前设置和预期业务规则的记录。为活动期间特意设置的限制，即使会拒绝短住预订，也不代表设置有误。更改酒店可接受的销售条件前，应先获得批准。
限制设置分散时，员工容易改错销售方案。使用酒店渠道管理系统核对关联的房型和房价，再执行渠道支持的更改。Smart Order 将房价、房态和已连接渠道的预订整合到同一操作流程中，帮助团队将目标销售方案与正确的共享房量对应起来，减少凭相似名称猜测和反复核对的时间。
核对受限销售方案对应的房型
更改渠道规则前，先检查关联房型的可售房量和房价，再验证您希望在 Booking.com 上接受的具体住宿安排。
结合实际日期理解 Booking.com 商家后台的住宿限制
以下通过一个假设的周末场景，说明搜索为何没有可订结果。所有示例均假设可售房量充足、价格有效，且不存在其他阻止预订的条件。
CTA 限制当日入住，不会阻止所有包含该日期的住宿
CTA 指禁止当日入住。设置周六禁止入住后，宾客无法预订从周六开始的住宿。单凭这项限制，并不会阻止周五入住的宾客在周六晚继续住宿。
如果您希望接受周五入住、周日退房的预订，取消周六的入住限制可能不会产生任何效果。此时应检查周五的入住设置，以及影响该住宿安排的其他规则。
CTD 针对退房日期生效
CTD 指禁止当日退房。设置周日禁止退房后，以周日为退房日期的搜索将无法获得可订结果，即使这次住宿并不包含周日晚。
周五入住、周日退房的搜索，实际占用周五和周六两晚。若周日禁止退房，这一搜索可能无法预订，而周五入住、周一退房则可能符合条件。不要将禁止周日退房与关闭周日晚的可售房量混淆。
最少入住晚数可按入住日期或住宿涵盖日期生效
MinLOS 指最少入住晚数。如果周五按入住日期设置了至少入住三晚，周五入住、周日退房的两晚住宿就不符合条件。
按住宿涵盖日期生效的最少入住晚数规则则不同：只要实际住宿包含受限日期，该规则就会生效，即使宾客更早入住也是如此。如果规定凡住宿包含周六晚就必须至少入住三晚，那么即使周五按入住日期设置的最少入住晚数仅为一晚，同样的周五入住、周日退房搜索也可能无法预订。
检查规则的生效依据，不能只看晚数。针对宾客实际住宿某一晚的限制，与按入住日期生效的规则不同；退房日期也不应额外计为一个住宿晚间。
单项规则都有效，组合后仍可能导致无法预订
如果同一拟订住宿安排同时受到最少三晚和最多两晚的限制，就不存在符合条件的入住晚数。取消 CTA 也无法解决这一冲突。
正确做法是在获得批准后，对冲突规则进行必要的最小调整，而非清除整个日历的限制。系统接受更新，只能说明设置已保存或已发送，并不代表这些规则组合后允许宾客预订。
修正日历设置，同时保留有效的管控规则
使用酒店平时管理这些设置的系统。在商家后台，打开受影响酒店的日历，找到对应房型、房价计划和相关限制字段。界面布局和可用控件会因账户及日历视图而异。
- 准确选择涉及的日期，包括与该规则相关的入住日期、实际住宿晚间或退房日期。
- 确认您编辑的是房型，还是某个特定的房型与房价组合。
- 将已保存的入住、退房、最少及最多入住晚数规则，与已批准的销售条件逐一核对。
- 仅修改存在冲突的数值或关闭设置。保存前，复核受影响的日期范围。
- 按照该系统支持的流程保存，重新打开日历，核对已保存的数值，而非尚未保存的输入内容。
如果相关字段不可用，请让渠道分销负责人向 Booking.com 或系统连接服务商确认支持哪些控制选项。不要用全面停售替代仅禁止当日入住的限制，也不要为清除字段而随意填写数值。
扩大销售范围前，使用前台预订日历核对已有预订和房间占用情况。切勿在忽略维修房或已满房日期的情况下，放宽原本有意设置的限制。
逐一检查相关房价计划，不能只看最低价
可灵活取消的不含餐房价计划与含早餐房价计划，可能显示不同的搜索结果。应核对宾客实际尝试预订的房价计划，以及该计划的可订日期、入住人数和适用条件。
如果某个价格由另一房价派生而来，请检查哪些规则会继承，哪些规则单独管理。价格存在关联，并不代表所有限制都完全相同。应检查适用的母房价计划及具体房价计划，避免开放无关的销售产品。
促销也需要关联符合条件的基础销售方案，并满足促销自身的有效条件。如果住宿安排仍被适用规则限制，不要试图通过打折来绕过这些限制。
保留有意设置的差异。如果酒店希望灵活取消房价接受两晚住宿，而促销房价要求至少三晚，那么搜索较短住宿时，就不应显示促销房价。目标是让销售条件清晰易懂，无需将所有设置统一。
同时验证应允许和应限制的搜索场景
重新打开已保存的设置后，重复最初的搜索。确认目标房型和房价计划可以选择，且价格、入住人数、餐食和取消条款均符合预期。
然后再执行一次仍应被限制的搜索。例如，对于已批准的最少入住三晚规则，在保持其他相关条件相同的情况下，测试三晚住宿是否允许预订、两晚住宿是否无法预订。如果其他有效规则会阻止较长住宿的搜索，请选择能够单独验证当前规则的测试场景。
在酒店的酒店直订系统中搜索到可订结果，并不能证明 Booking.com 采用了相同规则。必须直接验证 Booking.com 上的销售方案。
如果已保存的设置看起来正确，但目标搜索仍无法获得可订结果，请向客服提供准确的房型和房价计划标识、日期、入住人数、预期可接受的住宿安排、已保存的规则及测试时间。在排查剩余原因期间，保留有效限制。只有当目标销售方案可正常预订，且需要保护的日期或住宿安排仍受到限制时，才算完成处理。
