微信群里一句"设备不动了"，然后是一串对话："我看看""派个人过去""到了""修好了"。三个月后，没人能说清这台设备出过几次故障、平均多久修好、花了多少成本。
工单系统解决的不是"记录"，而是责任的明确和闭环的确认。
工单的必备字段
| 字段 | 说明 | 为什么 |
|---|---|---|
| 工单号 | 唯一标识 | 便于引用与查询 |
| 报修时间 | 精确到分钟 | SLA 计算的起点 |
| 客户与设备 | 哪个客户的哪台设备 | 关联历史 |
| 故障描述 | 客户原话 + 分类 | 分类是分析的基础 |
| 紧急程度 | 一般/紧急/停产 | 决定响应优先级 |
| 处理人 | 谁负责 | 责任明确 |
| 响应状态 | 待派单/处理中/待确认/已关闭 | 进度可见 |
| 处理记录 | 做了什么、更换了什么 | 知识沉淀 |
| 完成时间 | 客户确认的时间 | SLA 计算终点 |
| 客户评价 | 满意度 | 闭环确认 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
报修入口：越简单越好
三个常见入口，按推荐度排序：
| 入口 | 优点 | 适用 |
|---|---|---|
| 设备二维码扫码 | 自动带出设备信息，无需描述 | 有实体设备的场景 |
| 网页表单 | 简单，可挂官网/公众号 | 通用 |
| 客服代录 | 客户只需打电话 | 客户不习惯自助的场景 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
扫码报修是最优解，因为它自动关联了设备信息（型号、购买日期、保修状态、历史维修记录），客户只需描述故障现象。
报修入口的设计原则：让客户少打字。每多一个必填字段，报修率就下降一截。理想状态是：扫码 → 选故障类型 → 提交，三步完成。
派单与 SLA
派单规则
| 模式 | 适用 |
|---|---|
| 按区域派 | 外勤服务场景 |
| 按技能派 | 设备类型差异大 |
| 按负载派 | 团队较大 |
| 抢单 | 需要激励的场景 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
中小企业通常用"按区域 + 人工判断"，不需要复杂的自动派单算法。
SLA 的三个时间点
| 指标 | 定义 | 常见承诺 |
|---|---|---|
| 响应时效 | 从报修到有人联系 | 2–24 小时内 |
| 到场时效 | 从报修到人员到达 | 24–72 小时（视距离） |
| 解决时效 | 从报修到问题解决 | 按故障类型分档 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
系统应该自动记录这三个时间点，超时的工单自动提醒并升级。
一个实用做法：把 SLA 承诺公开展示给客户（如"我们承诺 24 小时内响应"）。这既是服务承诺，也是一种自我约束机制——公开的承诺比内部的制度更有效。
闭环：客户确认才算完成
这是工单系统最关键的设计：工单不能由处理人自行关闭，必须由客户确认。
流程：
- 处理人完成 → 标记为"待客户确认"
- 客户收到确认请求（短信/微信）
- 客户确认或提出异议
- 确认后关闭；有异议则重开
这个设计的价值：
- 避免"我以为修好了"
- 留下客户确认的记录（争议时有据）
- 客户满意度数据真实
工单数据的二次价值
工单数据积累后，能做三件有价值的事：
一、产品质量反馈
统计故障类型分布：
| 故障类型 | 发生次数 | 占比 |
|---|---|---|
| A 部件损坏 | 32 | 40% |
| B 部件老化 | 18 | 22% |
| 软件问题 | 15 | 19% |
| 操作不当 | 15 | 19% |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这个分布直接告诉你该改进什么。如果某个部件故障率异常高，可能是设计问题或供应商问题。
二、配件库存优化
哪些配件更换频率高 → 应该常备库存；哪些很少换 → 减少备货。
三、客户分层
哪些客户报修频繁（可能是设备老化，是换新机会）；哪些客户从未报修（可能是满意度高的潜在推荐来源）。
工单系统最大的价值不在服务环节，而在它记录了产品最真实的失效数据。这些数据对研发和质量改进的价值，往往超过对售后部门的价值。
落地建议
| 阶段 | 动作 | 周期 |
|---|---|---|
| 第一期 | 工单录入 + 状态流转 + 闭环确认 | 2–3 周 |
| 第二期 | 扫码报修 + 自动提醒 | 1–2 周 |
| 第三期 | SLA 统计 + 故障分析 | 1–2 周 |
| 第四期 | 知识库联动（同类问题自动推荐解法） | 持续 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
常见错误
| 错误 | 后果 | 规避 |
|---|---|---|
| 处理人自行关单 | 问题未真正解决 | 必须客户确认 |
| 不记录处理过程 | 知识无法沉淀、无法追溯 | 强制填写处理记录 |
| 故障无分类 | 无法分析 | 预设分类，必选 |
| 无 SLA 提醒 | 超时无人知 | 自动提醒与升级 |
| 只记录不分析 | 数据浪费 | 定期输出故障分布报告 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
售后工单要在 ERP 里做吗？+
通常不需要，也不建议。售后工单是一个相对独立、边界清晰的模块，用常规方式实现即可，成本低、周期短（2–4 周）。只有在需要与 ERP 深度集成（如自动生成配件领用单、自动结算服务费）时，才需要考虑在 ERP 内实现。建议先用独立模块跑通流程，验证后再决定是否集成。
客户不愿意扫码报修怎么办？+
提供多种入口，不要只依赖扫码。常见组合是：扫码（推荐）+ 电话由客服代录。客服代录时系统同样生成工单，只是录入人不同。另外可以在设备交付时就贴好二维码并说明用法，形成习惯。关键是无论客户用哪种方式，最终都进入同一个工单系统——入口可以多样，数据必须统一。
工单系统会不会增加售后人员的工作量？+
短期会（多了一步录入），长期会减少（减少沟通、减少扯皮、减少重复解释）。关键在于让录入动作尽量轻：手机端操作、支持语音、支持拍照、字段尽量少。如果录入一次超过一分钟，就会被抵触。另一个平衡点是让一线人员先受益，比如系统自动推送同类问题的历史解法，减少他们排查的时间。
本文为通用性售后管理建议，SLA 承诺的具体时效应结合企业实际服务能力设定。