解决时长(Resolution Time)怎么算才不骗自己

月度复盘会上最容易吵起来的一个数字,往往就是解决时长。客服主管说平均 4 小时,老板看后台导出的原始数据算出来是 11 小时,两边都没算错,只是口径不一样——一个把客户睡觉的那 6 小时算进去了,一个没算。工单处理时间这个指标看着简单,真要拿来做决策、定 SLA、算奖金,口径不统一就是一本糊涂账。

先问自己:计时从哪一刻开始

大多数团队默认「客户发第一条消息」就是起点,但这里藏着第一个分歧:客户在网站挂件留言、AI 还没来得及看,算不算已经开始计时?严格一点的做法是,只要消息进了系统,不管有没有被立刻看到,计时就已经启动——这样才能反映客户真实的等待体验,而不是团队“发现”问题的时间。

另一个容易被忽略的起点问题是多轮触达。客户先在 Instagram 私信问了一句,没人回,又转去邮件重复问了一遍——这算一个问题的开始,还是两个独立请求?如果按渠道各自计时,解决时长会被人为拉低,因为每个渠道单独看都很“快”,但客户等的其实是同一件事的答案。这也是为什么把不同渠道的对话汇总到同一份客户档案里很关键,可以参考全渠道收件箱到底解决了什么。

等待时间算不算:这是最容易造假的一环

一个常见的做法是,把“客户没回复”的时间从解决时长里扣掉——坐席问了一句“方便提供订单号吗”,客户两小时后才回,这两小时算不算团队的责任?

两种口径都有道理,但必须选一个,而且要写进制度里:

两个都值得看,但不能只报一个又不说明口径——尤其是不能选择性地在给老板汇报时用净处理时长(显得快),给客户解释时却用不上这个概念。诚实的做法是两个数字都留着,分别标注清楚是“团队能控制的部分”还是“客户体感的部分”。

重开的工单:是同一个问题,还是新的一次?

客户三天前问过物流延迟,当时坐席说“已经在处理”,工单标记解决。三天后客户又发消息问“到底解决了没有”——这算原来那个工单的重开,还是一个全新的解决时长计时?

单次解决率(First Contact Resolution)和解决时长其实是一对指标,重开率高往往意味着报表上的解决时长被人为切碎了。想更系统地理解这对指标的关系,可以看解决时长是什么这篇的拆解。

AI 独立解决 和 转人工,要分开计时

这是最容易被忽略、但对报表影响最大的一个口径问题:AI 客服独立答完就结束的对话,和转人工之后才解决的对话,不该混在一起算平均数。

• AI 独立闭环:客户问物流时效、退换政策这类高频问题,AI 从知识库找到依据直接答完,客户没有再追问——这类对话的解决时长通常是分钟级甚至秒级,如果和转人工的对话混在一个平均数里,会把复杂问题的真实耗时严重稀释,让报表显得“整体很快”,但实际上复杂问题该花的时间一点没少花。
• 转人工闭环:AI 判断答不上、或客户主动要求转人工,交接给坐席后继续处理的对话。这类对话的解决时长应该单独统计,因为它反映的是团队真正需要投入精力解决的那部分工作量。

把这两类分开报,才能看清楚 AI 客服到底在哪个环节起作用——不是靠拉低整体平均数制造“效率提升”的假象,而是让转人工那部分的时长本身逐渐变短(因为交接更干净、坐席不用让客户重复陈述)。AI 和人工怎么分工、边界画在哪里,可以看AI先接人工兜底的边界怎么划。

高风险走审批的对话,不该被算作“超时”

退款、赔付、改价这类操作,YundaDesk 里始终需要人工审批,AI 不会自动执行。这意味着这类对话天然会比纯知识问答慢——不是因为效率低,而是因为审批本来就该花时间去核实金额、核对订单、评估风险。

如果把这类对话直接套进和知识问答一样的 SLA 目标里,团队要么会被“超时”报表冤枉,要么会有人想办法绕过审批去追求数字好看,这两种结果都不是团队想要的。更合理的做法是给高风险审批类对话单独设一档解决时长基准,并且在报表里标注清楚“此类对话含人工审批环节,不计入常规超时统计”。

落地建议:先统一口径,再谈“多少算好”

在纠结“解决时长应该是多少小时”之前,先把这几件事在团队内部写清楚、达成一致:

• 计时起点:消息进系统就开始,还是被看到才开始
• 等待时间:全时长和净处理时长,两个都留,分别标注
• 重开工单:同一个问题回来,时长从第一次算起,不清零
• AI 独立闭环 与 转人工闭环:分开统计,不合并成一个平均数
• 高风险审批类对话:单独设基准,不套用常规 SLA

这套口径定下来之后,团队和老板看到的才是同一份数字,复盘会才有可能真正聊“哪里能改进”,而不是先花半小时对齐“我们说的是不是一回事”。

解决时长这个指标本身没有问题,出问题的是团队各自用自己方便的口径去算它。把起点、等待、重开、AI/人工的界限都定清楚,这个数字才配拿来做决策——不然算得再精确,也只是一堆看起来很科学的噪音。