维修报价变更确认留痕：追加项目别只停在口头

这个案例来自 汽车服务 场景。企业背景我只保留最少的信息，重点放在一个售后门店最容易从“小沟通”变成“大争议”的现场上：
车辆拆检后发现追加维修项目，顾问口头讲过、客户电话里点过头、车间也继续施工了，但结算时客户又觉得报价变了、范围变了、当时没有说清。

这个场景到底发生在什么现场

这是一个维修过程中追加项目、追加工时、追加配件和报价变更并存的售后服务场景。
一辆车进店时，最初工单往往只是根据客户描述和初检结果先开出来。

真正开修以后，现场常常会继续出现这些情况：

拆开后发现隐藏损伤
常规保养外又查出安全风险项
旧件拆卸后发现关联件也需要更换
原报价里没有包含某个辅料或工时
客户临时加做美容、清洗或精品加装

参与这条流程的人一般有这些：

服务顾问：负责向客户解释追加原因、费用和交车影响
车间技师：负责发现新增项目并说明技术依据
配件人员：负责核实配件库存、价格和到货时间
售后主管：负责复核争议项目和异常折扣
客户：关心钱花在哪、是否真的同意过、会不会被临时加价

这个现场最真实的难点不是不能追加项目，而是追加项目一旦只靠电话、口头和群消息确认，后面就很难证明“当时确认的到底是哪一版报价”。

原来的处理链条为什么会卡

改造前，追加维修报价多靠技师口头说明、顾问电话沟通、客户口头答复、再由顾问把结果补到工单里。

典型流程通常是：技师发现新增项目，顾问去车间听原因，再打电话或发消息给客户，客户口头同意后车间继续施工，结算时再按最新报价收费。

旧流程最常见的卡点有这些：

1. 追加原因没有形成统一说明

技师讲的是技术语言，顾问讲的是服务语言，客户听到的又是费用变化。

2. 报价版本容易混在一起

初始报价、拆检后报价、减免后报价、客户最终确认报价如果没有分版，后面很难回看。

3. 客户确认只停在口头里

电话里同意了哪几项、有没有同意工时、有没有同意交车改期，系统里未必能看清。

4. 车间开工和客户确认之间有时间差

客户刚说“先看看”，车间可能理解成“可以做”，这类误差最容易引发结算争议。

5. 异常折扣和赠送承诺容易另走一条线

为了安抚客户，顾问可能补一句“这项少收一点”或“顺手做个检查”，后面又没有进入报价主线。

改造前的旧流程简图

flowchart TB
    A[车间发现新增维修项目] --> B[技师口头说明追加原因]
    B --> C[顾问电话或消息联系客户]
    C --> D[客户口头表达同意或犹豫]
    D --> E[顾问手工备注报价变化]
    E --> F[车间继续施工]
    F --> G[结算时客户重新核对费用]
    G --> H[确认依据不清导致争议]

这条旧流程为什么总在结算前后最容易翻车

从项目复盘角度看，旧流程真正的问题不是门店故意漏说，而是“新增项目、报价版本、客户确认、施工放行、最终结算”没有形成同一条可追溯链。

1. 新增项目被当成沟通事项，而不是变更事项

一旦只是电话里讲一讲，追加项目就很容易脱离工单、报价和施工节点。

2. 版本变化没有被显性拉出来

客户看到的是总金额变化，门店心里想的是多了哪些项目。两边关注点不一致，争议就会变多。

3. 顾问记了备注，但备注不是确认凭证

一句“客户已同意”无法说明客户同意的项目、金额、工时、交车时间和减免条件。

4. 施工继续推进后，补确认的空间很小

项目已经做完再补签，客户会觉得被动，门店也很难解释过程。

5. 最后争议常常落到一线顾问身上

技师、配件、主管都参与过，但过程没串起来时，客户只会抓住最后收费的顾问。

派宝怎么把多智能体放进去

派宝做的不是替门店决定要不要维修，也不是替客户作出最终选择，而是把“发现新增项目、整理报价差异、发出确认、盯住承诺、留好过程、满足关闭条件”这条变更链跑顺。

1. 先把新增项目从聊天里拎成变更对象

车间发现新增项目后，派宝会把项目名称、技术原因、关联旧件、建议处理方式、是否影响安全和是否影响交车时间先整理成一条结构化变更记录。

这样它不再只是群里一句“建议加做”，而是可以继续被报价、通知、确认和留痕接住的业务对象。

2. 再用版本差异比对拉清新旧报价变化

系统会把初始报价和追加后报价放在一起看，区分新增项目、删除项目、金额变动、工时变化、配件替换、折扣或赠送调整。

客户和门店看到的重点不再只是“总价多了多少”，而是“为什么多、具体多在哪里、哪些项目不变”。

3. 再把客户确认变成带版本的动作

顾问发给客户的确认内容会带上报价版本、项目明细、总金额、预计交车影响和确认时点。

客户确认后，系统把确认结果挂回同一张工单，而不是只留在电话记录或聊天截图里。

4. 再用企业微信通知同步内部岗位

当客户已确认、部分确认、拒绝追加或要求改方案时，企业微信通知会把结果同步给顾问、车间、配件和主管。

这一步重点不是多发消息，而是让车间明确知道当前能施工的是哪一版项目。

5. 再用任务提醒盯住未确认和临期项目

如果客户还没确认、配件报价还没回、主管折扣还没批，系统会按节点提醒对应岗位。

这样追加维修不会停在“等客户回复”或“等主管看一下”的模糊状态里。

6. 再用承诺兑现跟踪挂住减免、交车和补偿

如果顾问承诺了交车时间、费用减免、免费检查或后续回访，这些承诺会跟着变更记录走。

后面不是靠顾问记忆，而是由系统持续判断承诺有没有兑现。

7. 最后用关闭条件校验防止报价变更早关

追加项目要正式进入结算前，系统会检查客户确认、施工放行、报价版本、折扣口径和关键留痕是否齐全。

缺少任何关键条件，就不建议把变更事项直接关掉。

改造后的新流程详细图

flowchart TB
    A[车间发现新增维修项目] --> B[形成结构化变更记录<br/>项目 原因 金额 工时 交车影响]
    B --> C[版本差异比对能力<br/>比对初始报价和追加报价]
    C --> D[顾问向客户发送带版本的确认内容]
    D --> E{客户是否确认}
    E -- 已确认 --> F[企业微信通知能力<br/>同步顾问 车间 配件和主管]
    E -- 未确认 --> G[任务提醒能力<br/>持续提醒责任人跟进]
    G --> D
    F --> H[车间按已确认版本施工]
    H --> I[承诺兑现跟踪能力<br/>跟踪交车 减免 回访等承诺]
    I --> J[操作留痕追踪能力<br/>记录每次报价变更和确认动作]
    J --> K[关闭条件校验能力<br/>校验确认 留痕 结算条件是否齐全]
    K --> L[结算争议更少]

上线前后到底差在哪

为了让这篇案例更像真实项目复盘，这里按一个典型 4S 店售后维修场景来说明：
以 日均维修工单 90 到 130 张、其中约 18% 会出现拆检后追加项目 的业务环境为例，连续运行 8 周后，企业最明显的感受不是追加项目变少了，而是追加项目终于从“口头说过”变成“过程可追、版本可看、结算可解释”。

上线前后对比表

对比项	改造前	改造后
追加报价确认方式	电话和口头为主	带版本确认并挂回工单
报价变化解释效率	依赖顾问临场说明	差异明细直接可看
客户结算争议	较容易发生	明显下降
车间施工放行依据	靠顾问口头转达	按已确认版本施工
减免和赠送承诺	容易散落在聊天里	跟随变更记录持续跟踪
工单关闭依据	备注较多、凭证较散	关闭条件更清楚
争议复盘时间	较长	缩短约 58%

为什么这些变化站得住

第一，变更对象更清楚，因为新增项目不再只是顾问和技师之间的一段沟通，而是进入了工单变更链。

第二，报价差异更可解释，客户看到的不只是总价变化，而是每一项新增、调整和减免。

第三，施工放行更稳，车间按已确认版本执行，避免把客户犹豫理解成客户同意。

第四，承诺不再掉地上，交车时间、折扣、赠送检查和后续回访都能跟着变更事项继续走。

第五，关闭更有门槛，确认、留痕、施工和结算条件不齐时，系统会把风险先拦住。

这个案例的价值

这套做法在汽车售后里站得住，不是因为它让门店不再需要沟通，而是因为它抓住了一个真实问题：
维修报价变更最容易出事的地方，从来不是“多修了一个项目”本身，而是客户后来无法确认当时到底同意了什么。

1. 它没有替技师做专业判断

新增项目是否真的需要做，仍然由技师和门店按专业标准判断。
派宝补的是变更解释、报价版本、客户确认和过程留痕。

2. 它没有替客户做消费决定

客户可以同意、拒绝、部分同意，也可以要求先给替代方案。
系统要做的是把这个选择完整、清楚、可回看的方式沉淀下来。

3. 它把“口头确认”变成“带版本确认”

这一步对维修售后特别关键。
因为争议发生时，最需要回看的不是一句“客户同意了”，而是哪一版、哪些项目、多少钱、什么条件下同意。

4. 它特别适合追加项目多、客单价高的门店

钣喷、事故维修、疑难故障、精品加装和大保养场景里，报价变化更频繁。
变化越多，版本和留痕越重要。

5. 它让结算解释更像复盘，不像争辩

顾问不必靠回忆还原过程，而是可以顺着时间线说明：
最初报价是什么，拆检后新增了什么，客户确认了哪一版，门店兑现了哪些承诺。