Booking.com 取消预订后自动回补库存：已关闭的客房为何重新开放

前台关闭了某房型周六的销售。随后，一位客人取消了此前在 Booking.com 上的预订，周六的客房又显示为可售。最初的关闭操作可能已经生效，只是之后发生的其他事件再次改变了房态。

遇到这种情况，应同时检查 Booking.com 取消预订后的处理机制，以及酒店渠道管理系统向 Booking.com 发送的库存。取消一笔预订，并不一定意味着酒店就有一间可以放心再次出售的客房。

区分库存回补与已关闭客房重新开放销售

自动回补库存会将取消的间夜重新计入 Booking.com 的可售库存。重新开放已关闭客房则涉及取消预订是否还会让酒店此前已关闭的销售重新开放。不要将两者视为同一个可以相互替代的开关。

如果取消预订确实释放了可售客房，正常回补库存就有助于继续销售。但维修停房、人员不足导致接待能力下降，或已接下其他预订，都可能使酒店当前的实际情况与原预订时不同。

可联系 Booking.com 客服，申请停用重新开放已关闭客房的选项。不要认为渠道管理系统中的某项控制就能关闭 Booking.com 的所有库存回补行为。应确认该住宿当前对已关闭客房的实际处理方式，以及任何设置变更的适用范围。

因此，仅凭“酒店管理系统里仍然显示已关闭”，还不足以完成排查。PMS 即酒店管理系统。需要查明这些间夜对应的实际可接待客房数、计划在线销售的数量，以及 Booking.com 当前保存的状态。

如果取消预订也让酒店管理系统中的房态恢复可售，应将这种正常的库存释放与渠道端另行触发的重新开放区分开来。切勿仅仅因为到店预订列表中少了一笔订单，就手动增加一间可售客房。

当已取消的预订和维修锁房分散在不同视图中时，员工容易将预订释放的库存误认为实际多出的接待能力。在 Smart Order 中，可先通过预订日历核实剩余客房，再通过已连接的多渠道管理发送计划销售的房态。应核实 Booking.com 上的实际结果，而不是因情况不明就反复额外扣减库存。

先保护受影响日期，再还原事件经过

如果已无可放心出售的客房，应按照酒店批准的应急流程，关闭 Booking.com 上受影响的可售选项。检查渠道保存的结果及客人看到的可售选项。凡是在 Extranet 后台直接覆盖设置的操作，都应保留记录，以便后续与酒店管理系统的常规控制保持一致。

不要关闭无关房型，也不要假定应急覆盖设置会一直有效。应指定专人持续关注受影响日期，直到重新开放的风险得到解决。

针对具体房型、价格计划和入住间夜，整理出一条完整的事件时间线。根据现有记录，注明完整日期、时间和时区：

1. 确认原计划关闭的销售范围，并查找 Booking.com 已接受关闭指令的证据。本地保存了某个值，并不等于渠道已确认关闭。
2. 找出重新开放前后发生的取消或修改预订事件。对比释放的间夜与重新变为可预订的间夜。
3. 查明酒店、渠道管理系统或其他授权用户此后是否更新过房态，或手动重新开放过销售。
4. 如果收到了新预订，应将其最初创建时间与关闭销售的时间进行对比，而不只是看它何时出现在前台系统中。
5. 将 Booking.com 最终显示的可售选项与酒店管理系统中的当前接待能力进行对比。在下一次按计划修正前，保留相关记录。

以这组假设时间线为例：14:00 关闭指令被接受；14:10 预订取消；14:12 发现相同间夜重新开放。这一顺序支持进一步排查自动回补库存机制。但在检查是否存在后续开放指令或其他仍在销售的价格计划之前，还不能据此确定原因。

相比之下，一笔在 13:59 创建、14:02 才收到的预订，实际下单时间早于 14:00 的关闭操作。预订延迟进入酒店管理系统，并不能证明客房在关闭后重新开放过。

应仔细核查部分变更。三晚预订缩短入住时间，可能只释放最后一晚；多间客房预订的取消，也可能只释放其中一间。应追踪具体受影响的间夜，而不是对整个预订时段统一增减库存。

通过住宿管理预订日历，前台可以对照变更后的预订与剩余入住安排。计算时仍须计入维修及其他运营锁房；取消的预订只是客房数量核算中的一个因素。

修正重新开放机制，并核实结果

当证据指向取消预订触发了重新开放时，应请 Booking.com 客服确认重新开放已关闭客房的设置，并为该住宿安排适当的处理方式。应清楚说明业务需求：主动关闭的间夜，不应仅因一笔较早的预订被取消就重新变为可售。

提供住宿编号、已取消或修改的预订编号、房型和价格计划、受影响的入住日期、关闭与取消时间，以及异常可售选项的截图。隐藏不必要的客人信息和支付信息。应要求确认设置已完成变更，而不是将提交申请视为处理完毕。

在处理设置问题的同时，应通过平时负责销售控制的系统修正当前房态。如果系统支持，可依据已核实的当前客房数量和计划关闭状态，针对受影响日期重新发送一次更新。确认 Extranet 后台保存的状态，并按原先条件再次模拟客人搜索。

如果客房仍然可订，应保留该可售选项的具体信息，并同时向连接服务商升级反馈。问题可能涉及房型或价格计划映射、另一个仍在销售的计划，或后续更新。自动回补库存只是可能的原因，不能因此停止核查其他证据。

在不冒险取消真实预订的前提下验证处理效果

不要为了查看客房是否会重新开放而取消真实客人的预订。应采用服务商批准的测试安排，或在指定负责人并落实防误售措施后，监测下一笔真实发生且与问题相关的取消预订。选择的验证方式必须确保已售罄或不宜出售的库存不会被开放销售。

对于应保持关闭的客房，应在事件发生前、取消处理完成后立即，以及常规房态更新完成后，分别检查其状态。这样才能区分短暂重新开放与问题已得到持续修正。对于正常可售客房，则应确认取消的库存按预期回补，且没有重复增加。

应保留实际验证结果，而不只是一条“设置已更改”的备注。真正有用的证据是：需要关闭的间夜始终未被开放销售，同时正常可售库存的处理也符合预期。

如果已经产生另一笔预订，应立即按照酒店的超售处理流程升级处理客房安排冲突。不要删除新预订，也不要为了操控库存回补而将普通取消标记为超售。在修正设置的同时，应妥善安排客人入住，并保留预订历史。