上门维修公司数字化，第 5 章：让反馈变成生命线——服务→反馈→优化→再发现的闭环
服务完成后请客户反馈，反馈绑定到具体师傅，公司据此优化服务，满意的客户下次通过 PWA 快速再找到公司。这一章讲清楚闭环怎么落地，以及师傅如何看待『反馈会关联到自己』。
这一整条系列，跟着一家春武里的上门维修公司一步步走进数字化。故事的情境来自我们在维修服务行业的真实实施经验——你要是经营靠老客户重复叫修的小型服务公司，每一章应该都会看到自己师傅车上的影子。每章都会说明：盖了什么、刻意没盖什么，以及是靠哪些证据才敢接着往下走。
一次维修的终点，是下一次服务的起点
对上门维修公司来说，一次服务结束，通常意味着：师傅收钱走人，公司失去联系，直到客户下次家里再出问题。这中间的空白期，客户是“失联”的。
PWA 改变的不只是“入口”，而是让公司在这段空白期里留在客户生活里。方法就是一个字：问。
闭环的四步：服务→反馈→优化→再发现
第一步：服务。 师傅上门完成维修，这是公司最熟悉的一环。唯一的变化：结束前，告诉客户“回去后在手机上点一下桌面图标，就能给我们反馈，下次再有问题也直接从那找我”。
第二步：反馈。 服务完成后，公司通过 PWA 发一则通知，请客户评价这次服务：师傅是否准时、问题是否解决、报价是否清楚、下次还会不会找我们。反馈绑定到具体师傅——因为只有知道“这个好评是哪位师傅挣的、这个投诉是谁惹的”，反馈才有改进价值。
第三步：优化。 老板每周看反馈。不是看评分开心或难过，而是看模式：某个师傅总被投诉“报价后加价”，某个活总被说“没有彻底解决”，空调旺季的预约总是排不进去。反馈数据告诉公司该改什么——这是以前靠印象永远看不出来的。
第四步：再发现。 客户被服务好了、收到过反馈邀请、桌面上有公司图标。下次家里出问题，他不再翻聊天记录，而是点开图标直接报修。老客户回流，从“碰运气”变成“走管道”。
闭环转起来之后，公司的增长逻辑变了：不再是“每单都拉新客”，而是“服务好一个，留住一个，让他年年回来”。
师傅怎么看待“反馈会关联到自己”
这是最容易翻车的地方。如果师傅觉得反馈是老板用来扣钱的，他会：一，劝阻客户别反馈；二，把评分好的人抢走、坏的单子丢给别人。闭环会当场死掉。
所以公司提前定了几条规矩：
- 反馈的第一个用途是改进服务，不是考核扣钱。 师傅看到的是“哪类活老被投诉、下次怎么避免”，而不是“你的评分排第几”；
- 反馈用于考核，是后期独立环节。 当数据积累足够、规则清晰、争议处理方式明确之后，才讨论是否把反馈纳入绩效——本期不承诺；
- 师傅也有解释权。 遇到低分，公司先找师傅聊现场情况，而不是直接定罪。师傅愿意配合，是因为他知道反馈是在帮他，不是在整他。
反馈闭环要活下去，靠的不是系统多聪明，而是师傅相信它是帮手而不是枷锁。
这一阶段刻意不是这些
- 不是师傅绩效考核系统。 反馈先用于改进服务，考核是后期独立环节，本期不建评分排名；
- 不是完整 CRM 或会员体系。 不做客户全档案、不做积分、不做自动化营销——PWA 记住了“谁是老客户”就够了；
- 不是派工调度系统。 闭环不解决派谁、去哪，解决的是客户回不回来；
- 不是原生 App。 桌面图标＋通知，PWA 已经覆盖了这个场景。
判断闭环有没有成功的标准
闭环跑过一段时间后，公司看三件事：
- 反馈量有没有形成规模——通知发出去，有多少客户真的回；
- 反馈有没有推动改进——被投诉的模式有没有真的变好，而不是停在“收到反馈”；
- 老客户再发现有没有增加——通过 PWA 再报修的比例，是不是在稳定上升。
第 6 章会回过头，把两期放在一起看：白跑率降了多少、老客户回流怎么变、每一步为什么这样决定，以及这个案例里“不建大型系统、不建 App”的边界是怎么守住的。
边界很重要：本期的 PWA 反馈通知与闭环，是公司的二期独立专案；反馈用于师傅考核属于后期独立环节，本期不建评分系统。派工调度、线上收款、客户账户体系与完整 CRM 均不在本案例范围内，不因出现在案例中而成为标准网站套件的组成部分。