重试 OTA 导入产生了重复预订：如何安全修复

重试后产生的重复 OTA 预订看起来似乎很容易修复：找到两条相似的记录并删除其中一条。但这充满风险。其中一条记录可能是连接的预订，将接收未来的 OTA 更改，而另一条记录可能包含前台已完成的排房、支付、备注或入住工作。

安全的应对措施是暂停自动化，证明记录是重复的，选择一条权威预订，移动或保留运营数据，然后使用酒店管理系统允许的操作停用多余记录。必须立即进行房态和支付检查，因为删除记录可能会释放客房或更改余额。

为什么 OTA 重试会产生重复预订

重试通常应该重用 OTA 的外部预订 ID，以便 酒店管理系统 识别出是同一个预订。当原始导入部分成功但返回错误、重试到达时没有相同的标识符，或者在延迟的自动预订进入酒店管理系统之前创建了手动占位符时，就可能出现重复预订。

另一种常见情况始于手动导入的未来预订。如果手动记录不包含有效的来源预订 ID，稍后的 OTA 修改可能无法与其匹配。酒店管理系统可能会创建一条新的已连接记录，而不是更新现有的手动记录。

两条酒店管理系统记录看起来可能完全相同，但表现却不同。可能只有一条记录仍连接到 OTA 修改、取消、宾客消息、支付说明或虚拟卡数据。这就是为什么仅凭宾客姓名和入住日期不足以决定删除哪条记录的原因。

一旦发现重复记录，应立即停止重复导入、重新发送和手动房态更改。在另一条消息改变证据之前，记录两个预订编号、创建时间、来源 ID、当前状态和对房态的影响。

证明这两条记录确实是重复的

同一位客人和同一日期的两个预订仅是疑似重复。客人可能是故意预订两间客房，或者两名同姓旅客结伴入住。不同的 OTA 确认号通常意味着这是两个独立的预订，除非 OTA 另有证明。

逐个字段比较两条记录：

• OTA 确认号和酒店渠道管理系统或 CRS 参考号
• 酒店管理系统预订编号、创建时间、导入方法和来源
• 住宿、房型、入住、退房、入住人数和房价计划
• 总价、税费、支付模式、押金和取消政策
• 最新修改、取消、消息和同步状态
• 排房、账单、备注、任务和入住操作

打开 OTA 后台，确认存在多少个有效预订。然后检查酒店渠道管理系统或 CRS 队列。如果 OTA 和中间商显示一个预订，但酒店管理系统显示两条具有相同外部参考号的记录，则酒店管理系统记录极可能是重复的。

如果记录具有不同的 OTA 确认号，请停止操作。在 OTA 或客人确认是否两边都有意预订之前，不要合并、取消或删除任何一个。短暂保留房态的成本通常低于取消有效预订的成本。

互联的工作流程使这种比较变得更加容易。Smart Order 的 酒店渠道管理系统 将传入的 OTA 参考号与酒店管理系统房态链接起来，因此员工可以追踪重试是更新了现有预订还是创建了另一条运营记录。

选择权威记录并安全修复重复项

权威预订是酒店将保留作为住宿唯一来源的记录。它应该能够接收未来的 OTA 更改，并保留直到退房所需的运营和财务记录。

使用下面的矩阵作为决策辅助。供应商的行为各不相同，因此在合并、删除、作废或取消记录之前，可能仍需要主管或支持部门的批准。

在许多重试事件中，具有有效 OTA 来源 ID 的自动记录是更安全的权威记录，因为以后的修改和取消可以与其匹配。没有该来源 ID 的手动占位符通常是要停用的记录——但前提是必须保留其有用数据。

请遵循以下顺序：

1. 冻结两条记录上的额外重试、编辑、入住操作和支付尝试。
2. 根据有效的来源链接和未来的更新路径选择权威记录。
3. 保留或转移排房、宾客备注、任务、账单项目、押金和授权支付参考。
4. 使用酒店管理系统允许的状态、合并、作废、取消或删除操作将多余记录标记为重复。
5. 当系统保留重复历史记录时，向两条记录添加交叉引用备注。
6. 重新打开 OTA、酒店渠道管理系统和酒店管理系统，以确认仅剩一个有效的运营预订。

不要仅仅为了清理酒店管理系统而取消 OTA 预订。未经财务和管理层审查，不要删除包含已入账收入、支付授权、已入住状态、客房门禁或财务单据的记录。有些系统需要支持部门协助才能安全合并，因为可见的预订链接到了隐藏的交易和消息记录。

核对房态、支付和前台工作

直到酒店的运营总数正确，删除重复项才算完成。如果两条记录都减少了可用房量，停用其中一条可能会退回一间客房。如果只有一条记录减少了可用房量，手动增加房量可能会释放出多余的客房进行销售，从而导致超售。

在修正之前记录可用房量，完成批准的重复项处理操作，然后将酒店管理系统的客房数量与酒店渠道管理系统和 OTA 进行比较。最终数量应反映一次已确认的住宿——而不是零次，也不是两次。

单独核查支付和账单活动。确认任一记录是否包含押金、预授权、扣款、退款、OTA 代收余额、虚拟卡说明、税务发票或佣金基础。切勿将完整的银行卡或安全详细信息复制到普通的预订备注或支持电子邮件中。

同时核对每条记录已经触发的工作。检查宾客消息、到店前自动化、排房、房务工作备注、接机、用餐请求、门禁密码和入住登记表。抑制重复的工作流程，以免客人收到两次确认、两次支付请求或相互冲突的指示。

在夜审之前，再次按客人姓名和每个外部参考号进行搜索。确认一次有效住宿、一次排房、一个运营余额以及正确的渠道归属。保留显示保留了哪条记录以及保留原因的审计跟踪。

上报事件并防止再次出现重试重复预订

当团队无法识别已连接的记录、两条记录都包含交易或取消一条记录会导致房态发生意外变化时，请向上级汇报。酒店管理系统或直连提供商可能需要检查消息 ID、送达回执、导入日志和重试行为。

发送给支持部门：

• 住宿 ID 和直连提供商
• OTA、酒店渠道管理系统以及两个酒店管理系统预订参考号
• 原始导入、错误、重试和重复创建的时间戳（含时区）
• 当前状态、客房和房价映射以及前后的可用房态
• 消息和错误的屏幕截图（隐藏敏感的支付数据）
• 已采取的操作，包括支付、入住、排房或取消

永久修复取决于原因。缺少外部来源 ID 需要更好的 ID 保留机制。成功导入后超时需要在重试前检查状态。手动占位符需要核对标志。并发缺陷或重复的 webhook 需要供应商方面的重复保护，而不是另一个前台的变通方法。

将该规则纳入酒店的事件处理流程：在员工确认第一条消息是否创建了预订之前，不进行重试。通过新的预订、修改和取消来测试新的 OTA 连接。修改应更新同一条酒店管理系统记录，取消应退回一次房量。

当前台可以同时看到预订来源、运营状态和客房可用性时，清理重复项会更安全。Smart Order 的 酒店前台管理系统 为员工提供了一个日历，用于查看已连接的预订及其对客房的影响，从而降低了临时占位符变成第二次有效住宿的可能性。

常见问题

酒店应保留哪个重复的 OTA 预订？

通常保留具有有效 OTA 来源 ID 和有效修改或取消链接的记录。在停用另一条记录之前，请保留其包含的任何支付、账单、排房、备注、任务和入住操作。

前台可以直接删除较新的预订吗？

不可以。较新的记录可能是恢复导入所创建的自动已连接预订。删除它可能会中断未来的 OTA 更新，同时留下一个未链接的手动记录。

酒店应该在 OTA 后台中取消一个预订吗？

当 OTA 仅显示一个已确认预订时则不应这样做。重复项可能仅存在于酒店管理系统内部。取消真实的 OTA 预订会影响客人、支付、佣金和取消条款。

如果两条记录都已经包含扣款怎么办？

停止进一步的支付活动并让主管或财务团队介入。确认哪些扣款已获授权、是否发生任何重复扣款，以及酒店管理系统是否需要进行作废、退款、账单转移或供应商协助合并。

为什么重试创建了新的酒店管理系统记录，而不是更新第一条？

常见原因包括缺少或更改了外部预订 ID、原始导入成功但返回错误、没有来源参考号的手动占位符、重叠的重试处理或修改无法与第一条记录匹配。

酒店应该如何验证该修正？

确认酒店管理系统中有一个有效预订、OTA 中有一个确认的预订、一条已连接的参考路径、一次正确的客房扣减以及一个运营余额。然后测试未来的修改是否会针对保留的记录。

安全的重复项修复可在清理数据库之前保留客人的真实预订。识别已连接的记录、保护资金和运营、修正房态一次并留下审计跟踪，从而防止下一次重试变成另一次前台紧急情况。