1. 每次仅核查一家酒店、一个日期范围、一种房型、一个房价方案和一种入住人数配置。
2. 对比实际可售客房、酒店管理系统房态、TERA 库存以及 Traveloka 实时在售房源。
3. 在控制渠道房态的系统中完成修正，并重新测试所有受影响的房型，确认无误后再结束故障处理。
当客人可预订的客房数量或房型，与酒店管理系统中酒店认定的可售房态不一致时，就会出现Traveloka 房态不一致问题。该问题可能仅影响一个房间、一个房价方案、某一天，也可能波及整家酒店。
最快且稳妥的处理方式并不是修改整家酒店的库存，而是逐房型核查，找出数据最先出现偏差的环节。
本指南不讨论已确认的 Traveloka 预订未进入酒店管理系统的情况，而是聚焦新预订产生之前对外展示的可售库存。
修改库存前先明确核查范围
选择一个较短的日期范围，其中应包含问题日期，以及至少一个房态看起来正常的相邻日期。使用统一的标准客人搜索条件，包括相同的房间数、成人数、儿童数和住宿晚数。
记录核查时间。预订、取消、手动调整或锁房后，房态都可能发生变化，因此在不同时间进行对比可能造成虚假的不一致。
如果酒店已经满房或面临紧迫的超售风险，应暂时仅保护受影响的房型和日期。记录所有紧急手动操作，以便正常连接恢复后及时撤销。
分 7 步核查每个 Traveloka 房型
完成一个房型的全部核查后，再处理下一个房型。这样更容易找到第一个出现错误的数据。
- 确认实际可售客房数量。首先核实酒店实际能够履约接待的客房。对于故障停用或在酒店管理系统之外已被占用的房间，只有在相关锁房记录仍然有效且信息最新时，才应从可售数量中扣除。
- 检查酒店管理系统中的房型。按每个入住日期记录客房总数、在住房数、已确认到店数、离店数、维修锁房、业主锁房以及最终可售数量。
- 匹配 Traveloka 房型名称。确认哪个TERA房型映射到酒店管理系统中的对应房型。名称相似、房型更名或近期新增房型，都可能导致其指向错误的库存池。
- 检查所有已连接的房价方案。即使某个方案已经关闭，纯住宿、含早餐、可退款、不可退款或促销方案仍可能处于可订状态。确认所有方案是否共享同一客房库存。
- 逐日对比 TERA 库存。检查是否有某一晚的数量不同、开放或关闭状态不一致，或者是否存在上次酒店管理系统更新后手动录入的数值。
- 复现客人端的实时搜索。使用相同的日期和入住人数配置，确认 Traveloka 实际提供的房型、方案和数量。房型可能可见但无法预订，因此操作到足以确认房态即可，不要提交真实预订。
- 记录第一个出现差异的环节。准确描述不一致情况，例如："酒店管理系统显示 11 月 12 日豪华双床房为零间，TERA 显示一间，而灵活取消的含早餐方案仍可预订。"这就是需要修正的目标。
对每个受影响的房型重复以上七个步骤。不要以为修复一个映射后，整家酒店的其他房型也会自动恢复正常。
当管理者需要在多个页面之间手动对比每个房型时，很容易遗漏仍保留库存的某个方案。Smart Order 将酒店管理系统房态与渠道分销连接起来，让团队能够在一个酒店工作台中查看客房数量及每次更新结果，确认无误后再重新开放销售，减少人工核查时间和超售成本。
让各渠道的客房房态始终保持一致
在同一个酒店工作台中高效管理已连接渠道的客房库存，及时发现房态差异，避免不必要的超售与运营成本。
判断房态不一致的规律
如果只有一个房型的数据错误，请检查该房型的映射、房价方案和近期手动修改记录。当其他房型均保持一致时，整家酒店的连接出现问题的可能性较低。
如果所有房型在相同日期的数据都不正确，请检查酒店连接是否已暂停、负责控制库存的系统是否停止发送更新，或者是否有人直接在 TERA 中修改了库存。
如果仅出现某一种入住人数配置或套餐，基础客房库存可能没有问题，但关联的在售方案使用了独立设置。修改主房型数量前，应沿着客人端的实时在售方案追溯到其对应的房型和房价方案。
如果不一致从某个确切日期开始，请检查该时间前后的预订、取消记录、锁房和批量更新。之后单独录入的一个手动数值，可能会覆盖此前正确的更新。
修正数据源，而不是逐个页面修改
首先确定由哪个系统负责向 Traveloka 发送房态。如果连接由多渠道管理系统控制，应在该系统中修正客房数量或映射，并让系统发送更新。手动修改 TERA 可用于紧急保护，但不应作为长期解决方案。
如果酒店管理系统中的数量有误，应修正导致该数量错误的预订、锁房或维修状态。不要强行让 TERA 匹配一个酒店无法解释的数值。
如果 TERA 显示的房型或房价方案没有有效的酒店管理系统映射，应保持关闭状态，直到产品完成映射和测试。重新开放一个身份不明的在售方案，只会让房态不一致再次发生。
每次只进行一项受控修正。同时修改多个项目会让团队难以判断哪项操作真正生效，还可能导致下一次更新撤销修复结果。
逐房型重新测试整家酒店
更新后，对每个受影响的房型重复相同的客人端搜索和 TERA 检查。确认最初的问题日期、其前后日期，以及至少一个应当开放销售的未来日期。
只有当实际可售客房、酒店管理系统房态、TERA 库存和 Traveloka 实时在售房源完全一致时，核查才算完成。仅看到更新成功提示并不代表故障已经排除。
只有在正常连接已经发送正确数值后，才能撤销临时手动关闭。记录最终数量、截图、修正操作以及批准重新开放销售的人员。
预防下一次房态不一致
每当新增、重命名、拆分、合并或删除房型时，都应检查房型映射。映射变更后，应测试所有房价方案，而不仅是基础方案。
为员工制定清晰的 TERA 手动修改规则。紧急修改记录应包含房型、日期、原因、负责人，以及必须复核或撤销的时间。
批量更新库存、连接中断或出现大量取消后，应进行一次简短的逐房型抽查。少量检查远比客人到店后再处理超售更快捷，也更节省成本。
常见问题
为什么 Traveloka 显示的客房数量比酒店管理系统更多？
常见原因包括房型映射错误、房价方案使用独立配额、TERA 中存在手动录入的数值、锁房未减少可售库存，或者更新未能传送至渠道。
酒店是否应将 Traveloka 上的所有房型库存设为零？
只有当整家酒店确实无房可售，或酒店无法确定哪些产品可以安全销售时，才应这样做。否则，只需保护范围最小的受影响房型和日期。
促销活动会造成房态不一致吗？
促销活动通常只会改变在售方案，但它也可能展示员工在最初核查时未包含的房价方案或入住人数配置。应追溯促销方案对应的基础房型和库存来源。
TERA 还是酒店管理系统才是数据基准？
这取决于酒店的连接设置。运营数据应以被指定控制 Traveloka 库存的系统为准，而实际可售客房数量始终是最终的业务限制。
如何确认房态不一致已经修复？
针对相同的房型、日期和入住人数配置，确认酒店管理系统、TERA 和客人端实时搜索中的数量均已修正。然后检查相邻日期，并撤销所有临时手动覆盖设置。
