1. 在开始排查前，先保护受影响入住日期的房态，但不要关闭无关的房间或渠道。
2. 检查 Booking.com 上具体的房型、房价计划、入住人数和日期范围，而不是笼统检查整个酒店。
3. 只有当宾客端页面不再为该产品提供任何可预订房价时，才能确认房间已安全关闭。
当 Booking.com 上已关闭的房间仍可预订时，通常意味着关闭指令只覆盖了宾客可购买产品的一部分。一个房型可能关联多个房价计划、入住人数选项或不同的联动房态来源。关闭其中一项，并不一定会关闭与该房间关联的所有可售产品。
应先将其作为销售管控问题处理，再开展系统排查。先避免酒店收到新的预订，然后找出仍处于开放状态的具体房型与房价组合。
本指南重点解决 Booking.com 上本应关闭、却仍向宾客显示的房间，不涉及预订丢失或预订导入失败问题。
首先，确认“关闭”的具体含义
房间可能因多种不同原因无法预订。酒店可能已将房量设为零、设置停止销售、关闭某个房价计划、在酒店管理系统中锁定某间实体客房，或将房间标记为停用。
这些操作不能相互替代。因维修而锁定某间实体客房会影响酒店运营，但不一定会减少发送至 Booking.com 的可售房量。关闭不可退款房价计划后，灵活房价计划可能仍然开放。最短入住限制可能会阻止一晚住宿的搜索结果，但仍允许预订两晚。
用一句话写明预期结果：“对于这些抵达和离店日期，无论选择哪种房价计划或入住人数，都不得预订这一具体房型。”这句话将成为每项检查的判断标准。
完成以下 7 项 Booking.com 检查
请按顺序完成各项检查。在尚未确定哪个可售产品仍处于开放状态时，不要反复点击同步，也不要大范围修改房态。
- 复现宾客的搜索操作。使用正确的酒店、抵达日期、离店日期、房间数量、成人数量和儿童数量进行搜索。不同的入住人数或入住天数可能会显示另一个可售产品。保存搜索结果截图并记录时间。
- 核对页面显示的房型名称。分别在 Booking.com 后台以及酒店管理系统或多渠道管理中打开同一房型。“豪华客房”和“豪华特大床房”等相似名称可能会掩盖映射错误。请核对产品代码或映射记录，不要只看显示名称。
- 检查该房型关联的所有房价计划。检查灵活、不可退款、含早餐、仅客房、移动端、会员、套餐以及所有衍生房价计划。如果其中一个计划仍然开放，即使另一个计划显示已关闭，该房间仍可能被售出。
- 对比每个入住日期的房态。搜索连续入住两晚时，两晚都必须有房。请在酒店管理系统、多渠道管理和 Booking.com 中分别检查每个日期，查找是否有某一天仍保留房量，或之后又收到了新的更新。
- 检查限制条件，而不只是房间数量。确认酒店设置的是停止销售、禁止抵达、禁止离店、最短入住天数还是最长入住天数。这些规则会影响不同的搜索结果。例如，禁止抵达并不一定会移除在该日期之前已经开始的住宿。
- 确认由哪个系统控制 Booking.com。如果房价和房态由多渠道管理控制，在 Booking.com 后台进行的手动修改可能会被覆盖。检查受影响房间和日期的最近一次成功更新以及所有警告信息。除非需要紧急手动关闭，否则应在主控系统中进行修正。
- 查找是否存在独立的房态来源。房间仍可能通过拥有独立配额的房价计划、新建但尚未映射的房型，或未连接主房态池的计划继续销售。请将所有在线可售产品与酒店的房型映射及合同配置逐一对比。
只有能够准确指出仍处于开放状态的产品时，才算找到问题，例如：“家庭房、灵活含早房价、三人入住、10 月 4 日至 6 日。”这比直接断定 Booking.com 忽略了整个酒店的关闭指令更稳妥。
当不同系统显示的房量不一致时，团队需要在一个平台中完成修正，并确认更新是否已成功传递至渠道。Smart Order 将房态与已映射的渠道产品连接起来，管理者可以在重新开放销售前快速核查受影响日期，提升处理效率并降低超售成本。
轻松掌控 Booking.com 房态
通过统一的酒店工作台管理已连接的客房房态，降低因房价计划仍开放而售出本应关闭房间的风险。
排查期间先保护酒店房态
如果酒店已经没有可安全销售的房间，请暂时关闭 Booking.com 上对应的具体房型产品，或在渠道主控系统中将其可售数量设为零。同时确认该操作不会关闭其他酒店、其他房型或无关日期。
不要重复扣减房量。如果酒店管理系统中已经显示为零，又将 Booking.com 后台的手动修改作为紧急措施，请记录操作人员和操作时间。否则，连接恢复后，手动关闭设置可能仍然有效，并在不易察觉的情况下阻止未来销售。
如果酒店只剩最后一间房，应判断在排查房态不一致问题期间继续销售是否安全。一次超售产生的成本，通常高于让一间房态存疑的客房继续开放一小时所带来的收入。
从宾客端确认问题已修复
等待新更新被接受，然后重复最初的宾客搜索。在条件允许的情况下，使用相同的日期、入住人数、房间数量、市场、币种和设备类型。检查房型列表，以及此前出现过的所有套餐或移动端专享产品。
酒店管理系统中的成功消息可以作为有效依据，但不是最终证明。最终判断标准是：在测试搜索中，受影响的房型与房价组合已无法继续预订。
除非酒店已有获批的测试预订流程，否则不要为了测试关闭状态而创建真实预订。通常，通过宾客端的房态搜索即可完成验证。如果房间仍然显示，请保存可见产品的截图并上报问题，不要同时进行多项新修改。
重新开放销售前记录本次事件
保留一份简短的事件记录，包括酒店、房型、房价计划、入住日期、预期房量、页面显示房量、最近更新时间、截图和修正措施。这样既能为支持团队提供可直接处理的信息，也能帮助酒店识别反复出现的问题。
重新开放销售前，请撤销所有紧急手动关闭操作，并确认正常的房态来源已恢复控制。然后分别测试一个应当开放的未来日期和一个应当继续关闭的日期。
如果同一房型反复保持可预订状态，请检查房型映射和房价计划配置，不要将每次事件都视为偶发的同步延迟。
常见问题
为什么 Booking.com 上已关闭的房间仍然可见？
房间可见并不一定意味着可以预订。即使没有可售房价，酒店或房型页面也可能继续显示。只有当宾客可以选择有效的房型与房价产品并继续预订时，才说明问题仍然存在。
一个仍开放的房价计划会让房间保持可预订吗？
会。灵活、不可退款、含餐、套餐或定向优惠可能拥有独立的控制设置。请检查与受影响房型关联的每一个房价计划。
酒店是否应该关闭整个物业？
通常不需要。只关闭能够防止再次售出的最小产品范围和日期范围。关闭整个物业可能会移除正常可售房量，造成不必要的收入损失。
酒店管理系统显示更新成功，是否足以证明问题已解决？
不足以。请使用发现问题时的相同宾客搜索条件确认结果。酒店管理系统中的状态应与 Booking.com 上的实时可售产品保持一致。
酒店应在什么时候联系支持团队？
如果主控系统显示关闭操作已成功，但经过合理的刷新等待后，具体产品仍然可以预订；或者房型映射中存在酒店无法识别或控制的产品，就应上报给支持团队处理。
