1. 确认 OTA 显示预订已完成取消，而不是取消申请或免除费用消息。
2. 核对预订编号、已取消房间、日期和取消时间。
3. 保留酒店管理系统中的原始记录，并且只修改一次；不要创建替代预订。
4. 更正后检查房态、付款、费用、宾客消息和报表。
当OTA 取消信息未同步至酒店管理系统时，酒店可能面临两种相反的风险：房间可能仍被占用，无法重新销售；或者员工可能重复释放房间，导致售出的房量超过酒店实际可售房量。
住宿管理人员还可能等待一位已不会到店的宾客、收取错误金额、发送入住消息，或者让错误的预订继续出现在收益报表中。
这是一套专门针对取消订单的处理流程。流程从确认 OTA 的最终状态开始，直到酒店管理系统中的原始预订、房态、付款和宾客沟通信息全部一致才算结束。
确认 OTA 取消已最终生效
在正确的 OTA 酒店页面中打开该预订，并使用渠道确认号进行搜索。确认当前状态以及带时区的取消时间。
不要将宾客消息、取消申请、免除费用申请、付款失败提醒或客服对话视为已完成取消。酒店只有在 OTA 预订显示最终取消状态后，才能更改酒店管理系统中已确认的入住预订。
检查整个预订是否均已取消。多房间预订可能只取消其中一个房间，修改后的住宿订单也可能仅移除部分晚数，而不取消剩余住宿。记录 OTA 实际释放的房间、宾客、日期和数量。
保存显示最终状态、取消参考编号、取消时间和适用费用条件的截图或导出记录。这将成为后续所有操作的核对依据。
找到准确的酒店管理系统预订
首先使用 OTA 确认号在整个酒店管理系统中搜索，然后按宾客姓氏、抵店日期、预订日期、房型和来源进行搜索。搜索范围应包括有效、已取消、已修改、未分配、已归档、手动录入和重复的记录。
不要只依赖抵店名单。日期筛选、酒店筛选或已修改的入住安排可能隐藏相关记录，而手动创建的副本仍处于有效状态。
对比 OTA 与酒店管理系统中的标识符、日期、房型、房价方案、宾客人数、价格、付款方式和预订历史。当前有效记录可能是在此前导入异常时创建的重复记录，而后续渠道变更可能只与其中一条酒店管理系统记录保持关联。
如果两条记录使用相同的 OTA 确认号，请立即停止操作。在更改任何一条记录的状态前，先确定哪条记录包含正确的付款信息、备注、房间分配和渠道历史。
更正状态前先保护房态
记录每个已取消晚数当前的可售房量。检查实际房间库存池，而不要只查看预订中显示的单个房价方案。
确认房量是否已通过其他途径恢复。即使酒店管理系统中的预订仍处于有效状态，OTA 也可能已经重新开放房态；酒店管理系统也可能已经释放房间，只是仍显示旧状态。
在明确当前房量之前，不要手动增加房间。如果酒店管理系统随后收到取消信息，手动增加房量可能会多出一个可售房间。
如果涉及当天入住或满房日期，应安排一名管理人员统一负责。仅在必要时采用一项临时控制措施，做好记录，并在确认最终房量后将其移除。
Smart Order 可在同一个操作视图中关联 OTA 确认号、酒店管理系统预订和房态，帮助管理人员更正原始记录并确认房量仅恢复一次，无需多名员工分别执行操作，从而提升效率并降低出错成本。
确保 OTA 取消始终关联原始预订
使用 Smart Order，在释放房量或更正酒店管理系统前轻松核对预订状态和房态。
检查酒店管理系统记录为何仍处于有效状态
依据可见的运营信息进行检查，而不是纠结于技术术语。确认 OTA 连接是否有效、取消信息是否仍在等待处理，以及预订中的房间和房价方案是否仍保持连接。
检查原始预订以何种方式进入酒店。如果预订是手动录入，或通过备用电子邮件传入，自动取消信息可能无法更新对应的酒店管理系统记录。团队可能需要采用经过批准的手动取消流程。
查找较早创建的重复记录、手动编辑、换房、拆分预订、变更后的确认号或已锁定的入住状态。这些情况都可能导致取消信息无法找到员工预期的记录。
不要为了强制处理一条取消信息而重新映射正在使用的房间或房价方案。映射变更可能影响未来预订。保留警告信息、预订参考编号和时间线，以便交给相关系统服务商处理。
一次性更正原始预订
如果服务商能够恢复已确认的取消信息，只请求执行一次恢复并等待结果。反复重试可能产生重复备注、状态变更或房量恢复。
如果酒店流程要求手动更正，请更新酒店管理系统中的原始预订，而不要将其删除。保留 OTA 确认号、原预订条款、付款历史、取消时间、费用决定、宾客消息和审计记录。
请按以下顺序操作：
- 确认 OTA 取消已最终生效，以及具体影响的房间或晚数。
- 确定应保留的唯一一条酒店管理系统记录。
- 记录经批准的取消费、退款、押金或付款处理决定。
- 使用经过批准的取消原因和渠道来源更改酒店管理系统中的状态。
- 确认受影响房间库存池和日期的房量仅恢复一次。
- 只有在最终房量准确无误后，才能移除临时保留或手动调整。
不要为了让预订从抵店名单中消失而直接将其删除。财务、宾客服务和未来的争议处理都需要这条预订的历史记录。
核对费用、退款和付款说明
取消状态本身并不能决定如何处理款项。查看原始 OTA 预订所附的取消条款，确认是在免费取消期内取消、逾期取消、不可退款、部分取消，还是适用已批准的费用豁免。
分别记录酒店有权收取的金额、实际已收金额，以及必须退款或调整的金额。不要仅仅因为酒店管理系统中的有效记录仍显示余额，就向宾客收费。
如果由 OTA 收取款项，请按照该预订所示的渠道付款与退款路径处理。如果由酒店收取款项，请采用酒店批准的退款和取消费处理流程。
财务部门应保留 OTA 状态、酒店管理系统记录、付款凭证、费用计算、退款凭证和审批人信息。即使房间在运营层面已经取消，财务问题仍可能尚未解决。
检查所有后续处理结果
再次使用 OTA 确认号搜索酒店管理系统。确认只保留一条状态为已取消的记录，并且受影响的房间、日期、原因、费用和付款备注均准确无误。
检查每一晚的房态。如果多房间预订中只取消了一个房间，则只能恢复相应数量。如果仅移除了部分晚数，剩余晚数必须继续保留。
检查抵店名单、房务工作计划、自动入住流程、付款提醒、宾客消息、入住率预测、收益报表和渠道佣金核对。取消或更正所有仍将该宾客视为即将抵店的任务。
只有当 OTA 与酒店管理系统的状态一致、房量仅恢复一次、宾客未收到相互矛盾的消息，并且财务人员能够说明最终金额时，才能结案。
防止再次遗漏取消信息
将取消订单纳入每个班次的交接事项。优先处理当天抵店、仅剩最后一间房的日期、多房间预订、预付预订、免除费用决定以及手动录入的预订。
每天执行异常检查，对比近期 OTA 取消订单与酒店管理系统中的有效抵店预订。酒店不需要复杂的技术报表，只需要一份状态不一致的确认号简表。
新增 OTA、房型、房价方案或渠道连接后，应完整测试一条可取消预订，从下单一直测试到取消。确认酒店管理系统中的原始记录已发生变更，且房量仅恢复一次。
分别记录反复出现的原因：连接未启用、产品未映射、手动预订、重复记录、员工编辑和更新延迟。应解决反复出现的运营缺口，而不是将每次取消都视为孤立错误。
常见问题
员工是否应根据宾客消息取消酒店管理系统中的预订？
不应这样做。首先确认 OTA 预订已进入最终取消状态。取消申请或免除费用消息可能不会使预订失效。
是否应立即将房间重新加入可售房量？
不能立即操作。员工应先确认房量是否已经恢复，重复增加房量可能导致额外多出一间可售房。
如果多房间预订中只取消了一个房间，该怎么办？
只取消受影响的部分，并将相应房量恢复一次；其余房间和晚数应继续保持有效。
酒店应在何时联系技术支持？
如果 OTA 的最终状态已明确，但无法安全更新正确的酒店管理系统记录，则应上报涉及当天入住、最后一间房、预付、重复记录或反复发生的问题。
