1. 使用仍会显示可预订报价的确切日期和入住人数在 Expedia 上搜索。
2. 确认该报价对应的房型、房价方案和库存池。
3. 在进行更改前，确认当前由哪个系统控制 Expedia 的房态。
4. 仅关闭一次剩余的可售路径，然后从宾客端验证结果。
当一个已在 Expedia 关闭的房间仍在售时，眼前的问题并不是技术错误提示，而是酒店可能接受一笔无法履约的预订。
首先保护受影响日期的库存，然后追查仍可预订的具体报价。酒店可能已在酒店管理系统中关闭某间实体客房，但 Expedia 上对应的房型仍有库存；也可能只关闭了一个房价方案，而同一房间的其他报价仍处于开放状态。
本指南重点介绍如何找出Expedia中仍然存在的销售路径。本指南不会重复通用的停售检查清单；这里的关键问题是，Expedia 上究竟是哪个房型与房价方案组合仍在向宾客提供可预订报价。
在避免过度关房的同时保护酒店
使用受影响的入住日期、宾客人数、房间数量以及问题发生的市场进行一次宾客端搜索。记录实时报价中的房间名称、取消条款、餐饮方案、价格，以及附加的套餐或会员条件。
如果酒店已经满房或临近入住日期，请按照酒店批准的应急流程停售该具体报价。记录操作人员、时间、日期、房型、房价方案以及所使用的系统。
除非所有房间确实都需要停售，否则不要关闭整个酒店。同时，也不要在酒店管理系统、多渠道管理系统和 Expedia 合作伙伴中心同时分别设置关闭。多项应急更改会增加后续恢复正常销售时确认正确库存的难度。
确认仍处于开放状态的 Expedia 产品
打开 Expedia 合作伙伴中心，将宾客端报价与酒店的房型和房价设置进行匹配。仅凭相似的房间名称无法准确判断；还需要对比入住人数、床型配置、是否含餐、取消政策和价格。
检查以下可能让房间继续保持可售状态的替代路径：
- 同一房型关联了另一个房价方案；
- 另一个 Expedia 房型关联了同一批实体客房；
- 某个入住人数或儿童选项仍处于开放状态；
- 套餐、会员、移动端或促销报价仍在使用有效的基础库存；或
- 相关日期存在单独的配额或人工录入的库存数量。
即使受影响的房间已正确关闭，酒店的公开页面仍可能继续显示。判断故障的依据是：使用完全一致的房间、日期和入住人数完成搜索后，仍能进入可预订报价；酒店仅仅出现在搜索结果中并不能证明发生了故障。
确认酒店实际执行了哪种关闭操作
检查酒店管理系统或多渠道管理系统中的原始操作。确认员工是将可售库存设为零、应用停售限制、仅关闭到店、锁定某间实体客房，还是将房间标记为停用。
这些操作不能相互替代。锁定一间实体客房会影响房务工作或排房，但不一定会关闭线上房型。关闭某日到店后，入住日期更早的宾客仍可能跨越该日期继续入住。关闭一个房价方案，也可能使另一个关联报价继续有效。
记录酒店原计划发送的确切房型、房价方案、日期、数量和限制条件。如果原始操作与 Expedia 上的实时报价不一致，应修正目标产品，而不是反复发送同一个不完整的关闭指令。
Smart Order 可帮助管理者在同一操作界面中对比酒店房态与已连接 OTA 的销售情况。团队可以快速确认受影响的客房库存池，指定一名负责人完成修正，并在恢复正常分销前保留清晰记录，从而提高处理效率并降低超售成本。
在一个操作界面中统一管理 Expedia 房态
使用 Smart Order，在关闭或重新开放报价前快速核对客房库存与 OTA 销售情况。
查明哪个系统控制 Expedia 库存
酒店通常可以在多个位置查看房态，但日常情况下只能由一个数据源向 Expedia 发送客房数量。请确认该数据源是酒店管理系统、多渠道管理系统，还是 Expedia 合作伙伴中心。
如果 Expedia 库存由多渠道管理系统控制，那么在 Expedia 合作伙伴中心进行的人工更改可能只是临时生效，也可能被下一次系统同步覆盖。如果酒店通常直接管理 Expedia，那么仅在酒店管理系统中进行更改可能不会影响实时报价。
检查 Expedia 的连接状态，以及受影响日期最近一次面向酒店的更新结果。查找连接暂停、授权过期、房型或房价未映射、更新被拒绝，或关闭后又发送了不同库存数量等问题。
在当天发生销售事故时，请勿更改房型映射，除非现有映射明确有误，并且已经评估对未来预订的影响。映射调整或许能解决当前可见的报价，却可能将后续预订分配到错误的房间。
追查最后一次重新开放房间的更改
关闭指令可能已正确送达 Expedia，之后却又被覆盖。将酒店执行停售操作的时间，与后续房价或库存更新、批量更改、定时规则、Expedia 合作伙伴中心的人工编辑以及员工操作记录进行对比。
需要特别关注共享库存。如果两个 Expedia 房型共用同一个实体客房库存池，但只有其中一个连接至酒店管理系统，那么第二个房型中的人工库存数量可能会让销售保持开放。新建的房价方案未被纳入日常关闭流程时，也可能出现相同问题。
建立一条简单的事故时间线：房间何时变为不可用、酒店何时关闭房间、Expedia 最后一次显示房间开放的时间，以及这些节点之间发生了什么更改。这样可以将模糊的“同步故障”转化为酒店能够修正的具体控制漏洞。
一次性关闭剩余销售路径
确认实时在售的 Expedia 产品及其库存控制方后，进行一次有控制的修正。
- 在控制 Expedia 销售的系统中，为确切的房型、房价方案和入住日期设置正确的库存数量或关闭限制。
- 如果必须通过 Expedia 合作伙伴中心进行紧急覆盖，请记录该操作，并在下一次更新前明确如何与已连接的系统进行数据核对。
- 确认相关房型或房价方案是否应继续开放；不要将关闭设置复制到无关库存。
- 等待正常更新周期结束，然后刷新 Expedia 合作伙伴中心并再次进行宾客端搜索。
- 只有在酒店管理系统、库存控制系统、Expedia 合作伙伴中心和宾客端显示结果一致后，才能重新开放销售。
不要反复点击同步，也不要在更新处理期间持续修改库存数量。如果第一次修正没有显示，请保留证据并上报处理，避免产生多条相互冲突的指令。
从宾客端验证修复结果
重复执行暴露问题时的同一搜索，包括日期、入住人数、房间数量、设备或市场条件，以及适用时的套餐选择。确认受影响的报价已无法继续进入预订流程。
然后，对另一个应保持开放的房间或日期进行对照搜索。这样可以确认酒店修复了目标 Expedia 产品，同时没有误关正常有效的库存。
在酒店系统内部，确认每晚的可售库存均正确，并确保不存在之后会导致库存被重复扣减的应急锁定。在交接班记录中保存最终截图、更新时间和审批经理信息。
防止 Expedia 再次开放房间
每当酒店新增房型、房价方案、促销活动或共享库存安排时，都应为 Expedia 维护一份房型与房价检查清单。测试真正重要的宾客端搜索场景，包括单晚、多晚、不同入住人数，以及酒店使用的任何套餐或会员报价。
指定一个系统统一负责 Expedia 的日常库存更新。仅在有记录的例外情况下进行直接人工更改，并在下一次自动更新前复核。当某间客房暂停使用时，应明确员工是只需锁定实体客房，还是还需要减少 OTA 的可售房型库存。
最后，在恢复正常销售后复盘事故。修复缺失的映射、残留配额、不受支持的关闭方式，或造成销售路径仍然开放的员工操作流程。长久的解决方案不是延长紧急停售时间，而是彻底消除 Expedia 能够重新开放房间的原因。
常见问题
为什么酒店管理系统中的房态为零，Expedia 仍能销售房间？
酒店管理系统中的数值可能并不控制该 Expedia 产品，也可能存在其他房型、房价方案、库存配额或后续更新仍在提供库存。
关闭一个 Expedia 房价方案会彻底关闭该房间吗？
不一定。关联同一房间的其他房价方案和报价可能仍处于开放状态，因此需要核实宾客端显示的具体产品。
发生紧急情况时，酒店是否应该直接关闭 Expedia？
当实时报价造成紧迫的超售风险时，请按照酒店批准的应急流程操作。记录临时覆盖操作，之后再与日常库存数据源进行核对。
何时才算同步故障已经解决？
当库存控制系统、Expedia 合作伙伴中心以及条件一致的宾客端搜索均显示预期的关闭状态，同时无关房间和日期仍保持可售时，才算故障已经解决。
