按业务类型设置售后工单的SLA和流转规则，核心是把客户承诺拆成可配置的规则：先划分维修、退换货、投诉等工单类型，再为每类定义判定字段、优先级和响应/解决时限，最后把状态流转、责任角色和升级条件绑定到类型上。规则最终要在工单平台中承载，ONES Desk 的自定义字段与工作流配置可作为落地方向之一。
要点总览（TL;DR）
- 按业务动作、责任团队和客户承诺差异划分维修、退换货、投诉、咨询四类工单，用产品型号、订单号、诉求等必填字段做类型判定，类型层级控制在两级以内。
- SLA拆成响应时限和解决时限两个独立指标，按业务类型×优先级组合成时限矩阵，并明确工作日历、服务时段和暂停计时条件。
- 每类工单单独设计状态机，每个状态写清责任角色和交付物，跨团队交接设定触发条件和必填信息，退回、挂起、重开等异常路径单独定义规则。
- 升级规则围绕预警、超时、多次催办三个触发点设计，投诉类走独立加急路径，SLA豁免须经审批留痕并单独统计。
- 先选一个业务类型或区域试点两到四周，用首次响应达成率、解决达成率、退回率、升级率校验档位，调整形成版本记录后再全量上线。
先划分售后工单类型与判定口径
类型划分的起点是业务动作和责任团队的差异，而不是客户口头描述的措辞。同一个客户说“东西坏了要换”，可能同时涉及维修检测和退换货两个动作，如果只按一句话建一个类型，后续SLA和流转都会失去区分度。建议按三个维度判断：客户要的结果是什么（修好、换新、退款、得到答复）、由哪个团队主责（技术支持、仓储售后、客服投诉组）、客户承诺差异有多大（是否需要上门、是否涉及物流时效、是否涉及赔付）。
典型售后场景可以归为四类。维修类：产品出现故障，需要检测、维修或更换配件，主责通常是技术支持或服务网点，承诺重点是响应速度和修复周期。退换货类：客户要求退货或换货，主责是售后受理与仓储物流，承诺重点是审核时限和物流节点。投诉类：客户对服务、产品质量或处理结果不满，主责是客服主管或投诉专员，承诺重点是首次回应速度和闭环回访。咨询类：产品使用、保修政策、进度查询等，主责是一线客服，承诺重点是首次响应时间。四类之外如果还有安装、上门保养等动作，可以作为维修类的子类型处理。
类型判定要靠必填字段落地，而不是靠受理人员主观选择。建议在工单提交环节设置以下字段作为判定输入：产品型号与序列号、订单号或购买凭证、故障现象描述、客户明确诉求、期望完成时间、是否在保修期内。受理人员选择类型后，系统按类型带出对应的必填字段；反过来，字段组合也可以用于校验类型选择是否合理，例如客户诉求选了“退款”却把类型选成“维修”，就应触发提示或转由主管确认。
类型层级建议控制在两级以内：一级是业务类型，二级是子类型，例如“退换货—退货”“退换货—换货”“维修—上门维修”“维修—寄修”。层级过深会让SLA矩阵和状态机数量成倍增加，配置和维护成本迅速上升。判断是否需要新增子类型的标准是：客户承诺或责任团队是否真的不同。如果两个子类型的时限、角色、流转路径完全一致，就合并为一个类型，用字段区分即可。
| 类型名称 | 判定字段示例 | 责任团队 | 客户承诺差异 |
|---|---|---|---|
| 维修 | 产品型号、故障现象、保修状态、是否需上门 | 技术支持/服务网点 | 承诺响应时间与修复周期，上门与寄修时限不同 |
| 退换货 | 订单号、购买时间、诉求（退货/换货）、商品状态 | 售后受理/仓储物流 | 承诺审核时限与物流节点，退货涉及退款到账时间 |
| 投诉 | 投诉对象、事件描述、影响程度、是否要求赔付 | 客服主管/投诉专员 | 承诺首次回应速度与闭环回访，敏感投诉需加急 |
| 咨询 | 咨询主题、产品型号、关联订单 | 一线客服 | 承诺首次响应时间，通常不涉及解决时限 |
为每类工单定义SLA口径与计时规则
SLA要拆成两个独立指标：响应时限和解决时限。响应时限指从工单创建到责任人首次有效回复的时间，解决时限指从创建到客户确认解决或工单关闭的时间。两者分开定义的原因在于，响应快不代表解决快，维修类工单可能几分钟内就响应了，但实际修复需要几天；如果只设一个总时限，就无法区分“没人接”和“在修但没修完”两种问题。咨询类工单通常只需要响应时限，退换货和维修类需要同时设置两个时限，投诉类则要额外设置回访时限。
时限档位按“业务类型×优先级”组合设定，而不是所有类型共用一套数字。优先级建议用三到四档，例如紧急、高、中、低，判定依据包括是否影响安全、是否涉及大额订单、客户是否已多次催办、是否属于重点客户。组合之后形成矩阵，每个格子填响应时限和解决时限。下面是一个演示用的矩阵结构，具体数字需要企业根据自身服务能力和客户合同确定，不能直接照搬。
| 业务类型 | 优先级 | 响应时限（演示） | 解决时限（演示） | 计时说明 |
|---|---|---|---|---|
| 维修 | 紧急 | 30分钟内 | 24小时内给出处理方案 | 等待客户寄回配件期间暂停 |
| 维修 | 中 | 4小时内 | 3个工作日内 | 按工作日历计时 |
| 退换货 | 高 | 2小时内 | 48小时内完成审核 | 等待客户提供凭证期间暂停 |
| 投诉 | 紧急 | 15分钟内 | 24小时内闭环并回访 | 不暂停，全程计时 |
| 咨询 | 低 | 8小时内 | 不设解决时限 | 按服务时段计时 |
计时规则要写清楚三件事：工作日历、服务时段、暂停条件。工作日历决定哪些天计入时限，例如是否包含周末和法定节假日；服务时段决定每天从几点到几点计时，例如7×24小时还是9×18小时；暂停条件决定哪些等待状态不计入时限，常见的有等待客户补充信息、等待客户寄回商品、等待第三方检测结果。暂停条件必须和状态机中的挂起状态对应，否则会出现“工单挂着但计时还在跑”的争议。投诉类工单一般不建议设置暂停，因为客户感知的是整体处理时长。
SLA目标值和内部预警阈值要分开设置。SLA目标是对客户的承诺，预警阈值是内部管理线，通常设在目标值的70%到80%位置。例如解决时限是24小时，可以在剩余6小时时触发预警，提醒责任人加快处理。预警阈值的作用是给团队留出补救时间，避免等到超时才被动升级。预警和超时的通知对象也应不同：预警通知责任人和其主管，超时则升级到更高层级。
设计状态流转、角色分工与交接节点
状态机按业务类型分别设计，而不是所有工单共用一条流程。维修类的典型状态包括：待受理、已受理待检测、检测中、待客户确认方案、维修中、待寄回、已完成、已关闭。退换货类的状态包括：待受理、审核中、待客户寄回、已收货待质检、退款处理中或换货发货中、已完成、已关闭。投诉类的状态更短：待受理、处理中、待回访、已闭环。咨询类可以简化为待受理、处理中、已回复、已关闭。每类状态集合不同，但命名和含义要保持一致，方便跨类型统计。
每个状态要明确责任角色和交付物。以维修类为例：待受理由一线客服负责，交付物是完整工单信息和类型判定；检测中由技术支持负责，交付物是检测结论和处理方案；待客户确认方案由客服负责跟进，交付物是客户确认记录；维修中由服务网点负责，交付物是维修记录；已完成由客服回访确认，交付物是客户确认解决的记录。角色职责表要写到“谁在什么状态下必须做什么、产出什么”，而不是只写岗位名称。
跨团队交接是流转设计中最容易出问题的环节。交接触发条件要明确，例如维修类从“检测中”转到“维修中”，触发条件是检测结论为“需要维修”且客户已确认方案。交接时必须携带的必填信息包括：故障检测结论、已确认的处理方案、客户联系方式与可服务时间、关联的订单或产品信息。缺少必填信息时，系统应阻止流转或标记为不完整交接，由交接方补齐后再提交。这样可以避免接手的团队反复回头找信息。
异常流转要单独设计，不能只画正常路径。退回：下游团队发现信息不足或不属于本团队职责时，退回上一节点并填写退回原因，退回次数应计入统计。挂起：等待客户补充信息或等待外部检测结果时挂起，挂起期间按SLA规则决定是否暂停计时，挂起原因必须选择或填写。重开：工单关闭后客户再次反馈同一问题，允许重开并关联原工单，重开后的SLA计时规则要提前约定，例如重新计算响应时限或沿用原时限剩余时间。这三类异常路径如果没有明确规则，实际运行中就会出现工单卡住无人处理的情况。
设置超时升级、例外与优先级调整规则
升级规则围绕三个触发点设计：预警、超时、多次催办。预警触发后通知责任人和直属主管，动作是提醒处理；超时触发后升级到部门负责人，动作是介入协调并给出处理计划；客户多次催办或投诉升级时，触发跨层级升级，通知到售后负责人。每个触发点要写清楚通知对象、通知方式和期望动作，避免出现“通知了但没人负责”的情况。升级记录应保留在工单上，作为后续复盘和考核的依据。
投诉类工单需要独立的加急路径。建议投诉工单创建后自动标记为高优先级或紧急，跳过普通排队直接进入投诉专员队列；如果投诉涉及安全、媒体曝光或大额赔付，设置更短的响应时限并同时通知客服主管和售后负责人。加急不等于可以绕过流程，投诉工单的状态流转仍要完整记录，回访环节不能省略，否则无法证明问题已闭环。
例外处理和SLA豁免必须有审批和记录。常见例外包括：客户原因导致无法联系、客户要求延后处理、不可抗力导致服务中断、工单本身不属于SLA覆盖范围。处理方式是责任人提交例外申请，说明原因和预计恢复时间，由主管审批；审批通过后该工单的SLA计时暂停或标记为豁免，并在工单上保留审批人和审批时间。豁免不能由责任人自行勾选，否则SLA数据会失去可信度。统计SLA达成率时，豁免工单应单独列出，不能直接混入达成或未达成。
优先级调整要控制权限并留痕。一线人员可以在受理时按判定规则设定优先级，但上调优先级（例如从中调到紧急）应限制给主管或以上角色，下调优先级同样需要审批。每次调整记录调整人、调整前后值、调整原因。优先级调整频繁的工单类型，说明初始判定规则可能不合理，应在复盘时检查判定字段和阈值。
用试点数据校验并迭代规则
规则设计完成后不要直接全量上线，先选一个业务类型或一个区域团队做试点。试点范围建议覆盖该类型下至少两个优先级档位和至少一个跨团队交接节点，观察周期以两到四周为宜，周期太短看不出退回和升级的真实比例。试点前要明确基线数据，例如当前该类工单的平均首次响应时长和解决时长，作为对比参照。
试点期间重点观察四个指标：首次响应达成率、解决达成率、退回率、升级率。首次响应达成率低，说明响应时限过紧或工单分配规则有问题；解决达成率低但响应达成率高，说明瓶颈在解决环节，需要检查交接节点或资源排班；退回率高，说明类型判定字段或交接必填信息不完整；升级率高，说明预警阈值设置过早或优先级判定偏严。每个指标要结合具体工单抽查原因，不能只看数字。
根据数据调整时限档位和流转节点。调整方向包括：放宽明显无法达成的时限、增加或合并状态节点、补充交接必填字段、调整预警阈值。每次调整都要记录调整内容、依据数据和生效时间，形成规则版本。规则变更后要通知所有受影响的角色，并在工单平台中同步更新配置，避免出现文档和系统不一致的情况。建议每季度做一次规则复盘，把SLA达成率、退回率、升级率与上季度对比，判断规则是否仍然匹配业务量和服务能力。
| 试点观察项 | 记录内容 | 调整判断 |
|---|---|---|
| 首次响应达成率 | 按类型和优先级统计达成比例 | 低于目标时检查时限档位和分配规则 |
| 解决达成率 | 按类型统计按时解决比例 | 偏低时检查交接节点和资源排班 |
| 退回率 | 退回次数、退回原因分布 | 偏高时补充判定字段和交接必填信息 |
| 升级率 | 预警、超时、催办触发次数 | 偏高时调整预警阈值和优先级口径 |
规则要落到工单平台中才能执行。ONES Desk 支持自定义工单属性和工单内容配置，可用于承载类型判定字段和不同收集场景；其工作流可灵活调整，适合把上述状态流转和交接节点配置成实际流程；优先级定义能力可用于区分紧急工单。工单处理进度和分析报表可帮助管理者观察各类型的处理情况。SLA计时、暂停和预警的具体配置方式，以及按类型区分多套流程的粒度，需要在实际环境中核验后再确定配置方案。
完成检查：规则可执行性核对
上线前用下面这份清单逐项核对，每项标注通过或待改，待改项明确责任人和完成时间。核对的目标是确认类型、SLA、流转、升级四部分配置完整且相互一致，而不是重新设计规则。
| 核对项 | 核对内容 | 通过标准 | 结果 |
|---|---|---|---|
| 类型判定 | 每类工单都有判定字段和责任人 | 提交时能按字段判定类型，每类有明确主责团队 | 通过/待改 |
| 类型层级 | 子类型数量可控，合并标准已执行 | 层级不超过两级，时限和角色相同的已合并 | 通过/待改 |
| SLA矩阵 | 类型×优先级无空缺档位 | 每个组合都有响应和解决时限，或明确标注不适用 | 通过/待改 |
| 计时规则 | 工作日历、服务时段、暂停条件明确 | 暂停条件与挂起状态一一对应，投诉类不暂停 | 通过/待改 |
| 状态流转 | 无死胡同，异常路径有处理 | 每个状态有出口，退回、挂起、重开均有规则 | 通过/待改 |
| 角色交接 | 交接触发条件和必填信息完整 | 缺必填信息时无法完成交接 | 通过/待改 |
| 升级规则 | 预警、超时、催办触发点和通知对象明确 | 每个触发点有责任人和期望动作 | 通过/待改 |
| 例外记录 | 豁免有审批和留痕 | 豁免不能自行勾选，统计时单独列出 | 通过/待改 |
| 试点复盘 | 试点数据已分析并形成调整记录 | 四项指标有基线对比，调整有版本记录 | 通过/待改 |
核对完成后，把类型清单、SLA矩阵、状态流转图、角色职责表、升级例外规则和试点记录整理成一份配置说明，与工单平台中的实际配置逐项对照。上线后第一个月保持较高频率的抽查，重点看退回和升级工单的原因分布，确认规则在实际业务量下仍然可执行，再转入常规季度复盘。
常见问题
维修类工单在等待客户寄回配件期间，SLA计时应该暂停吗？
建议暂停，但前提是暂停条件与状态机中的挂起状态一一对应。具体做法是：工单进入“待客户寄回”状态时自动挂起计时，客户寄回并签收后恢复计时。暂停期间不计入解决时限，但响应时限通常已经完成，不受影响。需要注意两点：一是挂起原因必须选择或填写，便于后续统计客户原因造成的时长占比；二是暂停不能由责任人随意勾选，应由状态流转自动触发，避免出现“工单挂着但计时还在跑”或“人为暂停掩盖超时”的情况。
投诉工单是否也应该设置解决时限，还是只考核首次回应？
投诉类建议同时设置首次回应时限、闭环时限和回访时限三个节点。首次回应解决的是客户情绪和预期管理，闭环时限约束问题处理完成的时间，回访时限确保处理结果得到客户确认。投诉类一般不建议设置计时暂停，因为客户感知的是从投诉到闭环的整体时长，中途挂起会让客户觉得被搁置。如果投诉涉及安全、媒体曝光或大额赔付，可以设置更短的时限并同时通知客服主管和售后负责人，但状态流转和回访记录仍要完整保留。
同一张工单同时涉及维修和退换货，类型应该怎么选？
建议按客户明确诉求确定主类型，另一个动作作为关联工单或子任务处理，避免一张工单挂两个类型导致SLA口径混乱。例如客户要求换新，主类型选“退换货—换货”，检测环节作为换货流程中的状态节点；如果检测后确认可以维修且客户同意，再由受理人员转为维修类工单并关联原单。类型判定字段中的“客户明确诉求”应作为主类型选择的主要依据，受理人员选错类型时，系统可通过字段组合校验触发提示或转主管确认。
试点期间SLA达成率很低，应该先放宽时限还是先查流程？
先区分是响应环节还是解决环节的问题。如果首次响应达成率低，优先检查工单分配规则和排班，时限过紧只是可能原因之一；如果响应达成率高但解决达成率低，瓶颈通常在交接节点或资源排班，放宽时限只能掩盖问题。退回率高说明类型判定字段或交接必填信息不完整，升级率高说明预警阈值设置过早或优先级判定偏严。建议对未达成工单逐单抽查原因，按原因分布决定调整方向，每次调整记录依据数据和生效时间，形成规则版本。
SLA豁免由谁审批，统计达成率时怎么处理？
豁免应由责任人的直属主管或更高层级审批，责任人不能自行勾选。申请时需说明豁免原因（如客户要求延后、不可抗力、工单不属于SLA覆盖范围）和预计恢复时间，审批通过后在工单上保留审批人和审批时间。统计SLA达成率时，豁免工单应单独列出，不能直接计入达成或未达成，否则数据会失真。建议定期复盘豁免原因分布，如果某一类豁免频繁出现，说明SLA覆盖范围或计时规则本身需要调整。
