上门维修公司数字化，第 4 章：二期——用 PWA 建立老客户入口，而不是做原生 App

这一整条系列，跟着一家春武里的上门维修公司一步步走进数字化。故事的情境来自我们在维修服务行业的真实实施经验——你要是经营靠老客户重复叫修的小型服务公司，每一章应该都会看到自己师傅车上的影子。每章都会说明：盖了什么、刻意没盖什么，以及是靠哪些证据才敢接着往下走。

老客户的问题，不是“服务不好”，是“找不到你”

一期数据告诉老板一件事：老客户重复叫修占了三成以上，客户是愿意回来的。但客户怎么回来？靠的是：记得公司的电话、LINE 里有聊天记录、或者刚好又搜到公司。

问题就在这里——区域市场的客户池就那么大，每一次“找不到你”，都等于把客户送给街角的另一家。 而客户家里的问题不是一次性的：空调年年要保养、水龙头迟早要换、家里总有下一个要修的东西。谁能被客户“快速再次找到”，谁就拿到了下一单。

老板想要的是一个“老客户入口”。但他第一个念头——做 App——很快被自己否掉了。

为什么是 PWA，而不是原生 App

做 App 的想法很自然：装个 App，客户就天天看得到你。但对一家区域型小公司来说，原生 App 的成本是持续而沉重的：

• 上架与审核。 App Store 和 Google Play 各有审核流程，改一次版就要重新过一遍；
• 双平台维护。 客户有人用 iPhone、有人用 Android，两套都要养；
• 下载门槛。 让客户去商店搜、下载、注册，每一步都在流失客户；
• 长期维护。 一个没人更新、无法适配新系统的 App，会从“入口”变成“坏口碑”。

PWA（Progressive Web App，渐进式网页应用）不同。它本质上是一个网页，但能像 App 一样被“加到桌面”：客户在浏览器里打开一次，点一下“加入主屏幕”，就有了一个图标，下次像打开 App 一样点进去。而它：

• 不用上架、不用审核，改了即时生效；
• 一套代码跑所有平台，iPhone、Android、桌面都能用；
• 成本远低于 App，对区域型小公司是现实的选择；
• 却完整覆盖了核心场景——客户快速再次找到公司。

对于上门维修的生意，PWA 不是 App 的廉价替代，而是恰到好处的答案。

老客户入口怎么建起来

二期 PWA 只做三件事：

1. 加入主屏幕。 服务完成后，师傅或行政引导客户打开公司页面、点一下“加入主屏幕”。客户下次再需要，桌面图标一点就进——不搜、不翻聊天记录、不用想公司叫什么。
2. 一个简单的再次报修入口。 PWA 里就是一期那个报价请求表单，客户直接描述新问题、留时间。老客户不需要学习新东西，界面和他已经用过的网站一模一样。
3. 一个“我是老客户”的信号。 PWA 记得客户是谁，下次描述问题可以少填几栏——客户觉得贴心，公司也知道是熟客来了。

服务完成通知：闭环的起点

PWA 的另一个能力，是通知。这比单纯“入口”更进一步：服务完成后，公司用 PWA 发一则通知给客户，请他对这次服务反馈——师傅是否准时、问题是否解决、报价是否合理。

这一步把“被动等客户回来”变成“主动留在客户生活里”：维修结束不是终点，而是下一次服务关系的开始。反馈怎么变成闭环，是第 5 章的完整内容。

这一阶段刻意不是这些

• 不是原生 App。 理由上面已经说清楚，PWA 是成本与体验之间的正确选择；
• 不是派工调度系统。 PWA 面向客户，不面向师傅排程；
• 不是完整客户账户体系。 不做会员积分、不做等级、不做登录密码体系——“记得你是老客户”就够了，不把客户拖进复杂账号；
• 不解决新客户获客。 新客还是靠网站、地图、LINE 和口碑，PWA 是给已经服务过的老客户的再发现入口。

判断 PWA 有没有成功的标准

PWA 跑过一段时间后，公司看三件事：

• 有没有老客户通过 PWA 再次报修——这是入口有没有被用起来的最直接证据；
• 服务完成通知有没有人打开、反馈——闭环有没有真的转起来；
• 师傅与行政愿不愿意顺手引导客户加主屏幕——如果这变成尴尬的推销，入口就断了。

第 5 章要谈的，就是反馈怎么变成生命线：服务→反馈→优化→再发现 的闭环，以及师傅怎么看待“反馈会关联到自己”。

---

边界很重要：本期的 PWA 老客户入口与服务完成通知，是公司的二期独立专案，属于独立范围，不属于标准网站套件；它面向老客户，不替代新客户获客。派工调度、线上收款、客户账户体系与 CRM 仍属独立系统，不因出现在本案例中而成为标准网站套件的组成部分。