售后工单系统的设计难点，在于把维修、退换货、投诉三类业务拆成可配置的工单类型，并为每类定义清晰的SLA计时口径。本文按“类型与字段—SLA分级—状态流转—角色交付—示例走查—上线验证”的顺序，给出可直接照表配置的工单类型表、SLA对照表和检查清单，并说明ONES Desk在自定义字段与工作流配置上的承载方式。
要点总览（TL;DR）
- 按业务对象拆分维修、退换货、投诉三类工单，再按处理路径设子类型，避免按部门拆分导致同义类型重复。
- SLA 设计先定优先级，再定响应与解决时限，最后明确计时起点、暂停条件与恢复规则，三者写入同一张对照表。
- 状态机让每张工单在任一时刻只有一个明确状态和一个责任人，交接字段缺失时禁止流转。
- 上线前用近 3 个月历史工单回放验证 SLA 达成率，低于 80% 的档位需判断时限过紧还是流程瓶颈。
- ONES Desk 支持自定义工单属性、工单内容与工作流调整，可作为承载类型与流转配置的平台方向；SLA 具体配置方式需以实际产品界面核验。
三类工单怎么拆分：类型、子类型与必填字段
工单类型应按业务对象拆分，即客户提出的诉求是什么：设备要修、货要退换、服务要投诉。按部门拆（客服单、技术单、仓储单）会让同一件事在多个类型间来回搬运，产生同义类型和重复统计。确定业务对象后，再按处理路径设子类型，因为上门维修与寄修的字段、时限、责任角色都不同。
拆分的完成标志是：任一真实售后诉求，受理人员能在30秒内判断它属于哪个类型和子类型，且不需要新建类型。若出现“其他”“综合”类工单占比超过5%，说明类型划分有遗漏，应补充子类型而非扩大父类。
维修类：按服务方式设子类型
维修类的核心对象是待修设备或产品，必填字段围绕设备识别、故障描述和服务方式展开。子类型建议至少区分上门维修、寄修、备件更换，三者的处理地点和时限差异明显。
退换货类：按资金与货物走向设子类型
退换货类同时涉及货物回仓和资金处理，子类型按“货是否退回、钱是否退”组合划分：退货退款、换货、仅退款。仅退款不涉及物流，时限应短于退货退款；换货需要出库新件，必须关联库存。
投诉类：按投诉对象设子类型
投诉类按被投诉对象划分：服务态度、产品质量、处理时效。投诉工单的关键字段是诉求期望（道歉、赔偿、重做）和情绪等级，后者影响是否需要主管介入。投诉类通常不设“解决时限”而设“闭环时限”，因为客户满意度的确认需要回访。
类型命名与编码规范
命名采用“业务对象-处理路径”结构，如“维修-上门维修”“退换货-退货退款”“投诉-服务态度”，编码用两位字母加两位数字，如WX-01、TH-02、TS-03。编码一经上线不再复用，废弃类型标记停用而非删除，保证历史工单统计口径连续。
| 工单类型 | 子类型 | 必填字段 |
|---|---|---|
| 维修（WX） | 上门维修 | 产品型号、序列号、购买日期、故障现象、上门地址、期望上门时段、保修状态 |
| 维修（WX） | 寄修 | 产品型号、序列号、故障现象、寄出物流单号、收件联系人、保外报价确认 |
| 维修（WX） | 备件更换 | 产品型号、备件名称与编码、故障现象、备件库存状态、更换方式（上门/寄件） |
| 退换货（TH） | 退货退款 | 订单号、商品与数量、退货原因、退款金额、退回物流单号、验收结论 |
| 退换货（TH） | 换货 | 订单号、原商品、换出商品、换货原因、新旧件物流单号、库存占用记录 |
| 退换货（TH） | 仅退款 | 订单号、退款原因、退款金额、审批人、退款流水号 |
| 投诉（TS） | 服务态度 | 关联工单号、涉事人员、发生时间、客户描述、期望诉求、情绪等级 |
| 投诉（TS） | 产品质量 | 产品型号、批次、问题描述、是否涉及安全、关联维修记录 |
| 投诉（TS） | 处理时效 | 原工单号、承诺时限、实际耗时、超时环节、客户期望 |
SLA怎么定：分级、计时口径与暂停规则
SLA的设计顺序是先定优先级，再定时限，最后定计时规则。优先级决定用哪一档时限，计时规则决定时限算得准不准。三者必须写进同一张对照表，否则执行时会出现“优先级高但计时口径宽”的矛盾。
按影响范围与客户等级划分优先级
优先级用两个维度交叉确定：影响范围（单台设备、批量、涉及安全）和客户等级（普通、重点、战略）。建议设四级：P1为涉及人身安全或批量故障，P2为重点客户单点故障或影响生产，P3为普通客户功能故障，P4为咨询类或非紧急诉求。客户等级由合同或服务协议确定，写入客户档案字段，受理时自动带出，避免人工判断不一致。
响应时限与解决时限分开定义
响应时限指从工单创建到首次有效回复的时间，解决时限指从创建到问题解决或给出客户认可方案的时间。两者分开的意义在于：响应快不代表解决快，把两者合并会让工程师为了“响应达标”而提前点击状态，掩盖真实处理周期。投诉类可再增加“回访时限”，从解决到完成满意度回访。
计时起点、暂停与恢复规则
计时起点统一为工单创建时间，客户通过电话报修由客服代建的，以通话结束时间为创建时间。暂停条件只设两类：等待客户补充信息、等待备件或物流。暂停需由处理人填写暂停原因并选择恢复条件，系统记录暂停起止时间，恢复后累计计时继续。审批等待、内部排队不设暂停，这类时间属于内部效率问题，应计入时限暴露出来。
工作日历与节假日口径
时限按工作日还是自然日计算，需在SLA表中逐档标注。P1、P2建议按自然日24小时计时，因为安全和生产影响不因下班而中止；P3、P4可按工作日历计时，日历需提前维护节假日和特殊工作日。跨时区服务需明确以哪个时区的工作日历为准。
超时预警与升级触发点
每档时限设两个触发点：剩余20%时间时预警给处理人，超时即升级给上级并记录升级原因。预警和升级规则与时限写在同一行，便于配置时一次录入。
| 类型 | 优先级 | 响应时限 | 解决时限 | 计时口径 | 暂停条件 | 升级触发 |
|---|---|---|---|---|---|---|
| 维修 | P1 | 30分钟 | 8小时 | 自然日 | 等待客户确认上门时间 | 超时升级至服务主管 |
| 维修 | P2 | 2小时 | 24小时 | 自然日 | 等待备件到货 | 剩余20%预警，超时升级 |
| 维修 | P3 | 4工作小时 | 3工作日 | 工作日历 | 等待客户补充故障信息 | 超时升级至组长 |
| 退换货 | P2 | 2小时 | 2工作日 | 工作日历 | 等待客户寄回物流 | 超时升级至售后主管 |
| 退换货 | P3 | 4工作小时 | 5工作日 | 工作日历 | 等待仓库验收 | 剩余20%预警 |
| 投诉 | P1 | 30分钟 | 24小时闭环 | 自然日 | 等待客户方便回访 | 超时升级至客服负责人 |
| 投诉 | P2 | 2小时 | 3工作日闭环 | 工作日历 | 等待第三方责任认定 | 超时二次升级 |
| 投诉 | P3 | 4工作小时 | 5工作日闭环 | 工作日历 | 无 | 超时升级至投诉专员主管 |
流转规则怎么设：状态、交接与升级路径
状态机的作用是让每张工单在任何时刻只有一个明确状态和一个明确责任人。设计时先列状态集合，再列合法流转，最后标注每次流转的交接动作。非法流转（如从“待受理”直接跳到“已关闭”）应在系统中禁止，而不是靠人工自觉。
三类工单的状态集合
维修类状态：待受理→已派单→处理中→待客户确认→已完成→已关闭，其中“处理中”可进入“待备件”挂起。退换货类状态：待受理→待审核→待客户寄回→待验收→退款/换货处理中→已完成→已关闭。投诉类状态：待受理→调查中→方案沟通中→待回访→已闭环→已关闭。三类共用“已关闭”作为终态，关闭后仅允许“重开”。
交接责任与审批节点
受理环节由客服完成信息补全和分类，派单环节由调度或组长指定处理人，处理环节由工程师或专员填写处理记录，回访环节由客服确认客户满意，关闭由系统在回访完成后自动或人工触发。退换货的“待审核”节点由售后主管审批退款金额和换货资格，“待验收”由仓储录入验收结论，财务节点在退款执行后回填流水号。投诉的二次升级指首次方案客户不接受时，升级至客服负责人并重新设定闭环时限。
退回、重开与挂起规则
退回用于信息不全：处理人将工单退回受理人，状态回到“待受理”，计时不暂停。重开用于关闭后客户再次反馈同一问题：生成关联的新工单并引用原工单号，原工单保持关闭，避免统计数据被反复改写。挂起仅限SLA表中列明的暂停条件，挂起超过约定时长（如7天）自动提醒并允许强制恢复计时。
角色分工与各环节交付物
角色分工要落到“谁在哪个状态做什么、留下什么记录”。同一角色在不同类型工单中职责不同，例如客服在维修单中是受理人，在投诉单中可能是回访人。责任矩阵按“角色×环节”填写，每格写明动作和输出记录。
| 角色 | 受理 | 处理 | 审核 | 关闭 |
|---|---|---|---|---|
| 客服 | 补全客户与产品信息、判定类型与优先级、创建工单 | 跟进客户补充信息、记录沟通内容 | — | 回访确认后关闭，记录满意度 |
| 调度/组长 | 复核分类与优先级 | 派单、调整处理人、处理升级 | — | — |
| 维修工程师 | — | 填写故障诊断、维修方案、更换备件记录 | — | 提交完成记录与客户签字 |
| 仓储 | — | 录入收货、验收结论、出库新件单号 | — | — |
| 售后主管 | — | — | 审批退款金额、换货资格、保外报价 | — |
| 财务 | — | 执行退款并回填流水号 | — | — |
| 投诉专员 | — | 调查事实、拟定方案、与客户沟通 | — | 完成回访并记录闭环结论 |
SLA责任归属按“当前状态责任人”判定：工单处于哪个状态，该状态对应的处理角色承担该段时限。超时追责以系统记录的流转时间和暂停记录为依据，不以口头说明为准。跨部门交接的凭证是状态流转时必填的交接字段，如派单时的处理人、验收时的验收结论、退款时的流水号，缺字段则不允许流转。
一个完整示例：从客户报修到工单关闭
以下为演示情景，用于说明类型、SLA与流转如何配合，数据为示例值。
维修工单走查
客户A（重点客户）电话报修一台生产设备无法启动。客服创建“维修-上门维修”工单，产品型号和序列号从客户档案带出，故障现象填“通电无反应”，客户等级自动带出为“重点”，优先级判定为P2，响应时限2小时、解决时限24小时，按自然日计时。客服在15分钟内完成首次回复，响应达标。调度派单给工程师B，状态转为“已派单”。工程师现场诊断需更换电源模块，填写备件编码，工单进入“待备件”挂起，暂停原因“等待备件到货”，计时暂停。备件次日到货，仓储出库并回填单号，工单恢复计时。工程师上门更换后填写维修记录，状态转“待客户确认”，客户确认后转“已完成”，客服回访后关闭。全程解决时限累计约20小时，未超时。
投诉工单走查
同一客户就备件等待时间发起“投诉-处理时效”工单，关联原维修单号，优先级P2，闭环时限3工作日。投诉专员调查发现备件调拨环节无预警，拟定方案为补偿延保并说明改进措施。首次沟通客户不接受，触发二次升级至客服负责人，重新设定闭环时限并追加回访。第二次回访客户接受方案，工单转“已闭环”，回访记录和方案确认写入工单后关闭。
示例暴露的配置问题
第一，备件等待挂起没有设置最长挂起时长，若备件长期不到货，工单会无限期暂停，SLA形同虚设，应补充挂起超时提醒。第二，投诉二次升级后未同步调整关联维修单的优先级，两个工单的时限口径不一致。第三，客户确认环节没有设置超时自动确认规则，客户长期不回复会导致工单滞留。这些问题在配置阶段通过回放历史工单即可发现。
上线前的完成检查与验证方法
配置完成后不能直接上线，需先做完整性检查，再用历史工单回放验证SLA是否可达成。回放的价值在于用真实数据检验时限设定，避免上线后大面积超时或时限过松失去约束力。
类型与字段完整性检查
- 每个类型至少有一个子类型，无“其他”类兜底；
- 必填字段在创建和流转两个环节均有校验，缺字段无法进入下一状态；
- 类型编码唯一，停用类型不出现在新建选项中；
- 优先级与客户等级的对应关系可从客户档案自动带出；
- 每档SLA均有响应、解决时限和计时口径，无空白行。
历史工单回放验证
抽取近3个月的真实工单，按新规则重新计算响应和解决耗时，统计各类型各优先级的达成率。达成率低于80%的档位，需判断是时限过紧还是流程存在瓶颈：若多数超时集中在同一环节（如备件调拨），应优化流程而非放宽时限；若超时分散且与处理量相关，可调整时限或增加人力。回放结论写成模板：类型、优先级、样本量、原达成率、调整建议、调整后预估达成率。
流转规则的空转与漏派检查
逐条测试状态流转：是否存在无处理人的状态、是否存在无法退出的状态、退回后是否能重新派单、关闭后重开是否生成关联工单。重点检查派单规则未匹配到处理人时的兜底逻辑，避免工单停留在“待派单”无人认领。
上线后复盘与调整机制
上线首月每周复盘一次，之后按月复盘。复盘看三项指标：各档SLA达成率、暂停时长占比、升级次数。暂停占比持续偏高说明前置信息收集或备件管理有问题；升级次数集中在某类型说明该类型的时限或流程需要重新设计。调整SLA需留存版本记录，保证历史工单按当时口径统计。
在工单平台承载上述设计时，类型与字段需要可自定义，状态流转需要可配置，优先级需要能按规则带出。ONES Desk支持自定义工单属性和工单内容以适配不同收集场景，并可灵活调整工作流以适应不同工作方式，同时支持评估和定义工单优先级；其企业版提供统一门户集中接收工单、自定义处理流程与字段配置以及多维度数据统计能力。SLA时限、暂停与升级规则的具体配置方式，需以实际产品界面核验后落地。
常见问题
维修、退换货、投诉三类工单的优先级如何统一判定，避免同一客户在不同类型中优先级不一致？
优先级建议统一用两个维度交叉确定：影响范围（单台设备、批量、涉及安全）和客户等级（普通、重点、战略）。客户等级由合同或服务协议确定，写入客户档案字段，受理时自动带出，不依赖人工判断。这样同一客户发起维修或投诉时，客户等级维度保持一致，差异只来自影响范围。若投诉涉及原维修单，可在投诉工单中关联原单号，并同步调整关联工单的优先级，避免两个工单时限口径不一致。
SLA 计时中，等待客户补充信息和等待备件可以暂停，那审批等待和内部排队为什么不能暂停？
暂停条件只设两类：等待客户补充信息、等待备件或物流。审批等待和内部排队属于内部效率问题，如果也设为暂停，时限会被内部流程消耗掉，SLA 就失去暴露瓶颈的作用。把这两类时间计入时限，才能通过超时数据发现审批环节或派单环节的积压。若审批确实需要较长时间，应优化审批流程或调整时限档位，而不是用暂停掩盖。
历史工单回放时，达成率低于 80% 的档位应该放宽时限还是优化流程？
先看超时分布。若多数超时集中在同一环节（如备件调拨、仓库验收），说明是流程瓶颈，应优化该环节而非放宽时限；若超时分散且与处理量明显相关，可考虑调整时限或增加人力。回放结论建议写成模板：类型、优先级、样本量、原达成率、调整建议、调整后预估达成率。调整 SLA 需留存版本记录，保证历史工单按当时口径统计。
工单关闭后客户再次反馈同一问题，应该重开原工单还是新建工单？
建议生成关联的新工单并引用原工单号，原工单保持关闭。重开原工单会反复改写历史统计数据，影响达成率、处理时长等指标的连续性。新工单继承原工单的客户、产品、历史处理记录，处理人可快速了解前因。若问题确属原处理未解决，可在新工单中标记关联原因，便于后续复盘区分“新问题”和“未解决遗留”。
投诉工单设“闭环时限”而不是“解决时限”，回访不成功时怎么处理？
闭环时限覆盖从受理到完成满意度回访的全过程。回访不成功时，工单不能直接关闭，应记录回访尝试次数、客户未接或拒绝的原因，并按升级规则转交上级或更换回访人。若多次回访仍无法确认满意度，可设置“视为闭环”的条件（如三次回访未接通），但需在工单中留痕，并在复盘时单独统计这类工单，避免用“视为闭环”掩盖真实的服务缺口。
