售后工单系统怎么设计维修、退换货、投诉的工单类型与SLA
售后工单的类型和SLA如果只按“维修、退换货、投诉”三个名字建好,实际运行中仍会遇到归类争议、时限无法计时、交接无人认领的问题。本文围绕这三类业务,给出从类型拆分、SLA设定、状态流转到上线校准的完整设计方法,并说明这些规则如何落到ONES Desk的工单属性、工作流与优先级配置中。
Table of Contents
要点总览(TL;DR)
- 工单类型分两层设计:一级类型固定为维修、退换货、投诉,二级子类型按处理方式或严重程度拆分,并配稳定编码保证报表口径连续。
- SLA由响应时限、处理时限、暂停规则和升级路径四个要素组成,三类业务按各自节奏差异化设定,时限分档依据优先级或影响范围。
- 类型和时限要落到状态流转上才能计时:通用状态链加派工验收、审核物流、调查回复等特殊节点,每个交接点明确责任角色和交接物。
- 上线前先检查类型互斥穷尽、时限有依据、字段能支撑分派,再选一条业务线试运行两到四周,用超时率、升级率、一次解决率校准。
- ONES Desk 支持自定义工单属性、灵活调整工作流和评估工单优先级,可作为类型与流转规则的落地平台;SLA计时与暂停是否按类型配置需实施时确认。
先定分类维度:维修、退换货、投诉怎么拆成可用的工单类型
工单类型的设计目标是让每一张工单在提交时就能被识别、被分派、被统计。可行的做法是分两层:一级类型对应售后业务对象,固定为维修、退换货、投诉三类;二级子类型对应处理方式或严重程度,决定后续走哪条流程、套哪档时限。一级类型保持稳定,二级子类型可以随业务调整,这样报表口径不会因为流程细化而频繁变化。
二级子类型的拆分依据要选与处理动作直接相关的维度。维修按故障性质和是否需要上门拆分,因为这两点直接决定是远程指导还是派工上门,处理周期差异明显。退换货按诉求形式拆分,退货、换货、仅退款对应的审核材料、物流动作和退款节点各不相同。投诉按投诉对象和严重程度拆分,对象决定由谁调查,严重程度决定首响速度和是否升级。
每类工单需要一套必填字段,字段的作用是让受理人不必反复追问就能判断类型和时限。维修类至少需要产品型号、购买日期或保修状态、故障描述、故障发生时间、是否影响安全使用、联系方式与服务地址。退换货类至少需要订单号、商品与型号、购买渠道、诉求类型、问题凭证(照片、视频、检测报告)、物流单号。投诉类至少需要投诉对象(产品、服务人员、配送、门店)、事件时间与经过、客户诉求、期望回复方式、是否已向外部渠道反映。
类型命名建议采用“一级类型-二级子类型”的固定格式,并配一个稳定编码,例如“维修-保内上门”“退换货-七天无理由退货”“投诉-服务态度”。编码一经启用不随意更改,新增子类型时追加编码而不是复用旧编码。这样在导出报表、配置SLA和做趋势分析时,名称可以调整,统计口径保持连续。
| 一级类型 | 二级子类型 | 触发条件 | 必填字段 |
|---|---|---|---|
| 维修 | 保内远程支持 | 故障可通过指导排除,无需上门 | 产品型号、保修状态、故障描述、联系方式 |
| 维修 | 保内上门维修 | 需现场检测或更换部件 | 上述字段加服务地址、期望上门时段 |
| 维修 | 保外维修 | 超出保修期或人为损坏 | 上述字段加报价确认方式 |
| 退换货 | 退货退款 | 客户退回商品并要求退款 | 订单号、商品型号、退货原因、凭证附件 |
| 退换货 | 换货 | 客户要求更换同款或不同规格 | 订单号、原商品、目标商品、凭证附件 |
| 退换货 | 仅退款 | 不退回商品,仅退款项 | 订单号、退款原因、凭证附件 |
| 投诉 | 产品质量投诉 | 对产品性能、安全性不满 | 产品型号、事件经过、诉求、凭证 |
| 投诉 | 服务态度投诉 | 对客服、配送或门店人员不满 | 涉及人员或门店、事件时间、经过、诉求 |
| 投诉 | 重大投诉 | 涉及人身安全、媒体曝光或监管渠道 | 上述字段加外部渠道信息、上报对象 |
为每类工单设定SLA:响应、处理、暂停与升级怎么定
SLA由四个要素构成:响应时限指从工单创建到首次有效回复的时间;处理时限指从受理到给出解决方案或完成动作的时间;暂停规则规定哪些等待状态不计入时限;升级路径规定超时或触及条件后由谁接手。四个要素要一起定义,只写响应和处理时限,遇到等客户寄回商品、等配件到货这类情况就无法解释超时。
三类业务的时限差异来自业务本身的节奏。投诉涉及客户情绪和外部风险,首响应当最短,通常以小时计,重大投诉还需要在首响之外设置上报节点。维修的处理时限取决于是否上门、配件是否在库,远程支持可以按小时或工作日计,上门维修需要把预约等待和配件调拨单独设为暂停或分段计时。退换货的处理时限受物流周期影响,审核环节可以按小时计,退款到账则要按物流签收后的固定工作日计,不能把运输时间算进客服处理时限。
时限分档应依据优先级或影响范围,而不是客户身份。可以按“是否影响安全使用、是否影响多名客户、是否涉及外部渠道”设定高、中、低三档,同一子类型下不同优先级套用不同时限。按客户身份随意加急会让时限失去可预期性,也无法在报表中解释超时原因。如果确有重点客户约定,应写成独立的服务协议条款,在工单上标注协议编号,而不是临时口头加急。
计时口径需要提前约定。工作日历要明确每天的有效工作时长、周末是否计时、法定节假日如何处理;跨时区服务要统一以哪个时区为准,或者在系统中按受理团队所在时区计算。暂停条件要写清楚触发状态和恢复条件,例如“待客户提供凭证”暂停计时,客户上传凭证后恢复;“待配件到货”暂停计时,配件入库后恢复。暂停次数是否需要限制也应写明,避免工单长期挂起后失去跟踪。
| 类型/子类型 | 优先级 | 响应时限 | 处理时限 | 暂停条件 | 升级触发点 |
|---|---|---|---|---|---|
| 投诉-重大投诉 | 高 | 1小时内 | 24小时内给出处理方案 | 待外部调查结果 | 首响超时或涉及监管渠道,立即升级至投诉主管 |
| 投诉-服务态度 | 中 | 4个工作小时内 | 2个工作日内回复 | 待当事人说明 | 处理时限过半未回复,升级至客服主管 |
| 维修-保内上门 | 高 | 2个工作小时内 | 5个工作日内完成维修 | 待配件到货、待客户预约时间 | 预约后两次未上门,升级至服务网点负责人 |
| 维修-保内远程 | 中 | 4个工作小时内 | 2个工作日内解决或转上门 | 待客户操作反馈 | 远程两次未解决,转上门子类型 |
| 退换货-退货退款 | 中 | 4个工作小时内 | 审核1个工作日,签收后3个工作日退款 | 待客户寄回、待质检 | 审核超时升级至售后主管 |
| 退换货-换货 | 中 | 4个工作小时内 | 审核1个工作日,签收后2个工作日发出 | 待客户寄回、待库存确认 | 缺货超过3个工作日,升级并告知替代方案 |
把类型和SLA串成流转规则:状态、角色与交接节点
类型和时限只有落到状态流转上才能被计时和追责。通用状态链可以设为:新建→受理→处理中→待客户确认→关闭,另设退回、挂起、升级三个分支。新建到受理之间计响应时限,受理到待客户确认之间计处理时限,挂起期间暂停计时,升级后原时限继续计算但责任人变更。每个状态切换都要有明确的触发动作和操作人,系统才能记录时间点。
三类工单在通用状态链上各有特殊节点。维修类在“处理中”之后增加派工和验收:派工记录服务人员、预约时间、上门结果,验收以客户签字或系统确认作为完成标志。退换货类在“处理中”内拆出审核和物流两个节点:审核确认是否符合退换条件,物流节点记录寄回单号、签收时间和退款或换货发出时间。投诉类在“处理中”内拆出调查和回复:调查确认事实与责任,回复记录回复内容、回复方式和客户是否接受。
角色分工要按节点落到具体岗位。客服负责受理、分类、补齐必填字段和首次回复;技术支持负责维修类的故障判断与远程指导;仓储物流负责退换货的签收、质检和发出;投诉专员负责投诉调查与回复;主管负责超时升级、例外审批和重大投诉上报。每个交接节点都要有交接物,例如派工单、质检结论、调查记录,交接物缺失时下一节点不应开始计时。
| 节点 | 责任角色 | 交接物 | 计时规则 |
|---|---|---|---|
| 新建→受理 | 客服 | 类型、子类型、必填字段完整 | 计响应时限 |
| 受理→处理中(维修派工) | 技术支持/服务网点 | 派工单、预约时间 | 计处理时限,待预约期间可挂起 |
| 处理中(退换货审核) | 售后审核岗 | 审核结论、凭证核对记录 | 计审核时限 |
| 处理中(退换货物流) | 仓储物流 | 签收记录、质检结论、发出单号 | 签收后起算退款或发出时限 |
| 处理中(投诉调查) | 投诉专员 | 调查记录、责任认定 | 计处理时限,待外部结果可挂起 |
| 待客户确认→关闭 | 客服 | 客户确认记录或超时自动关闭规则 | 确认等待期可设固定天数 |
| 升级 | 主管 | 升级原因、处理意见 | 原时限继续计算,责任人变更留痕 |
这些规则在平台上落地时,需要工单类型可区分、字段可按类型配置、状态流转可调整、优先级可评估。ONES Desk 支持自定义工单属性与工单内容以适配不同收集场景,工作流可灵活调整,并支持评估和定义工单优先级;工单处理中可直接与用户对话,也可关联其他工作项,便于把需要研发介入的维修或质量投诉转交对应团队。SLA的计时、暂停与超时升级是否按类型分别配置,需在实施时结合官方文档和实际配置确认。
示例:一张完整的售后工单类型与SLA设计表
下面用三条完整记录展示三类工单如何落到同一张设计表上。示例中的时限为演示设定,实际取值应结合业务承诺和历史数据调整。
| 字段 | 维修-保内上门 | 退换货-七天无理由退货 | 投诉-服务态度 |
|---|---|---|---|
| 一级/二级类型 | 维修/保内上门维修 | 退换货/退货退款 | 投诉/服务态度投诉 |
| 触发条件 | 保内产品故障,需现场处理 | 签收后七天内,商品完好 | 客户对服务人员态度不满 |
| 优先级 | 高 | 中 | 中,涉及多人或外部渠道升为高 |
| 必填字段 | 型号、保修状态、故障描述、地址、预约时段 | 订单号、商品、退货原因、凭证、寄回单号 | 涉及人员、事件时间、经过、诉求 |
| 响应时限 | 2个工作小时 | 4个工作小时 | 4个工作小时 |
| 处理时限 | 5个工作日完成维修 | 审核1个工作日,签收后3个工作日退款 | 2个工作日回复 |
| 暂停条件 | 待配件、待客户预约 | 待寄回、待质检 | 待当事人说明 |
| 流转节点 | 受理→派工→上门→验收→关闭 | 受理→审核→签收质检→退款→关闭 | 受理→调查→回复→确认→关闭 |
| 责任角色 | 客服、技术支持、服务网点 | 客服、售后审核、仓储物流 | 客服、投诉专员、客服主管 |
| 完成标志 | 客户验收签字或系统确认 | 退款到账记录 | 客户接受回复或回复送达记录 |
| 升级条件 | 两次未按约上门 | 审核超时或缺货超3个工作日 | 处理时限过半未回复 |
三条记录共用同一套字段结构,差异体现在子类型、时限取值和特殊节点上。这样设计后,客服在受理时只需选择子类型,系统即可带出必填字段和对应时限;主管查看报表时,可以按一级类型看总量,按二级类型看超时分布,定位到底是维修派工慢、退换货审核积压还是投诉回复不及时。
上线前的完成检查:口径、试运行与校准
设计表完成后,先做口径检查再试运行。类型检查看互斥和穷尽:同一问题是否可能同时落入两个子类型,是否存在常见售后场景找不到对应类型。SLA检查看时限依据:每条时限是否有业务承诺、合同条款或历史处理数据支撑,没有依据的时限先标注为待验证,不要直接对外承诺。字段检查看必填项是否真的影响分派和计时,避免为了完整而收集大量无人使用的信息。
试运行选择一条业务线或一个区域,运行两到四周,观察四个指标:超时率按类型和子类型分别统计;升级率反映时限是否过紧或分派是否准确;一次解决率反映受理时字段是否齐全;暂停占比反映挂起规则是否被滥用。根据数据校准时限和暂停条件,例如某子类型超时集中在等配件环节,就应把配件等待设为独立暂停状态,而不是整体放宽处理时限。
权限和报表口径也要在上线前核对。客服、技术支持、仓储物流、投诉专员和主管的可见范围与操作权限应与职责一致;报表中的类型编码、时限口径、暂停是否计入统计要在同一版本中固定。上线前检查清单如下,每项设定通过标准、责任人和阻断条件,未通过的项目在全面推行前完成整改。
| 检查项 | 通过标准 | 责任人 | 阻断条件 |
|---|---|---|---|
| 类型互斥且穷尽 | 抽样历史工单可唯一归类,常见场景无遗漏 | 售后负责人 | 存在无法归类的场景 |
| SLA时限有依据 | 每条时限对应承诺、合同或历史数据 | 客服主管 | 关键子类型时限无依据且未标注待验证 |
| 必填字段可支撑分派 | 受理人凭字段即可判断类型和责任人 | 客服主管 | 关键字段缺失导致反复追问 |
| 状态与计时规则一致 | 每个状态切换有触发动作和计时起止 | 系统管理员 | 挂起或升级状态无法记录时间 |
| 角色权限匹配 | 各角色可见和可操作范围与职责一致 | 系统管理员 | 越权操作或关键角色无法处理 |
| 试运行指标达标 | 超时率、升级率、一次解决率在设定阈值内 | 售后负责人 | 超时率持续高于阈值且原因未定位 |
| 报表口径固定 | 类型编码、时限、暂停统计口径版本一致 | 数据负责人 | 同一指标出现两种统计结果 |
评审时点建议设在试运行结束和全面推行前各一次,由售后负责人组织,客服、技术支持、仓储物流和系统管理员参加。评审输出包括时限调整记录、字段增删记录和遗留问题清单,遗留问题明确责任人和完成时间后再进入全面推行。
常见问题
维修、退换货、投诉三类工单的SLA时限应该定多长?
时限没有统一标准值,取值依据是业务承诺、合同条款和历史处理数据。可以先用现有工单的处理时间分布作为基线,再结合对外承诺收紧。三类业务的节奏不同:投诉首响通常以小时计,重大投诉还要加上报节点;维修远程支持按小时或工作日计,上门维修要把预约等待和配件调拨单独处理;退换货的审核按小时计,退款到账按签收后的固定工作日计,运输时间不计入客服处理时限。示例表中的数值是演示设定,直接套用前应先用试运行数据校准。
客户一直不提供凭证或迟迟不寄回商品,工单超时怎么算?
这类等待应通过暂停规则处理,而不是放宽整体处理时限。做法是为“待客户提供凭证”“待客户寄回”设置独立的挂起状态,进入该状态暂停计时,客户上传凭证或物流签收后恢复计时。同时要写明暂停次数或最长暂停天数的限制,避免工单长期挂起失去跟踪;超过限制仍未推进的,转入升级或按规则关闭并留痕。这样超时统计才能区分是内部处理慢还是客户侧等待。
同一张工单既涉及产品质量又涉及服务态度,类型怎么归?
建议按客户的核心诉求确定一级类型,把另一项作为关联信息记录,而不是拆成两张互不相关的工单。如果客户主要要求解决问题,归入维修或退换货,在字段中标注涉及服务态度并通知投诉专员跟进;如果客户主要要求对服务人员追责,归入投诉,调查中发现的 product 质量问题另开维修或质量工单并关联原单。上线前的类型检查要用历史工单抽样验证这种归类规则能否唯一落位,减少受理时的争议。
工单类型和SLA设计好后,在工单平台上落地要注意什么?
落地时重点核对四件事:类型能否按不同表单配置必填字段,状态流转能否增加派工、审核、调查等特殊节点,优先级能否作为时限分档的依据,以及每个状态切换能否记录时间点用于计时。ONES Desk 支持自定义工单属性与工单内容以适配不同收集场景,工作流可灵活调整,并支持评估和定义工单优先级;工单处理中可直接与用户对话,也可关联其他工作项,便于把需要研发介入的维修或质量投诉转交对应团队。SLA的计时、暂停与超时升级是否按类型分别配置,需在实施时结合官方文档和实际配置确认。
试运行多久、看哪些指标才能判断SLA设计是否合理?
建议选择一条业务线或一个区域运行两到四周,样本量要能覆盖三类工单的常见子类型。重点看四个指标:按子类型统计的超时率,判断时限是否过紧或分派是否准确;升级率,反映时限设置和受理质量;一次解决率,反映必填字段是否齐全;暂停占比,反映挂起规则是否被滥用。校准时针对具体环节调整,例如超时集中在等配件,就把配件等待设为独立暂停状态,而不是整体放宽处理时限。指标持续高于阈值且原因未定位的,暂不全面推行。



