渠道管理器单独收费，还是包含在 PMS 里

如果你手上是一家二三十个床位的青旅或民宿，多半被报过两次价：一次是管房态的 PMS，一次是把房量推到 Booking.com、Agoda、Trip.com 的渠道管理器。两个后台、两张账单、两个客服入口，中间还夹着一块没人愿意碰的房型对应设置页。

这不是技术上必须如此，而是行业长成的样子。它的代价通常不写在报价单上。

这条缝是怎么来的

渠道管理器出现得比小旅舍用上 PMS 要早。那时候一家青旅的房态可能就是一张表格或者墙上的格子纸，急着要解决的是几家 OTA 各有各的后台。于是有人做了个"把一个数字推到几个后台"的工具，它不关心你店里用什么系统，所以单独卖、单独收费。

后来做 PMS 的公司面临选择：自己做对接，慢，而且永远做不完，因为各家平台的接口一直在变；或者接已经存在的渠道管理器。多数人选了后者。二十年过去，这个决定还留在你的账单上。

拆成两套，真正要付的是什么

月费是大家都会比的那一项，也是比较小的那一项。后面还藏着四笔。

一、房型要建两遍，改也要改两遍

你的房型在 PMS 里有一份，在渠道管理器里还有一份，两份必须对得上。新增房型、把一个大间拆成两个、为了做活动改个名字——每次都要做两遍。对应关系错了不会弹报错，你是从站在前台的客人那里知道的。

二、超售就住在两套系统的缝里

一张订单先落到渠道管理器，再进 PMS，PMS 再把新的可售数推回去。每跳一次都有延迟。平日里这点延迟看不见；等到某个展会周末把最后四张床卖光的那天晚上，它就是"干净关房"和"两个人拿到同一个床位号"的区别。订单跨过的边界越多，能卡住的地方就越多。

三、出了问题先要分清是谁的问题

价格没在 Agoda 上出现，你有三个可能的原因、两家供应商，而且两边都能合理地指向对方。光是确认这是谁的事，花的时间常常比修好它还多。

四、按连接数收费，会越用越贵

不少渠道管理器按连接数计费，而不是按门店计费。你想开 Hostelworld 拿床位客源，这件事不是免费的，于是你开始根据连接费决定要不要上一个渠道，而不是根据这个渠道带来什么样的客人。这是一个很差的关店理由。

还有一笔不在账单上：注意力。两套系统意味着两套版本更新、两次权限设置、两轮给新员工的培训。十间房的店里，这些事都落在老板自己身上。

怎么比才不会被表面价格骗到

打包价放在"只有 PMS"的价格旁边一定显得贵，因为它盖的是两件事。只比标价等于什么都没比。把每月实际支出算出来，然后对每一家供应商——包括打包的那家——问同样几个问题。

• 渠道管理器按门店收还是按连接数收？如果按连接数，请用你真实的渠道清单算，不要用入门套餐算。
• 两边有没有开通费、实施费？这类费用常常只在报价时说一次，比较的时候就被忘掉了。
• 合约要签多久，到期之后数据怎么办？
• 和 OTA 的对接关系挂在谁名下？如果挂在渠道管理器那边，以后换 PMS 就要和每一个平台重新走一遍认证。
• 改一次价格，多久能到 OTA？这个数字写在合同里还是写在宣传页上？

把这些加总，再除以你的房间数。"每间房每月一共花多少钱、且不再有额外账单"——只有这个数字值得跨供应商比较。

并成一套之后会变的地方

当房态和渠道对接是同一个产品，房型就只存在一份。一张床报修下架，它在所有渠道同时下架，因为没有第二份库存要跟着改。房型对应变成开业时做一次的事，而不是长期的杂活。某个渠道上东西没出现时，只有一个地方要查。

Kimchee 就是按这个结构做的：渠道管理器包含在产品里，不另外计费，也没有第二块对应设置页。渠道页面列出了可以接的平台，价格页面上的月费已经把对接算进去了，多人间按 4 张床折算成 1 间房，没有长期绑约。功能不分版本，低档位不会少给你东西，这部分在功能页面写得更细。

我们不是在白板上想出这个结构的。我们自己在釜山运营三家住宿，半夜重新做房型对应的人就是我们。把它做成一套，是不再干那件事的最短路径。

也说句公道话

打包不等于自动更好。一个你已经用顺手的独立渠道管理器，接上一个你已经习惯的 PMS，是完全成立的配置；如果你的渠道清单短而且稳定，这条缝几乎不花你什么钱。打包真正划算的时候，是你的库存经常变、你同时卖多人间和独立房间、或者你还在往上加渠道的时候。

拿你自己的渠道清单算一遍每间房每月的总成本，比看任何功能对比表都管用。算完有疑问，常见问题里有我们被问得比较多的几条。