1. 在进行任何创建或取消操作之前,请先确认该预订是否存在于正确的 Traveloka TERA 住宿中。
2. 追踪从 Traveloka 到多渠道管理、映射层、酒店管理系统导入队列以及到达视图的预订信息。
3. 保护已确认的宾客和房态库存,避免触发重复导入或自动发送重复的通知消息。
4. 仅在找出失败步骤后重试,然后验证系统中只存在一条酒店管理系统预订记录,且房态仅变更了一次。
一条 未在酒店管理系统中显示的 Traveloka 预订 并不一定意味着 Traveloka 系统出现故障。该预订可能已在 TERA 中确认,但在多渠道管理处出现延迟、被映射规则拒绝、停留在酒店管理系统导入队列中,或者被到达列表的过滤器所隐藏。
在判断宾客是否有已确认的渠道预订时,请将 Traveloka 记录视为首要事实来源。然后追踪每次数据交接,切勿重复导入同一条预订。
在 Traveloka TERA 中确认预订
登录 TERA,选择正确的住宿,并使用其 Traveloka 预订或订单 ID 搜索该预订。确认宾客姓名、入住日期、房间、房价计划、入住人数、预订状态、支付状态、总价以及创建或修改时间。
如果该预订未在 TERA 中显示,请勿仅凭宾客的截图在 酒店管理系统 中创建预订。请确认该信息属于同一家住宿,并且来自经过授权的 Traveloka 渠道。预订错酒店、已取消的退房尝试或欺诈信息都不应占用您的房态库存。
如果预订存在且已确认,请保存标识符并妥善保护宾客权益。Traveloka 将 TERA 定位为合作伙伴监控预订、入住办理、宾客需求和支付状态的平台,并可在运营设置中开启酒店预订通知和多渠道管理集成功能。Traveloka 目前的 TERA 概览 均支持这些功能。
2025 年 7 月推出的 TERA 主页还包括预订概览和左侧导航栏。请匹配账户中显示的实际功能,而不是依赖旧版的菜单标签。Traveloka 的界面更新文档已详细说明了这一布局变化。
寻找数据交接的中断点
已连接的预订通常遵循一条路径:Traveloka 确认预订,连接服务提供商接收或检索该预订,映射层识别住宿、房间和房价计划,酒店管理系统将其导入,最后到达视图显示最终生成的记录。
在每个层级检查相同的预订 ID。如果服务提供商日志中缺少该 ID,则问题出在上游。如果提供商成功送达但被酒店管理系统拒绝,则问题出在下游。如果酒店管理系统已完成导入但未在“到达”列表中显示,则问题在于过滤器或预订状态,而不是传输过程。
请在统一的时区下记录时间戳。否则,Traveloka 创建时间、提供商接收时间、酒店管理系统导入时间和当地酒店时间的差异,可能会让原本正常的顺序显得像是有延迟或乱序。
Smart Order 的 酒店渠道管理系统 将 OTA 预订传输与酒店库存记录无缝对接。当单笔预订可以通过该路径进行追踪时,工作人员就能有效地保护房间状态,而无需维护第二个不受控制的导入流程。
端到端追踪单笔 Traveloka 预订
将渠道传输、映射的房间房态以及酒店管理系统预订整合在一个工作流中,以便准确定位丢失的到达预订,避免盲目重试。
检查连接、映射和导入规则
请确认目标住宿的 Traveloka 连接处于活动状态,并且凭证或授权尚未过期。仅查看账户级别的绿色正常状态是不够的;请详细检查丢失记录前后的单笔预订流向和最近一次成功的预订记录。
将 Traveloka 的住宿、房间和房价计划 ID 与提供商的映射关系进行对比。相似的显示名称并不代表两者等同。新增房间、克隆房价、重命名房价计划或重新连接住宿,都可能导致预订无法匹配,即使房态和房价更新仍在继续。
接下来检查酒店管理系统的导入队列和拒绝日志。常见原因包括未映射的房间或计划、重复的来源 ID、无效的入住人数、缺少必填的宾客字段、不受支持的字符、财务日期已关账、住宿处于非活动状态,或者预订更新先于原始预订到达。
切勿仅为了强制通过单笔预订而更改房间映射。首先请确认物理房态库存和商业条件;仓促的重新映射可能会导致未来的 Traveloka 预订落入错误的房间池中。
检查酒店管理系统是否隐藏了该预订
通过 Traveloka ID、宾客姓名、到达日期、预订日期、电子邮箱和提供商参考号,在酒店管理系统中进行全局搜索。该记录可能存在于默认的到达列表之外。
检查住宿、到达日期范围、预订状态、房间过滤器、用户权限、时区,以及该视图是否排除了已取消、未分配、待处理或已导入的预订。在进行任何手动创建之前,还要搜索重复和已归档的记录。
预订修改可能会将入住时间移出当天的到达窗口。取消预订会将其从有效到达列表中移除,但保留预订历史。时区转换可能会将深夜的预订归入前一个或下一个营业日期。
如果酒店管理系统中有来源 ID 但预订详情不完整,请将其视为部分导入。请保留该记录,并通过集成工作流修复丢失的字段,而不是创建第二条预订记录。
安全保护宾客和房态库存
一旦 TERA 确认了预订,即使自动导入问题尚未解决,也应锁定正确的物理房态库存。仅在酒店政策允许的情况下,使用临时的运营占房,或在酒店管理系统中创建标记清晰的手动记录。
- 记录 Traveloka ID,并将该项目标记为待渠道对账。
- 匹配已确认的房间、房价、日期、入住人数、支付状态和宾客联系方式,切勿存储违规的支付数据。
- 通过指定来源仅锁定一次房态库存,并验证无关的房间保持不变。
- 在任何临时记录上禁用重复的确认、支付、门禁码和评价等自动化操作。
- 指定责任人和截止日期,以便在集成恢复后替换、合并或停用临时记录。
切勿为了清理酒店管理系统而取消 Traveloka 预订。不要要求宾客重新预订。内部传输失败不应更改有效的渠道合同,也不应让宾客面临被二次扣费的风险。
重试且不创建重复预订
在重试之前,请确认提供商是否使用 Traveloka 预订 ID 作为幂等性或重复控制键,并确认后续的修改或取消操作是否已在排队中。盲目重放可能会创建两条酒店管理系统记录,或者导致事件无序执行。
从最早确认的失败点开始重试。如果提供商未曾收到预订,请使用其批准的检索或上报路径。如果酒店管理系统拒绝了它,请修正具体的映射或验证错误,并将同一数据源事件重放一次。
恢复后,再次进行全局搜索。一条酒店管理系统预订记录应包含 Traveloka 来源 ID、正确的房间和房价、当前状态、支付数据以及修改历史。房态应只发生一次变更——而不是临时占房变更一次,导入预订时又变更一次。
只能通过受认可且保留审计追踪的工作流来合并或停用临时记录。转移房间分配、备注、押金、任务和宾客沟通记录时,不能破坏已连接预订的后续更新链路。
凭可复现的证据进行申诉上报
向负责的提供商发送一份完整的事件报告。包括住宿和 Traveloka ID、房间和房价计划代码、预订状态、创建和修改时间、提供商消息 ID、送达回执、酒店管理系统错误文本、映射截图、搜索过滤器、操作前后的房态库存,以及已经采取的措施。
明确陈述预期结果和实际结果:“已确认的 Traveloka 预订 X 应在房间 Y 和房价 Z 下创建一条酒店管理系统预订;截至时间 T,未见酒店管理系统记录或拒绝信息。”这比单纯说“预订丢失”更有可操作性。
针对当日入住、最后可用房态、支付存疑、多笔预订丢失或队列不断增长的情况,请立即上报。将酒店前台管理系统及收益的负责人与技术调查分开,确保宾客和房态库存持续受到保护。
常见问题解答
员工应首先去哪里检查丢失的 Traveloka 预订?
在更改酒店管理系统之前,请先在 Traveloka TERA 中检查正确的住宿,并确认预订 ID、状态、日期、房间、房价、入住人数和支付状态。
在预订失败的情况下,房价还能同步吗?
可以。出站的房价和房态可以与入站的预订使用不同的传输方向或流程。请分别测试和监控这两个数据流。
前台应手动录入预订吗?
仅当酒店政策要求立即进行运营保护时才可以。将其标记为待对账,使用 Traveloka 来源 ID,防止自动化重复操作,并规划在导入完成后如何处理该记录。
为什么该预订仅在“到达”列表中缺失?
酒店管理系统可能将其归入了不同的住宿、日期、状态、房间、权限范围或时区下。在判定为传输故障之前,请先进行全局搜索。
多次重试导入安全吗?
不安全。首先需确定失败的步骤并确认防重控制机制。重复重放已确认的事件可能会创建重复记录,或导致修改操作乱序执行。
什么能证明问题已解决?
一条已连接的酒店管理系统预订与 TERA 匹配,当前修改均已呈现,房态仅变更一次,临时占房已对账清理,且后续更新均遵循同一数据源记录。
当预订在运营层面得到保护,且在技术层面可追溯时,缺失的 Traveloka 到达预订问题才算真正解决。首先确认 TERA 数据,隔离数据交接的中断点,仅修正该问题点,最后用一条干净的酒店管理系统记录结束此事件。