外省酒店数字化，第 2 章：一期落地——Google Maps＋房型展示＋电话／LINE 预订引导

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

外省客人的路径，从地图开始

外省游客决定住哪里，和城市里的预订方式不太一样。他可能刚开车到省里，或者正在路上规划行程，先在 Google Maps 上搜“这个省住宿”“这个市酒店”。地图上跳出几家，他点进去看位置、照片、有没有停车、评论多少——决定住哪，很大程度从地图开始。

所以第一期第一件事，不是急着做在线预订，而是把这张地图上的入口做好。

一期真正做了三件事

第一件：完善 Google Maps 上的酒店信息，并关联网站。 酒店原本在地图上只有一条简陋记录：名字、大概位置。这期把它补成客人做决定需要的样子——完整地址、房型与设施照片、营业信息、联系方式，以及最重要的：链接到酒店自己的网站。这样搜索的人点进去，看到的是酒店自己写的房型页，而不是靠猜。

第二件：网站把每个房型做成一页。 每间房什么样、住几人、有什么设施、价格区间怎么算，一次写清楚。照片是真实拍的，不是官网素材图。游客在地图上点进来看完，心里已经有底：这家有什么房、住起来大概什么样。

第三件：每一页都指向同一个动作——电话或 LINE。 房间页、设施页、政策页，结尾都是大大的电话按钮和 LINE 按钮。网站的工作不是让客人在线下单，而是把咨询准备好、把客人送到前台接得住的地方。前台接到电话，客人已经看过房型，问答从“你们有什么房”直接跳到“X 号房这天有没有”。

为什么这个阶段用人工确认，而不是在线预订引擎

这是外省酒店业主最容易反复纠结的问题。答案是：这个阶段，人工确认更好。

• 成本更低。 在线预订引擎要维护实时房态、价格规则、收款与取消处理，一套下去都是成本。一间二十几间房、价格天天变的小酒店，第一版就用它，是拿利润去养系统。
• 更灵活。 过路客可能晚上十点才到、想加床、想临时改期，人工确认都能当场处理。在线引擎要先定义好规则，反而卡住这些真实生意。
• 例外更好处理。 当天入住、取消、押金、no-show，人工确认靠前台判断，不会因为系统规则僵化而流失客人。
• 直接渠道要先有，才谈得上降低 OTA 依赖。 在线预订引擎是承接直接渠道的工具，不是创造直接渠道的工具。渠道是网站、地图、电话、LINE 和前台一起建起来的。

这不代表以后永远人工确认。 它代表：先让直接渠道跑起来、留下数据，再让数据决定什么时候值得把它自动化。

这一阶段刻意不是这些

• 没有在线预订引擎——理由上面已经说清楚，这是二期由数据决定的事；
• 没有和 Agoda 整合——渠道整合（Channel Manager）是大系统，本期碰都不碰；
• 没有在线收款——订金和房费继续走现有转帐与前台收款；
• 没有客户账户——没有会员后台、没有在线回访入口。

进入下一阶段需要什么

酒店同意，第一期跑过一段时间后，要看一件事是不是成立：电话和 LINE 的询价是不是真的变多、来源能不能追踪。 如果地图和网站只是把流量导进来，但前台记不住谁打过、谁订了、哪个房型最热门，那这些流量就还是一团雾——下一步，就是把这些直接询价变成统一的记录。

第 3 章要谈的，就是前台怎么在不增加负担的情况下，把电话／LINE 预订接住并留下痕迹。

---

边界很重要：Google Maps 收录、房型展示网站与电话／LINE 预订引导，是一个正常的网站专案。本系列中的自建在线预订、在线订金收款、Channel Manager 与渠道整合，都是各有范围的独立系统专案——它们不属于标准网站套件，二期讨论的自建预订尤其如此。