多人间床位库存怎么同步到 OTA 才不超售

一间独立房是一个可售单位。一间十二人的多人间是十二个可售单位，只不过它们共用一扇门。青旅里绝大多数超售，追到最后都是某个系统、某个渠道或者某个人，把这两者当成了另一个。

下面是床位库存到底怎么对应到 OTA 的房型上、错位通常出在哪里，以及开新渠道之前该检查什么。

先想清楚你的多人间是怎么卖的

动任何设置之前，先确认自己在跑哪一种模式。同样十二张床，可以有三种卖法。

• 按床卖，不分性别。谁都能订任何一张床。十二个库存单位，一个价格。同步起来最简单，落地管理起来最麻烦。
• 按床卖，分池。女生间、男生间、混住间是三个不同的商品，哪怕物理上是同一种房型。每一个分池有自己独立的库存。
• 整间卖。这间多人间也可以整间包给一个团队。它是一个库存单位，一旦卖掉，必须同时扣掉十二个。

第三种是系统最容易崩的地方。卖掉整间必须关掉所有床位，卖掉最后一张床必须关掉整间。这两条规则如果没有绑在一起，你迟早会把一张床卖进一个已经被家庭客包下的房间。

错位通常出在哪

渠道本身不支持床位级库存

有的平台原生就把多人间理解成床位，有的只理解"房间"，变通做法是建十二个只住一人的"房间"。这个做法能跑，但它意味着你从这个渠道拉出来的入住率、平均房价和任何报表，数的东西和你 PMS 里的不是一回事。提前决定哪一个数字算数。

价格方案会膨胀得比你预想的快

三个多人间分池、两种取消政策、再加一个不可取消价，还没开第二个渠道就已经是十八种组合。每一种组合都是一条可能配错的对应关系。刻意把这张表压小：六个价格方案和十八个价格方案之间的收入差，通常小于配错一条的代价。

用分配额度而不是共享库存

如果你给一个渠道分四张床、另一个渠道分四张，而不是让所有渠道从同一个池子里取数，你会出现"账面满房、床位空着"的情况。五十张床以下的小店，几乎都应该用共享库存加实时推送。分配额度是大体量做风险控制的工具，不是给小店用的。

只在一边下架的维修床位

一张床在 PMS 里报修下架了，渠道管理器里没下架，这一定会变成一次"有单没床"。这是我们见得最多的一种，而它完全是库存存在于两套系统的后果。

改价和改房量走的不是同一条路

有些配置里，房量是实时推的，价格是按计划任务批量推的。平时看不出来，遇到临时调价就会出现"房还在卖、价格还是旧的"。开渠道的时候顺手确认一下这两条路各自多久同步一次。

混合房型的设置清单

1. 先在纸上画出库存地图。每一张实体床、它属于哪个池、能不能同时作为整间商品的一部分卖出去。打开任何后台之前先画完。
2. 所有地方用同一个名字。PMS 里叫"6楼混住12人间"，每个渠道上就叫"6楼混住12人间"，不要写成"混住12人间6楼"。以后要在赶时间的情况下肉眼对这些名字的是你自己。
3. 定下你的统计单位。床或房，报表只用一种，换算放在边界上做，不要放在中间。
4. 把整间商品和床位池显式绑起来。如果你的系统做不到这件事，就别把整间拿出来卖。这点收入不值得赔一次安置。
5. 先开一个渠道，等一周。看一张真实订单怎么流过来，再开第二个。一个渠道时一眼能看见的问题，四个渠道时就变成考古了。
6. 测一次关房。手动把一张床设为停售，然后逐个渠道确认它真的消失了。没消失就停下来先修这个，别往下走。
7. 每次结构性改动之后重测。新房型、改名、改容量——每一次都是一轮重新验证，不是改一行字那么简单。

结构上的解法

上面这张清单，大部分是在防"库存存在两个地方"这件事。当房态日历和渠道对接是同一套系统，床位池和整间商品共用一个来源，把一张床下架就是一个动作而不是两个。Kimchee 是这么处理多人间的：床位级库存，渠道管理器包含在里面，所以没有第二份库存要对齐。可以接的平台列在渠道页面，床位和房间怎么排、怎么算钱在功能页面和价格页面上（多人间按 4 张床折算成 1 间房）。

我们做成这样，是因为我们自己在釜山的三家住宿就同时卖多人间和独立房间，维修床位这个问题在我们把它从结构上解决之前，实打实赔过几次安置。

这周可以做的一件事

不管你用的是什么系统，去跑一次关房测试。把一张床停售，然后打开你在卖的每一个渠道，确认它不见了。十五分钟，它告诉你的东西比任何功能对比表都多。如果某个渠道没跟上，你就找到了下一个任务——而且是在周二下午找到的，不是晚上十一点、客人站在门口的时候。