1. 在更改房态或创建酒店管理系统记录之前，请先在正确的 tiket.com Extranet 酒店属性中确认该预订。
2. 通过 tiket.com、酒店渠道管理系统以及酒店管理系统中的所有预订状态，使用行程 ID (Itinerary ID) 进行搜索。
3. 确认中断环节是发生在数据传输、产品映射、导入验证，还是到店视图筛选器中。
4. 仅从失败的交接环节进行重试，然后确认是否存在一条预订记录且房态已相应更改一次。
如果在 tiket.com 已经确认，tiket.com 预订未在酒店管理系统中显示，它仍然是一个有效的预订。故障可能出在 Extranet 与 酒店渠道管理系统 之间，或者在酒店渠道管理系统与酒店管理系统之间，抑或是在酒店管理系统的导入队列中。该预订也可能已存在，只是在到店视图中被隐藏了。
不要一上来就重新发送或手动录入预订。请先确认渠道记录，在各个系统中使用同一标识符进行追踪，并在不创建重复预订的情况下保障宾客的权益。
在 Tiket.com Extranet 中确认预订
登录 桌面版 Extranet 中的正确酒店。打开 Bookings > Search Bookings（预订 > 搜索预订），然后通过行程 ID 或宾客姓名进行搜索。扩大日期范围并检查已确认、已修改和已取消的状态，而不是仅仅依赖今日数据看板。
Lignum by tiket.com 应用程序提供了另一种验证途径。打开 Reservations（预订），在 Check-In（入住） 与 Booking（预订） 之间切换，选择相关日期范围，并通过宾客姓名或行程 ID 进行搜索。Tiket.com 的预订搜索指南和 Lignum 预订指南详细说明了当前合作伙伴端的这些检查步骤。
打开该预订并记录酒店名称、行程 ID、预订状态、创建和修改时间、入住日期、客房、房价计划、入住人数、宾客详情、支付说明和特殊要求。使用渠道记录来确定宾客是否有有效预订；将酒店管理系统作为日常运营的目标平台。
如果 tiket.com 找不到该预订，在根据宾客的截图或转发的邮件采取行动之前，请重新检查酒店和标识符。如果 tiket.com 显示该预订已确认，即使数据传输问题仍未解决，也请保障宾客的住宿安排。
追踪预订数据交接过程
直连的预订通常从 tiket.com 传输至酒店渠道管理系统或直连服务商，经过产品映射，进入酒店管理系统的导入服务，最终显示在到店视图中。请使用一个行程 ID 来测试这条数据链路。
- 在直连服务商系统中搜索 tiket.com 行程 ID 和预订时间戳。
- 检查该预订是被接收、排队中、已送达、被拒绝还是已重试。
- 记录服务商的消息 ID、目标酒店、响应内容和错误文本。
- 通过行程 ID、服务商参考号、宾客姓名、预订日期和入住日期在整个酒店管理系统中进行全面搜索。
- 检查待处理、失败、重复、被隔离、已取消、已归档和未分配的记录。
- 在判断延迟发生在哪一环节之前，请将所有时间戳统一换算为同一时区进行比较。
如果 tiket.com 中有该预订但服务商处没有，说明中断发生在服务商的上游。如果服务商已发送而酒店管理系统拒绝了它，请调查导入错误。如果酒店管理系统中包含了该记录但不在到店(Arrivals)视图中，请更正筛选器或运营状态，而不是再次导入。
Smart Order 的 酒店渠道管理系统 可将传入的 OTA 参考号与映射的客房房态以及酒店管理系统预订路径紧密绑定，让您能够更轻松地定位最后一次成功的交接环节。
在重试前追踪 Tiket.com 预订
将传入的预订、已映射的客房和酒店管理系统房态关联起来，这样员工就可以在不产生重复预订的情况下隔离出失败的数据交接环节。
检查直连与产品映射
确认 tiket.com 直连对于正确的酒店处于激活状态，并且已启用预订下发方向。近期成功的房价更新并不能证明传入的预订功能正常；这两种数据流可能使用的是不同的服务。
将 tiket.com 的酒店、客房和房价计划标识符与酒店渠道管理系统的映射以及处于激活状态的酒店管理系统产品进行对比。在客房重命名、房价计划被克隆、产品被停用或酒店重新连接之后，请特别注意。仅仅显示名称匹配是不够的。
检查入住人数、儿童政策设置、餐食、取消条款、定价模式和货币。服务商可能会接收到该预订，但由于组合后的客房-房价产品在酒店管理系统中没有有效的目标对应，或因包含了不支持的必填值而拒绝它。
不要仅仅为了让某一个预订通过而重新映射正在使用中的客房。请确认实际的房源库存和商业条件，保存旧的映射记录，获取批准，并在低风险产品上测试更正后的映射。
检查酒店管理系统导入与到店规则
在更改数据之前，请阅读酒店管理系统返回的确切拒绝原因。常见原因包括酒店未激活、客房或房价映射缺失、入住人数无效、外部 ID 重复、存在不支持的字符、缺少必填的宾客字段、营业日期已关闭，或者是修改请求在初始预订之前送达。
如果没有出现拒绝提示，请在默认的到店列表之外进行搜索。检查酒店范围、到店时间范围、营业日期、时区、预订状态、排房情况、来源筛选器和用户权限。已修改的预订可能已经移出了今天的时间窗口，而取消的预订可能只保留在历史记录中。
如果源 ID 已经存在，请保留部分导入的数据。修复或重放该直连记录，而不是创建无法接收后续修改或取消的第二条重复预订。
保护宾客与房源库存
当 tiket.com 确认预订后，在继续进行技术排查的同时，酒店前台管理系统需要提供运营保障措施。
- 最后一次使用行程 ID 搜索每一个系统。
- 通过酒店批准的异常处理流程，保留出正确的实体客房。
- 仅当即将到店的政策有硬性要求时，才在酒店管理系统中创建临时记录。
- 将其标记为 pending tiket.com sync reconciliation（等待 tiket.com 同步对账） 并包含外部参考号。
- 准确复制日期、客房、房价、入住人数、支付方式、取消条款以及包含的项目。
- 在临时记录上禁用重复的预订确认、付款、访问密码和评价自动化任务。
- 指定负责人并设定在系统恢复后合并或停用该临时记录的截止日期。
不要因为内部数据交接失败而取消已确认的渠道预订，或者要求宾客重新预订。不要在多个系统中独立减少房态。记录一项临时控制措施，然后在直连预订送达时进行对账。
电子邮件是有用的后备提醒，但不能作为酒店管理系统交付成功的证据。Tiket.com 会向具有管理员或预订角色的用户发送新预订电子邮件；其预订电子邮件指南解释了角色、地址或黑名单问题会如何阻止这些消息的发送。请将电子邮件路由问题的修复与系统集成故障分开处理。
重试一次并验证恢复情况
询问直连服务商其是接收推送通知、主动拉取预订，还是使用其他获批的方法。恢复操作必须与该连接方式相匹配。
首先更正特定错误。然后使用相同的行程 ID 对原始事件进行一次重放或重新拉取。在重试之前，请确认没有延迟送达或稍后的修改已经处于排队状态。多名员工重复相同操作可能会产生重复的酒店管理系统记录或导致消息处理顺序错乱。
只有在满足以下条件时，恢复才算完成：
- 一条酒店管理系统预订记录包含了正确的 tiket.com 和服务商参考号；
- 客房、房价计划、日期、入住人数、价格、支付说明和状态与 Extranet 一致；
- 共享房态库存只精确扣减了一次；
- 临时保留或手动记录已被对账解决，且未丢失任何备注或任务；并且
- 随后的修改或取消操作仍然可以更新该条直连记录。
如果问题未解决，请携带酒店 ID、行程 ID、客房和房价计划标识符、带有时区的时间戳、服务商消息 ID、映射截图、酒店管理系统错误文本、变更前后的房态，以及已经采取的各项措施向上级进行升级反馈。对于当天到店、最后间房态、多条预订缺失或积压队列不断增长的情况，请在运营团队优先保障宾客权益的同时立即升级问题。
常见问题解答
员工应首先在哪里检查丢失的 tiket.com 预订？
检查 Bookings > Search Bookings（预订 > 搜索预订） 或 Lignum Reservations（预订） 区域中正确的酒店。在更改酒店管理系统之前，请先确认行程 ID 和状态。
在预订失败时，房价能够正常同步吗？
是的。向外推送的房价和房态（可用状态）与传入的预订下发可能使用不同的传输方向或服务。请独立验证这两种数据流。
前台应该手动创建预订吗？
仅当获得批准的异常处理流程要求立即提供保护时才应进行操作。请将其标记为待对账，防止触发重复的自动化任务，并在夜审前搜索是否有被延迟的直连预订送达。
为什么预订仅仅在到店(Arrivals)视图中缺失？
它可能被分配到了其他的酒店、日期、状态、排房、时区或权限范围下。请使用外部参考号和宾客姓名在整个酒店管理系统中进行全面搜索。
什么能证明问题已经解决？
一条与 tiket.com 匹配的直连酒店管理系统预订记录正常显示，房态仅变更了一次，所有临时控制措施均已对账处理完毕，并且未来的预订事件能够更新同一条记录。
当宾客得到有效保障且预订可端到端追溯时，缺失的 tiket.com 预订问题才算解决。请首先确认渠道记录，仅修复失败的交接环节，并以一条无误的酒店管理系统预订记录来终结该事件。
