一、原来的问题不是没有售后，而是售后过程没有证据链
客户最初的售后流程看起来很常见：客户在企业微信或电话里报修，客服手动登记到 Excel，主管根据经验派工程师，工程师到现场后拍几张照片发群里，备件临时向仓库申请，处理完再让客户口头确认。
这套流程最大的风险，是每一步都有人在做，但每一步都缺少系统证据。
- 客户说已经报修，客服说没看到；
- 主管说已经派单，工程师说没有收到完整信息；
- 工程师说设备需要换件，仓库说没有提前申请；
- 客户说服务超时，售后团队拿不出 SLA 过程记录；
- 老板想看服务成本，只能翻聊天记录和费用报销。
表面上是工单效率问题，实际上是服务履约没有被系统化。
二、第一步不是做派单，而是先把客户、设备和服务合同关联起来
很多售后系统一开始就想做派单，但派单之前必须先解决一个更基础的问题：这张工单到底属于哪个客户、哪台设备、哪个服务合同、哪个 SLA 等级。
所以我们先把基础数据拆成四类：
- 客户档案：企业名称、联系人、区域、服务等级、合同状态；
- 设备档案：设备型号、序列号、安装位置、维保周期、历史故障；
- 服务合同：保内保外、响应时限、上门范围、备件规则、收费规则；
- 工程师资源：技能标签、区域、可用时间、当前任务、历史评分。
只有这些数据打通以后，系统才能判断这张工单是普通维修、紧急故障、保内服务、收费服务，还是需要先做远程诊断。
三、客户 App 端要让报修变简单，也要让进度变透明
客户侧 App 的目标不是把页面做得复杂，而是减少反复沟通。
我们把客户侧拆成几个高频页面：服务首页、快速报修、设备档案、工单进度、消息提醒、服务报告和评价回访。客户可以选择设备、描述故障、上传照片或视频、查看预计响应时间，也能看到工程师是否已接单、是否出发、是否到达现场、是否等待备件。
对客户来说，透明进度比“客服正在帮您催”更有信任感。
四、工程师 App 端要服务现场，而不是让工程师回去补资料
售后项目最容易失败的地方，是后台看起来很完整，但工程师现场仍然靠聊天记录处理。
工程师 App 必须解决现场的几个关键动作：
- 今日任务和路线；
- 接单确认；
- 到达现场签到；
- 故障诊断；
- 照片和视频留痕；
- 备件申请；
- 处理结果；
- 客户签字；
- 服务报告；
- 异常升级。
这些动作如果不能在现场完成，最后还是会回到“工程师晚上补表格”的老路。
五、备件申请不能只靠电话确认
B2B 售后里，备件是成本和效率的交叉点。
如果工程师到现场才发现需要备件，临时问仓库有没有库存，会造成两类问题：一类是客户等待时间变长，另一类是仓库、采购和财务都不知道这次服务到底用了什么成本。
所以系统里把备件申请做成工单内动作：
- 工程师在工单里选择备件；
- 系统显示可用库存、适配型号和替代件；
- 保内、保外、收费、赠送规则自动提示；
- 主管或仓库按权限审批；
- 出库记录回写到工单；
- 最后进入服务成本统计。
六、服务完成不是结束，签字、报告和回访才形成闭环
很多售后流程在“工程师说修好了”这里就结束了，但对企业来说，真正的闭环应该包括客户确认、服务报告、回访评价和内部复盘。
我们把服务完成拆成几个动作：
- 工程师填写处理结果；
- 系统生成服务报告；
- 客户现场签字或远程确认；
- 客户评价服务体验；
- 客服按规则回访；
- 异常评价进入复盘队列；
- 费用、备件和工时进入统计。
这样老板后面再看售后，不是看谁在群里回复积极，而是看每张工单有没有完整履约证据。
七、后台不是给老板看热闹，而是让主管能调度、追责和复盘
后台系统重点放在六个模块：运营驾驶舱、派单调度台、备件审批、SLA 监控、工程师绩效和客户服务复盘。
运营驾驶舱看整体服务压力，派单台看当天工单和工程师负载，备件审批看库存和成本，SLA 看板看响应是否超时，绩效看工程师交付质量，客户复盘看哪些客户正在变成高风险客户。
八、这类系统第一版应该控制边界
售后系统很容易做大。一开始什么都想管：客服、派单、备件、费用、合同、采购、库存、财务、绩效、客户成功。方向没错，但第一版必须先抓住主链路。
我们建议第一版优先做到：
- 客户能报修；
- 工单能分派；
- 工程师能现场履约；
- 备件能进入审批和出库记录；
- 客户能确认和评价；
- 主管能看 SLA 和异常；
- 老板能看服务成本和客户风险。
这七件事跑通以后，再补费用结算、合同续费、客户成功、知识库、AI 远程诊断等模块会更稳。
