上门维修公司数字化，第 2 章：一期落地——报价请求表单＋电话／LINE 引导，建立统一报价记录

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

上门维修的报价，为什么不能跳过现场

先回答一个绕不开的问题：为什么不能像很多服务一样，客户在线下单、直接付款？

因为上门维修的问题，在询价时是模糊的。“水龙头漏水”可能是垫片老化，可能是水压问题，可能是管路裂了——报价要等师傅到现场看才知道。这不是流程落后，而是这类生意的本质：问题要现场判断，报价要人工确认。

但“必须现场判断”不等于“每一趟都白跑”。很多活，电话或视频里先聊两句就能筛掉：客户描述得够清楚，师傅就能判断要不要上门、该带什么零件、大概什么价位。而要做到这一步，公司得先让客户按对的方式描述问题。

一期真正做了什么：让描述先落地

第一期网站做了三件让“描述”落地的事：

1. 报价请求表单。 不是让客户下单，而是让客户回答几个固定问题：什么问题、什么类型（水电／空调／家电／漏水）、大概什么时候方便、地址在哪、怎么联系。客户描述得越完整，行政越好登记，师傅上门越有准备。
2. 服务范围与报价逻辑页。 写清楚公司做哪些活、怎么计费、什么情况要现场看。客户看完，问的问题会更准，行政少回答一遍。
3. 电话／LINE 引导。 页面每一处都提示：先描述问题，再等人工报价。不是让客户自助下单，而是把咨询的起点从“我家有问题”推进到“我家是什么问题、大概什么时候方便”。

同时，行政把每一笔报价请求记进统一的报价记录——这是本章真正的主角。每笔记四件事：

1. 来源 —— 网站表单、电话还是 LINE；
2. 问题类型 —— 水电、空调、家电还是漏水；
3. 报价结果 —— 报价多少、客户接受、放弃还是取消；
4. 师傅与工时 —— 谁去看了、花了几趟。

记录放在行政本来就会用的地方，也许是一份共享表格。重点是接单时顺手记一笔，让公司第一次有数据可看。

为什么师傅与行政愿意配合

上门服务公司最容易败的地方，就是让师傅觉得系统是“老板用来盯人的”。所以设计上坚持三件事：

• 记录对师傅有用，不只是对老板有用。 报价记录里的问题类型和工时，是师傅判断“该带什么零件”的参考——记得越准，下次越省事；
• 只记推动判断的信息。 不要求师傅写长篇报告，四栏够用。记录是为了看清方向，不是为了做漂亮的报表；
• 老板自己带头看。 每周翻一遍，用数字回问行政“这周哪类活最多、白跑了几趟”，大家才知道这笔账真的有人看，不是填了就丢。

师傅的活本身没有变——还是上门、看现场、报价、施工。变的只是出发前更有准备、回来后留下一行记录。

这一阶段刻意不是这些

• 没有派工调度系统。 没有行程看板、没有自动派单、没有位置追踪——7 个师傅的活还不值得为它上一套系统；
• 没有原生 App。 没有上架、下载、账号——老客户入口是二期 PWA 才讨论的事；
• 没有在线报价后直接收款。 报价确认、施工、收费继续用现有方式；
• 没有和任何平台打通。 不接派单平台，不做渠道整合。

进入下一阶段需要什么

报价记录跑过一段时间之后，公司终于第一次能回答这些问题：

• 哪类问题最多、哪类最赚、哪类在亏损；
• 白跑率多高，哪些活其实电话里就能判断；
• 老客户重复叫修占比多少，客户都是怎么找回来的；
• 师傅的工时都花在哪里，哪几个活可以合并安排。

这些数字，就是第 3 章要讲的——用一期的数据判断，值不值得投资老客户入口。

---

边界很重要：报价请求记录用的共享表格，是公司自己维护的简单资料工具。本系列中的 PWA 老客户入口、派工调度、线上收款、客户账户与 CRM，都是各有范围的独立系统专案——它们不属于标准网站套件。