外省酒店数字化，第 3 章：让前台承接电话／LINE 预订并留下记录

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

流量进来了，但前台还是一团雾

地图和网站把直接询价导进来了。客人看完房型页，打电话或加 LINE 问“X 号房这周三有没有”。前台照常接单——但接完之后，这笔订单落在哪里？

• 写在纸本上；
• 记在 LINE 聊天记录里；
• 或者更常见：记在记忆里。

于是出现了熟悉的一幕：老板问“这个月电话和 LINE 到底订了多少间、哪个房型最热、都是哪来的”，前台答不上来，老板也说不清。流量进来了，但数据没留下。 这章要解决的，就是这一件事。

一期真正做了什么：把直接询价变成统一记录

这里没有建后台系统，没有 CRM，没有 PMS——只是建立一份统一的询价记录，前台在接单时顺手填写。每一笔直接询价记四件事：

1. 来源 —— 电话、LINE、还是 Google Maps 点进来之后打来的；
2. 房型 —— 问的是哪种房；
3. 日期 —— 想住哪几天；
4. 结果 —— 订了、还在考虑、没订、取消了。

记录放在前台本来就会用、最容易更新的地方，也许是一份共享表格，也许是订房本。重点不是用什么工具，而是前台接单的时候顺手记一笔，让直接渠道第一次有了可以被看见的数据。

为什么前台愿意做，而不是觉得多一件事

这是最容易失败的地方：如果记录变成“额外的作业”，前台会先应付再放弃。所以设计上坚持三件事：

• 接单时顺手记，不是事后补。 电话还没挂，客人说出口的房型日期就是要记的内容，不需要下班后再回忆。
• 只记推动判断的信息。 不要求前台整理客户的个人信息、不要求写长篇备注，四栏够用。记录是为了让老板看得清方向，不是为了做漂亮的报表。
• 老板自己带头看。 每周翻一遍记录，用数字回问前台“这周哪来的订单多”，前台才会知道这笔账真的有人看，不是填了就丢。

如果前台觉得这纯粹是给老板看的作业，它活不过两周。只有当老板真的根据记录做决定，记录才会成为流程的一部分。

顺便处理掉最常见的例外

外省酒店的订单，比 Booking 后台里的还要糙一些。前台在记录里也把这些例外一并处理：

• 当天入住。 客人傍晚才订当晚，人工确认当场就能接，不需要系统规则；
• 过路客。 只住一晚、停车睡一觉就走，问到哪个房型有就订哪个；
• 取消与改期。 没有在线取消按钮，前台口头确认就好，记录里把结果更新成“取消”；
• 押金。 该收的押金继续照旧收，记录里标一笔。

这些例外不是“没被系统处理的瑕疵”，而是这个阶段人工流程仍然可靠的证据——它们同时也告诉你，将来若做在线预订，规则必须把这些情况都定义清楚。

这一阶段刻意不是这些

• 没有前台管理系统（PMS）。 没有房态看板、没有渠道日历、没有入住统计报表——一间二十几间房的酒店还不需要为它养一套系统；
• 没有 CRM。 不维护客户档案、不做会员、不做自动化营销；
• 没有在线预订。 记录是给老板看方向的，不是给客人在线用的；
• 没有和 Agoda 打通。 直接渠道和 OTA 各自记录，本期不整合。

进入下一阶段需要什么

记录跑过一段之后，酒店终于第一次能回答这些问题：

• 电话／LINE 直接订了多少间，占全部订单几成；
• 哪个房型最热门、哪几天最难订；
• 询价来自地图、电话还是 LINE，来源是不是真的在变多；
• 取消和改期主要集中在哪些情况。

这些数字，就是第 4 章要讲的——用一期的数据判断，值不值得进入二期。

---

边界很重要：前台询价记录用的共享表格或订房本，是酒店自己维护的简单资料工具。本系列中的自建在线预订、PMS、CRM、在线订金收款与渠道整合，都是各有范围的独立系统专案——它们不属于标准网站套件。