酒店管理系统与OTA房型映射：为什么小错误会导致超售

酒店管理系统和OTA中的房型映射决定了每一个预订订单、房价和可用房态的去向。一个错误的关联可能会让已经售出的客房在其他渠道上继续保持开放状态，从而在软件正常同步的情况下仍然造成超售。

当房型名称看起来相似时，风险是最高的。映射必须基于实际的客房、入住人数、价格条件和库存池，而不是看起来最相近的标签。

酒店房型映射实际上连接了什么

酒店房型映射是将您的 酒店管理系统 (PMS) 与Booking.com、Expedia、Agoda、Airbnb或其他OTA上匹配的产品进行关联的过程。

酒店管理系统和OTA各自保持独立的记录。每一方都会为自己的 房型和房价 分配专属的标识符。映射的作用就是告诉酒店渠道管理系统，一个特定的酒店管理系统产品和一个特定的OTA产品代表的是同一事物。

必须对齐以下四个层面：

• 房型： 实体分类，例如标准大床房、豪华特大床房或家庭套房。
• 房价： 价格和预订条件，例如灵活取消、不可退款、含早或提前预订。
• 库存： 该房型在每一天可供销售的客房数量。
• 限制条件： 如最低连住天数、限制预订抵达、最大入住人数或预订窗口等规则。

Booking.com将可售卖的“房型价格（roomrate）”描述为房型、房价和预订条件的独特组合。可能存在房型映射正确，但其中的某个房价映射错误的情况。

例如，一个豪华特大床房可能有灵活取消和不可退款两种房价。两者都连接到相同的实体库存，但各自保留了独立的价格和条件。

一个小小的映射错误是如何演变成超售的

假设一家酒店在周五还剩下一间标准大床房，而其豪华特大床房已售罄。

如果OTA上的豪华特大床房被意外映射到了酒店管理系统的标准大床房库存上，OTA可能会继续销售豪华特大床房。预订订单下达后，酒店却由于没有豪华特大床房而无法分配房间。与此同时，剩下的那间标准大床房可能会被关闭，尽管实际上并没有人预订它。

另一种故障情况发生在两个OTA房型将同一个实体房间池作为独立库存进行销售时。酒店管理系统可能会向两者都发送“可用房态：1”，从而导致两名宾客同时预订最后一间客房。

这并不总是同步故障。酒店渠道管理系统可能会完全按照配置传输每一次更新。问题在于配置指向了错误的库存池。

一个清晰的连接应该遵循一个具体的流程：OTA预订订单进入酒店管理系统，正确房型的库存减少，更新后的房态通过酒店渠道管理系统返回，然后所有连接的OTA都会显示新的数量。

Smart Order 的 酒店渠道管理系统 按照该顺序连接了预订来源、酒店管理系统库存和OTA房态。这为团队提供了一个统一的界面，来确认哪个房间已售出，以及各个渠道的剩余数量是否发生了变化。

房型必须与实体库存相匹配

从您在办理入住时实际可以分配的客房开始。只有当实体客房对宾客来说真正可以互换时，才将它们归为一类。

两间客房不应仅仅因为拥有相同的床就共享一个房型。如果宾客是为海景买单，那么海景大床房和内窗大床房就需要分成不同的类别。

不同系统中的名称可以有所不同，但含义必须一致。检查床型、入住人数、景观、浴室以及其他承诺的属性。

不要为了迎合不同OTA的用词而创建重复的酒店管理系统房型。如果Booking.com上写着“高级双人房”，而Expedia上写着“豪华大床房”，只有当它们代表相同的实体库存时，两者才能映射到一个酒店管理系统的豪华大床房类别。

还要检查数量。一个拥有5间实体客房的酒店管理系统类别绝不能因为保留了一个未激活的OTA客房而显示为6间。确认将房间标记为停用状态是否会减少OTA库存。

房价需要单独的映射

房型映射只是设置工作的一半。每一个激活的OTA房价都必须连接到正确的酒店管理系统或酒店渠道管理系统的房价。

一个灵活取消的仅含房费房价不应映射到不可退款的含早房价。实体客房可能没错，但宾客可能会收到错误的取消条款、包含内容或价格。这不仅会引起纠纷，还可能在测试期间掩盖更深层次的库存问题。

对于衍生价格，更改母价格并确认OTA收到了预期的子价格。名称匹配并不能证明两者关系有效。

同时检查基于入住人数的定价。如果酒店管理系统发送的是一个基础价格，而OTA期望的是按入住人数计算的价格，房态可能准确，但显示的价格却会出错。

最安全的顺序是先设置房型，然后再设置房价。Smart Order 的 酒店管理系统连接前检查清单 也建议在关联房价和连接OTA之前，先创建房型和具体的房间。

库存映射是存在超售风险的地方

库存通常应在房型层面上进行控制，因为该客房的所有房价都是从同一个实体池中提取的。以不可退款价格售出一间标准大床房，也必须相应减少灵活取消标准大床房的可用房态。

当房价表现得像独立的库存池时，问题就出现了。在三种价格下展示的同一间客房，它仍然是那最后一间客房。

审查一个淡季日期、一个接近售罄的日期和一个受限制的日期。确认在任何有意的渠道分配后，酒店管理系统和OTA的数量均能保持一致。

在库存源头将一个房型的可用数量从3减少到2。每一个映射的OTA产品都应该变为2，而不改变任何不相关的客房。

连接后，应限制在OTA后台进行手动编辑。添加房型或重命名房价可能会创建一个酒店管理系统无法控制的未映射产品。

在正式上线前运行测试预订

绿色的“已连接”状态仅证明系统之间可以通信。它不能证明每一个客房、房价、限制条件和预订订单路径都是正确的。

测试每一个库存池，以及具有不同支付或取消条件的任何价格。

使用此上线检查清单：

1. 选择具有充足可用房态的未来日期，并记录酒店管理系统和OTA中的初始数量。
2. 确认公开的房型名称、入住人数、房价、税费、餐饮包含项、取消政策和限制条件。
3. 通过OTA下达一个真实的测试预订订单，然后确认它以正确的房型和房价进入到酒店管理系统中。
4. 验证酒店管理系统库存减少了1，并且新的数量同步到了每一个已连接的渠道。
5. 修改预订订单，然后取消它，并确认日期、价格、状态以及释放的库存更新正确。
6. 对每一个不同的客房库存池重复测试，并在开放全部房态之前调查任何不匹配的情况。

除了后台系统外，也要检查面向宾客的预订页面。那才是定价、入住人数和限制条件最终展示的地方。

记录截图、时间戳、预订订单ID、预期结果和实际结果。这样更容易将映射错误与更新延迟或OTA端的配置问题区分开来。

谁应该对房型映射负责

指派专人负责映射记录，即使酒店管理系统供应商协助进行了技术对接。酒店仍有责任决定哪些产品才是真正等同的。

保留一份映射表格，其中包含酒店管理系统房型、客房数量、房价、OTA房型和房价名称，以及连接状态。在任何产品变更后及时更新。

在翻新改造、房型重命名、新房价发布、OTA迁移或渠道管理系统变更后重新测试。上个旺季有效的设置，如果在一方改变了其产品结构后，可能就不再安全了。

最好的预警信号是所预订的内容与酒店管理系统导入的内容之间存在任何不匹配。将错误的房型名称、出乎意料的入住人数、缺失的餐饮计划或未改变的库存视为映射事故——而不是无害的显示错误。

常见问题

什么是酒店管理系统中的房型映射？

房型映射将酒店管理系统或酒店渠道管理系统中的房型和房价关联到OTA上的匹配产品。它确保了预订订单、房价、限制条件和库存更新能够传达到正确的客房。

错误的房型映射会导致超售吗？

是的。错误的映射可能会将一个实体库存池的可用房态发送到另一个，或者允许重复的OTA产品独立售卖同一间最后的客房。系统可能在销售错误库存的同时仍然显示连接成功。

是否每个OTA房型都应映射到一个酒店管理系统房型？

每一个OTA房型都应映射到代表相同实体客房的酒店管理系统房型。有时多个OTA房源可以映射到一个酒店管理系统房型，但前提是它们从相同的库存中提取，并且对宾客而言是可互换的。

不同房价共享相同的客房库存吗？

附属于同一个房型的房价通常从相同的实体库存中提取。灵活取消和不可退款的标准大床房是针对同一个客房池的两种优惠方案，而不是两间独立的客房。

如何测试OTA和酒店管理系统的房型映射？

检查公开房源信息，下达一个未来日期的测试预订订单，确认它以正确的房型和房价导入，并验证每一个已连接OTA的可用房态是否均减少。然后修改并取消预订，以测试完整的更新周期。

防止大多数错误的映射规则

按实体库存和预订条件进行映射，而不是按相似的名称。房型回答了“酒店可以分配哪间客房？”房价回答了“能在什么价格和条件下售卖？”库存回答了“这些日期还剩多少间？”

当这三个问题的答案在酒店管理系统、酒店渠道管理系统和OTA中完全一致时，一个预订订单就会在所有平台上关闭正确的可用房态。当其中一个答案出现差异时，一个小小的设置失误就可能演变为宾客换房、退款或超售事故。