上门维修公司数字化，第 6 章：回顾两期——区域生意的生命线，是老客户而不是新系统

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

两期下来，公司变成了什么样

把两期放在一起看，这家上门维修公司的变化是清晰的：

• 业务从“凭感觉”变成“看得见”。 哪类活赚钱、白跑率多高、师傅工时怎么分布、老客户占几成——老板第一次能用数字回答自己的生意；
• 白跑在变少。 客户学会先描述问题，师傅出发前更有准备，电话里能判断的活不再白跑一趟；
• 老客户从“碰运气”变成“走管道”。 客户桌面上有公司图标，下次家里出问题直接点开报修；服务完成后收到反馈邀请，公司留在客户生活里；
• 闭环转起来了。 服务→反馈→优化→再发现，反馈数据真的在改公司的服务方式，而不是停在“收到了”；
• 没有大型系统，没有 App。 没有派工调度(FSM)、没有 CRM、没有原生 App。最重的投资，是二期那个用网页技术做的 PWA 入口。

每一步为什么这样决定：证据链

这个案例真正想讲的，不是“报价表单＋PWA”这个答案，而是这一连串决定是怎么做出的：

1. 先建报价入口，因为问题在“描述不清”。 客户的问题模糊，公司看不清自己做什么生意。所以一期先让描述落地：服务范围、报价逻辑、报价请求表单，让模糊问题变成可追踪的线索；
2. 记录先落地，才谈投资方向。 统一报价记录让老板第一次看清业务构成与老客户占比。没有这一步，二期投给谁都是拍脑袋；
3. 投资老客户，而不是派工系统。 数据说老客户占比够高、流失不可逆，而派工系统在 7 个师傅的规模上边际收益不大——于是钱投给了生命线；
4. 用 PWA 而不是 App。 上架、审核、双平台维护对区域型小公司是过重成本；PWA 不用上架、一套代码全平台，却完整覆盖“快速再次找到公司”；
5. 反馈让入口变成闭环。 单纯入口只能让客户“找得到你”，反馈通知让公司“留在客户生活里”，服务→反馈→优化→再发现 才能真正转起来。

每一步的下一步，都不是由“系统能做到什么”决定，而是由“数据告诉我们什么值得做”决定。数据不够，就回到人工流程安全运行，不急着升级。

区域生意的生命线，不是新系统

很多上门服务老板想到“数字化”，第一反应是上派工系统或做 App。这家公司的故事告诉我们不是这样：

• 客户池有限，留住比拉新更重要。 区域市场的每一个老客户都很难补回来，所以生命线是老客户回流，不是一套更贵的系统；
• 入口不等于 App。 客户需要的是“下次找得到你”，一个加到桌面的 PWA 图标就够了——复杂度再高的东西，不会让客户多回来一次；
• 反馈不是考核，是改进的燃料。 反馈绑定师傅、推动优化、让客户看到自己在被重视，闭环才活得下去；
• 避免大型系统，不是省钱，是避险。 7 个师傅的规模养不起一套 FSM，养了也只是让行政更忙、师傅更烦。只建支撑当前业务的最小闭环，等真实规模证明需要，再长大。

这个案例可迁移的判断

• 如果你在纠结要不要做 App，先问：客户需要的是“下载一个 App”，还是“下次找得到你”？ 后者常常便宜得多；
• 如果你在纠结要不要上派工系统，先问：你的业务规模，真的复杂到人协调不过来了吗？ 数据先于系统；
• 如果你担心反馈变成师傅的敌人，先问：反馈的第一个用途，是帮师傅还是盯师傅？ 帮手才活得下去。

边界，最后再强调一次

两期真正的投资——服务范围网站、报价请求表单、统一报价记录、PWA 老客户入口——前几项属于正常网站与简单资料工具范围，PWA 是二期独立项目，不属于标准网站套件。派工调度(FSM)、原生 App、线上收款、客户账户与完整 CRM，全程没有进入本案例——它们各有自己的边界，不因出现在教育案例中而变成网站套件的一部分。

---

边界很重要：本系列两期的建设范围——服务范围与报价信息网站、报价请求表单、统一报价记录、PWA 老客户入口——都属于正常网站专案、简单资料工具与二期独立项目。派工调度(FSM)、原生 App、线上收款、客户账户与完整 CRM 均不在本案例范围内，不因出现在案例中而成为标准网站套件的组成部分。