上门维修公司数字化，第 1 章：为什么先做服务范围与报价入口，而不是急着做派工系统或 App

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

公司原本的样子

这是一家位于春武里(Chonburi)的上门维修公司，服务范围集中在省内一个生活圈。7 位师傅分成几个小组，各擅长不同领域：水电维修、空调保养维修、家用电器维修、漏水与防水处理。师傅上门查看、现场报价、维修施工，生意靠同一个生活圈的老客户一单一单攒起来。

老板最清楚三件事在消耗公司：

• 客户的问题太模糊。 客户打电话来多半是“水龙头漏水”“空调不冷”“楼上渗水”。具体是什么原因、要换什么、多少钱，都得师傅跑一趟现场才知道。而有些活根本不用上门——电话或视频先聊两句就能判断，但因为没有标准，师傅常常白跑。
• 公司看不清自己哪类活赚钱。 报价靠师傅现场开口，完工靠纸本和记忆。问老板“上个月水电、空调、漏水各接了几单、哪类最赚、师傅时间都花在哪”，他只能凭感觉。
• 老客户靠客户自己记得。 客户家里下次出问题，找不找得回这家公司，取决于他有没有存下电话号码、LINE 有没有聊天记录。公司没有系统化的“老客户入口”，而区域市场的客户池就那么大——老客户重复叫修是生命线。

但老板也知道，自己现在最缺的不是派工系统，也不是 App。而是：让客户在问题发生、不知道怎么描述时，能用一个简单入口先把情况说清楚、留下联系方式；同时让公司第一次看清自己到底在做什么生意。

第一阶段真正盖了什么

第一期网站只做四件事：

1. 服务范围页 —— 公司做哪些活：水电、空调、家电、漏水防水，各自怎么计费、什么情况算大修。把师傅和行政在电话里反复解释的内容，变成一份写一次就长期有效的参考。
2. 报价逻辑页 —— 说明为什么上门维修需要现场看才能报价，什么情况可以先电话判断，减少客户“怎么还要跑一趟”的疑问。
3. 报价请求入口 —— 一个简单的表单：什么问题、大概什么时候方便、家里地址在哪、怎么联系。客户描述得越清楚，师傅上门越有准备，白跑越少。
4. 联系方式页 —— 电话和 LINE 放在最显眼的地方，每一页都指向同一个动作：描述问题、留联系方式、等报价。

网站的工作是把模糊的问题变成可追踪的线索，而不是取代师傅怎么上门干活。第一期没有派工系统——接单、派活、上门、报价、施工，全部照旧。

这一阶段刻意不是这些

这是大多数上门服务公司老板第一次做项目最容易想错的地方，值得单独列一遍。第一阶段没有：

• 没有派工调度系统。 没有行程看板、没有自动派单、没有师傅位置追踪。7 个师傅的活，靠行政协调和师傅之间的默契还转得动，不值得为它上一套系统。
• 没有原生 App。 没有上架、没有下载、没有账号体系。老客户入口是二期用 PWA 才讨论的事——它比 App 便宜得多，却够用。
• 没有客户管理系统（CRM）。 不建客户档案、不做会员、不做自动化营销。
• 没有在线付款。 报价、完工、收费继续用现有方式：现金、转帐或当面收。

“先没有”不是目标缩水，不是声称公司不需要派工、不需要老客户工具——而是让这一期小到做得完、让师傅只改变一点点、让下一步用真实资料而不是猜测来决定。

进入第二阶段需要什么

公司本来就有更长的路线图：看清业务构成、降低白跑、把老客户变成可重复回流的资产。在批准下一段建设之前，它同意先观察两件事：

• 有了统一报价请求入口之后，客户描述的问题是不是更清楚、白跑是不是真的变少；
• 这些请求能不能被统一记录，让老板第一次看清哪类活值得上门、哪类在亏损。

第 2 章要谈的，就是第一期怎么落地：报价请求表单加电话／LINE 引导，以及怎么把报价请求变成一条能追踪的记录。

---

边界很重要：服务范围与报价信息网站、报价请求表单、电话／LINE 引导，是一个正常的网站专案。本系列中的 PWA 老客户入口、派工调度、线上收款、客户账户与 CRM，都是各有范围的独立系统专案——它们不属于标准网站套件，二期讨论的 PWA 尤其如此。