外省酒店数字化，第 5 章：二期——自建最小预订，加上 checkout 的回流卡片

这一整条系列，跟着一家泰国外省酒店一步步走进数字化。故事的情境来自我们在酒店行业的真实实施经验——你要是经营外省的小型住宿，每一章应该都会看到自己前台的影子。每章都会说明：盖了什么、刻意没盖什么，以及是靠哪些证据才敢接着往下走。

二期做了什么：把一件事自动化，而不是把前台搬上系统

二期不是“我们终于要上酒店系统了”。它只是做了一个决定：把数据里最值得自动化的那一小段，从人工确认转成在线下单。

一期的记录显示：热门房型、规则简单、取消规律清晰的预订，最适合在线化；而那些过路客、加床、深夜改期的单子，人工确认仍然更好。于是二期只做了四件事：

1. 挑几个热门房型上线在线预订。 家庭房和标准房优先，复杂房型继续电话／LINE 人工确认；
2. 只做可用性与订金。 客人选日期、看到某房型有没有空、下订金占位。不接信用卡全款，不收复杂的动态定价——先把“夜里打来没人接”的漏补上；
3. 规则由一期的例外倒推。 取消、改期、当天入住这些规则，直接照着一期记录里最常见的例外来定义，而不是凭空设计；
4. 在线预订接进一期建的网站。 同一个房型页，多了“在线预订”按钮，电话和 LINE 按钮保留。客人可以选，不是被逼着走某一条路。

为什么只做“最小”，而不是完整在线预订

• 完整在线预订＝实时房态＋动态价格＋全渠道同步， 每一层都是成本与维护。一间二十几间房的小酒店，为这几个热门房型养这套东西，利润会被吃掉；
• “补漏”而不是“重造”。 在线预订要接住的是人工确认漏掉的深夜单、犹豫单，而不是取代前台——前台仍然接电话、处理例外、办入住；
• 规模决定复杂度。 今天只有三成订单走直接渠道，就为三成订单建一套全功能引擎，是把以后可能的需要，当作今天必须花的钱。

checkout 时送出的那张卡片

二期的另一半，不是在线预订，而是回流。它解决的问题是：从 Agoda 来的客人，下一次订房很可能又打开 Agoda，酒店白白再付一次分成。

所以酒店做了一件便宜的事：checkout 时，和房卡一起递一张卡片。

卡片内容很简单——酒店自己的预订方式：网址、一个专属优惠（比如下次直接预订享房费折扣）、和一句话：“直接从我们这订，没有平台抽成，我们把这笔省下来的钱回馈给你。”

这一步看起来平凡，但它把 OTA 客人最后一次面对面接触变成了自有渠道的起点。客人下次来，记住的不再只是“我在 Agoda 上订过这家”，而是“这家让我下次直接订更便宜”。

这一阶段刻意不是这些

• 不是完整酒店系统。 没有 PMS、没有房态看板、没有渠道日历、没有前台报表；
• 不是 Channel Manager。 自建预订和 Agoda 是两条独立的渠道路，不自动同步房态、不互相对账——先站稳直接渠道，再谈整合；
• 不是会员系统。 回流卡片靠的是“直接订更便宜”的简单承诺，不是积分、等级、后台登录；
• 不是全房型上线。 复杂房型、连住、包月订单，继续走人工确认。

判断二期有没有成功的标准

二期跑过一段时间后，酒店看三件事：

• 在线预订接住了之前漏掉的单吗？ 深夜和忙时段的直接订单有没有变多；
• 回流真的发生吗？ 有没有客人再订时，是拿着卡片直接打电话或上网站，而不是打开 Agoda；
• 前台负担变重了吗？ 如果在线订单反而制造了更多电话确认、对账或补录，那自动化就失败了——数据比感觉诚实。

第 6 章会回过头，把两期放在一起看：OTA 依赖降了多少、每一步为什么这样决定、以及这个案例里“不建大型系统”的边界是怎么守住的。

---

边界很重要：本期的自建在线预订（可用性＋订金）是酒店的独立系统专案，属于二期范围，不属于标准网站套件；它也不与 Agoda 等 OTA 做渠道整合。线上收款、PMS、Channel Manager 仍属独立系统，不因出现在本案例中而成为标准网站套件的组成部分。