← 全部文章 实操指南

换PMS不丢订单:民宿青旅系统迁移步骤与OTA映射

发布 2026-10-06 · 7 分钟阅读

民宿、青旅想换PMS又怕订单丢失、超售?按这个顺序迁移:先搬什么、新旧系统怎么并行、最容易被低估的OTA房型映射怎么做。

旅客们在民宿公共休息区里开心相聚的场景
© Kimchee

先说结论

换PMS不丢订单,靠三件事:先把未来订单完整搬进新系统,再做OTA房型映射,最后才让新系统往平台推送库存。顺序反了,最常见的后果就是超售:新系统里还是空房,却把“全部可售”推给了各个平台。

并行运行也有边界:新旧系统可以同时存在,但同一时刻只能有一个系统在控制各平台的库存。下面按操作顺序讲清楚。

第0步:切换前先把家底盘清楚

先别急着选日期,先导出旧系统里所有未来入住的订单,整理成一张表。至少包含这些列:

  • 订单来源渠道和平台订单号
  • 入住、退房日期
  • 房型或床位(青旅要具体到哪张床)
  • 房价,以及已付款、未付款、押金的状态
  • 客人备注(晚到、加床、接送、特殊要求)

历史订单不必导入新系统,导出一份存档即可。迁移的目标是“未来会发生的事”,不是“过去发生过的事”。

切换日期也要挑。避开五一、国庆、春节前后和旺季周末,选入住量少的工作日。预订量大的时候出了问题,你没有余量慢慢查。

第1步:先搬结构,再搬订单

摆放着上下铺的青旅多人间,这是迁移到新PMS时最先导入的房型和床位数据
© Kimchee

推荐顺序:

  1. 房型和床位结构:房间数量、房型名称、多人间的床位数。新系统里的结构必须和你在各平台上架的结构对得上。
  2. 未来订单:逐条录入或批量导入,录完以后按日期核对每天的在住和入住数量。
  3. 价格和规则:基础房价、最少入住天数、含早或不含早等价格计划。
  4. 自动消息和模板:最后再配置。

多人间要特别注意换算。我们的计费里是4张床算1间房,但那只是计费口径;日常排房时,床位日历才是你真正要核对的东西。

第2步:并行运行,到底怎么并行

很多人理解的“并行”是新旧系统都连上平台。这样两边同时收单、同时改库存,冲突几乎无法避免。更稳的做法是分阶段:

阶段旧系统新系统
A. 准备正常运营,控制所有渠道录入结构和未来订单,不连平台,不推送
B. 对账继续运营每天把旧系统新增的订单手动补录,并对比两边的房态
C. 切换日断开渠道连接,转为只读存档连接平台,完成映射,核对后开始推送库存
D. 观察期只读备查每天与各平台后台房态逐一对比

阶段B建议持续几天到一两周,看你每天新增多少订单。订单多,手动补录的压力就大,这个阶段就应该压短,并选在订单少的时段。

切换日有一个细节常被忽略:自动消息只能留一个系统发。两边都开着,客人会收到两遍入住指引,甚至两个不同的门禁说明。切换当天先关掉旧系统的所有自动消息。

第3步:OTA重新映射,最容易被低估

映射,是把平台后台的每一个房型、每一个价格计划,对应到新系统里的某一个房型。看起来只是点几下,实际上是整个迁移里最容易出事的环节,原因有几个:

  • 同一个房型在平台上常有多个价格计划:含早、不含早、不可退款、会员价。每个计划都要单独对应。
  • 平台上的房型名称和你内部的叫法往往不一致,比如平台上叫“高级大床房”,你内部叫“301-305”。
  • 多人间的床位在平台上可能被设置成“房型+可售数量”,映射错了,库存会差几倍。
  • 以前为了应付某个平台,可能做过特殊设置,比如把一个房型拆成两个、预留若干间给某个渠道。这些旧设置没人记得,迁移时才暴露出来。

建议这样做:

  1. 先把每个平台的房型和价格计划抄成一张对照表:平台名称、平台房型、价格计划、对应的新系统房型。
  2. 订单全部录入、核对无误之后,再建立映射。
  3. 先拿一个平台、一个房型试点。推送之后,到平台后台确认可售数量与你预期一致,再放开其他房型。
  4. 全部放开后,头几天每天早晚各对比一次平台后台和PMS的房态。

要注意的是,各系统对国内平台的支持范围并不相同。我们的渠道管理器基于Channex,可对接490个以上渠道,明确可以写的有Booking.com、Airbnb、Agoda、Expedia、Hostelworld、Trip.com。你主要用的平台是否在列表里,请先在渠道页面核对,不确定就直接问,不要默认“应该能连”。

切换日当天的清单

夜晚亮着橙色灯笼的民宿入口,各OTA房源都必须正确对应的住宿
© Kimchee
  • 确认当天和未来30天的订单数,两边一致。
  • 先断开旧系统的渠道连接,再连接新系统,避免两边同时写入。
  • 映射完成后,先看平台后台的可售数量,再放开推送。
  • 关闭旧系统的自动消息,检查新系统的消息模板。
  • 当天在住和当天入住的客人,提前确认房间和床位,前台手里留一份纸质或截图的名单。
  • 如果你们有公安住宿登记等必须按时完成的流程,切换期间不要中断。新系统能否衔接,要提前确认,不要假设。

留一条退路

切换前一天,旧系统的数据完整导出备份。观察期内,旧系统不要立刻注销或删除。出现无法解释的差异时,至少还能回头查“当初这条订单是什么样”。如果某个平台映射反复出错,最稳的办法是先把该平台暂时手动关房,修好映射再开,总比超售后给客人安排换房要省事。

我们为什么这样写

Kimchee是我们几个在釜山自己经营住宿的人做的,运营着One Way Guesthouse(约38间房)、KIMCHE Guesthouse Downtown(约45间房)和JMC Residence(15套公寓),所以这份清单是按“前台每天实际要做什么”来想的。当然也要如实说明:我们的管理后台目前只有韩语和英语,游客页面支持韩语、英语、日语和中文。如果你的团队需要中文后台,这一点要在评估时考虑进去。

功能方面,PMS包含床位日历、渠道管理器、自动客人消息、自助入住和房务管理等,详见功能页面;迁移上线的流程可以看使用流程。费用方面,房间制按房间数分档收费(1–10间为每月60美元),各档功能相同,没有长期合约,渠道管理器也不额外收费,具体见价格页面。

如果你正在考虑换系统,可以先把房型、价格计划和平台清单发给我们,我们帮你对一遍映射会遇到什么问题。联系我们。

用经营者自己做的系统

Kimchee 是我们在釜山三家住宿每天都在用的 PMS。渠道管理器已包含在内,不另签合同,也没有按渠道计费。