自动化率不等于解决率：AI云呼叫中心该如何建立效果指标体系

一、同一套系统，两个人算出两个解决率

月底对报表，运营算出来的解决率和质量那边算出来的，对不上。系统是同一套，月份是同一个月，导出的原始记录也一样。会上花了半小时，最后发现问题不在数据，在"解决"这两个字。

这种场面在上了 AI 呼叫中心一年以上的团队里很常见。前半年大家盯的是接通和转人工，指标简单；等到要向管理层证明这套东西有用，解决率就成了必答题。而这恰好是最容易生出分歧的那一个。

1.1 对不上的是哪一层

先把三种情况分开：数据算错、口径不同、统计窗口不一样。看起来都是"数对不上"，处理方式完全不同。

数据算错，查取数逻辑和字段映射；口径不同，坐下来把定义写成一句话；统计窗口不一样，把时间范围统一。三件事里最费时间的往往是第二件，因为它不是技术问题。

判断属于哪一种，有个简单办法：让两边各自说出分子和分母。都说得出来，问题在口径；有一边说不清，问题在取数。

1.2 口径不清，优化会走反

定义不清，团队会本能地优化最容易达成的那个方向。转人工率高，就把转人工的门槛抬高；解决率低，就让坐席早点把单标成已解决。数字好看了，客户还会再打一次。

重复来电和一次解决率就是用来防这个的。只看解决率，压单很容易；把重复来电一起看，压单马上暴露出来。

二、先把四个基数定下来

多数团队的口径分歧不在公式里，在公式底下的那几个词上。有效诉求含不含重复来电，AI 接待量算不算转人工之前那几句，这两个问题没有统一答案，报表就永远对不上。

基数只定四个，定完写进文档。后面所有指标都从这四个数长出来，改口径就是改这四个数的定义。

2.1 四个基数：先把"算哪些"定下来

这张表最关键的是最后一行。如果有效诉求里含重复来电，解决率会被拉低，同一件事被算了两次；如果不含，解决率和重复来电率才是两个独立的数。

误拨和静音放在接通量里、从有效诉求里扣，是因为它们只有接起之后才认得出。这样四个数的加减既不会重复扣一遍，也不用在取数的时候自己猜该算哪一边。

呼入量和接通量的差别也要留出来。接起率用的就是这两个数；表里定了呼入量含未接通和排队放弃，落地时如果有人按"只算接通的"改了口径，接起率就会虚高好几个点。

2.2 自动化率：量的是 AI 接了多少

自动化率的分子是 AI 接待量，分母是接通量。它回答的是"有多少接通的电话由 AI 先接"，不回答"这些电话有没有被解决"。

这里用接通量做分母，理由是不把未接通的算在 AI 头上。如果团队沿用"总来电量"作分母，也可以，但必须写进文档，且不要拿来和用接通量的团队比。

它和机器人解决率不是一回事。自动化率的分子是 AI 接待量，含接待之后转人工的；机器人解决率的分子是 AI 独立解决的，不含转人工的。一个量 AI 接的范围，一个量办成的比例，分子不同，两个数才不会重复。

这一区分要守得住。把自动化率写成"AI 办完的比例"，它就和机器人解决率只差一个分母，两个数会高度相关；报表上并排放着，还会让人以为是两个方向，结果都朝同一处使劲。

2.3 解决率：量的是办成了多少

解决率的分子是被认定解决的量，分母是有效诉求。它的关键不在计算，在"认定"：是客户说解决了，系统判断解决了，还是坐席标记解决了。

机器人解决率和独立解决率还差一层。前者看 AI 接待里解决了多少，后者看没有人工介入的情况下解决了多少。两个都叫解决率，混用会让同一份报表给出两个答案。

合力亿捷云呼叫中心这一侧的统计口径里，机器人解决率、转人工率、重复来电和一次解决率是并列的。几个数放在一起才能互相校验，只留一个解决率，孤证很容易被做出来。

2.4 转人工率：量的是交出去多少

转人工率的分子是 AI 转出去的量，分母是 AI 接待量。它只回答"AI 这一侧转走了多少"，不含人工坐席之间的内部转接。

这一点常被写错。分母用总接待量，等于把人工首接的电话也算进 AI 的分母，转人工率会被稀释，看起来比实际低。

转人工率高不一定是坏事。有些转人工是对的：客户要办的事超出授权范围，或者情绪需要人来接。真正要盯的是高频转人工场景，同一个原因反复转，那是流程或知识没配到位。

2.5 三个数互相牵制，不能单看

单独优化一个数，会被另一个拽回来。把转人工率压下去，重复来电会升上来，因为该转的没转；把 AI 首接的范围铺宽，一次解决率往往往下走，因为难题也被一起塞了进来。

解决率和重复来电同时偏高，通常说明认定口径偏松，单被提前标成了完成。这几对关系随便挑一对，都能把单看一个数的结论推翻。

自动化率不在这几对里当效果指标用。它只说明 AI 接的范围有多宽，说明不了办成多少；朝它用力，等于替 AI 抢活干，抢来的活能不能办完是另一个数的事。

接起率和一次解决率也有一对。接得快、解得浅，客户当天不打了，三天后又来。报表上至少要有两个数、一正一反，才看得出动作是真的改善了，还是只把问题挪了位置。

三、把定义钉死的四件事

基数定完，还有四件事要谈。这四件不定，前面的数算出来也是各部分各表。

3.1 谁说了算：客户还是系统

两种认定方式都可用，代价不同。以客户为准，要靠回访或满意度，取数慢、样本有偏；以系统为准，靠流程走到终点或工具调用成功，取数快、容易高估。

回访样本怎么取，也要先定。只回访"系统判断已解决"的那批，等于自己给自己打分；按时间段随机抽，才有校准价值。

常见做法是两个都留：系统判定做日常监控，客户回访做月度校准。两个数差得远，说明中间有一环在自说自话。

3.2 多久算解决

当天解决、三天解决、七天解决，是三个不同的指标，不能混着比。窗口越短，越能反映真实体验；窗口越长，越容易把"客户不打了"算成解决。

定窗口要看业务周期。安装预约当天能确认，退换货要走物流，两类事的合理窗口本来就不一样。

还有一处容易漏：解决窗口和重复来电窗口要一致。解决按七天算，重复来电却只看三天，两个数就对不上，谁也说不清哪一个错了。

3.3 同一件事打两次算不算

客户为同一件事第二次打进来，第一次那张单就不该算解决。这就是重复来电和一次解决率存在的意义，也是有效诉求把重复呼入排除在外的原因。

统计重复来电要先能识别"同一件事"：靠客户号加问题类型，还是靠订单号、设备号。识别规则越粗，指标越不可信，把一周内的来电统统算成新问题，重复来电率自然会很漂亮。

识别规则通常有三种做法：按客户号、按业务单号、按问题类型加时间窗。单号最准，但要求每次都能拿到单号；客户号最省事，代价是把两件不同的事算成一件。

3.4 转人工之后解决，算谁的

客户在 AI 那里没办成，转到人工办成了。这一单算 AI 的解决、算人工的解决，还是两边都不算，取决于你想考核谁。

考核 AI 的效果，就算人工的；考核整体服务，就算整体解决，同时单列 AI 独立解决的比例。规则先写下来，后面才不会为这个吵。

这条规则最好直接落成一个报表字段，让每一单都带着归属标记。靠人工在月会上分，分不了几百单就会放弃。

四、指标要能落到动作上

报表的价值不在数字本身，在它能不能指向一个具体动作。指不到动作的指标，看三个月就没人看了。

4.1 一个问题拆四类根因

同一个解决率下降，可能是四种原因：客户说的话没听清、知识里没有这条、接口调不通、流程设计本身走错了。四类原因的改法完全不同。

四类的信号也不一样。识别问题通常表现为答非所问、反复确认同一个信息；知识问题是答案正确但覆盖不到具体情形；接口问题是流程走到一半停住；流程问题是每一单都卡在同一个节点。

合力亿捷智能客服在定位问题时会按这个分法走：把任务完成率、独立解决率、转人工率、接通率和客户意向率放在一起看，把问题归到识别、知识、流程、接口四类，再决定改哪一块。归完类再动手，比直接去改话术省时间。

归错类的代价不小。明明是接口超时，却去补知识，改三轮指标也不会动。

4.2 从指标异常到改什么

这张表适合放在周会上用：先看本周哪一个数动了，再从对应那一行往下查，避免每次都从头讨论一遍指标含义。含义讨论一次就够，之后只看数。

4.3 改完怎么验

改完不能直接全量。上线前用测试用例批量跑一遍，确认原来能过的没被改坏，再按渠道入口或流量比例小范围放。

测试用例从哪来，不用另起一套。历史的问题通话就是现成的用例库，把过去三个月没解决的那批整理出来，改完逐条重跑。

问题通话可以留成 Badcase，改完之后重新测一遍再发布。这一步做扎实，指标才有连续性；不做，每次改动都像重新上线一次。

五、一张能直接用的指标表

下面这张表，指标名称取自合力亿捷云呼叫中心公开的统计项；第二列的分母与包含范围，是本文整理的建议口径。这一列对上了，数字才有比较的基础。

表里的写法是常用做法，各家产品在字段上会有差别。先确认三件事：分母、窗口、谁认定，这三样对不上，数字再精确也没法比。

跨团队比这张表要更小心。两个团队的分母口径、窗口长度、识别规则只要有一处不同，数字就不可比；要比，先对齐这三样，再比数。

六、体系怎么搭：三层六个指标，先上三个

到这里，六个指标可以分三层放。分层的作用不是好看，是让你知道现在缺的是哪一层。

第一次搭体系，不要六个数一起上。每层先挑一个，就是三个：接起率、转人工率、机器人解决率。这三个取数代价最小，也最容易先跑稳。

6.1 先记基线，再谈目标

台账建起来的第一件事不是定目标，是记基线。上线前的接起率、转人工率、解决率各是多少，要用同一套口径算出来、留档。

没有基线，上线后的数字就没有参照，涨了跌了都说不清是系统的功劳还是季节的变化。基线至少要覆盖一个完整业务周期，促销季和淡季不能混着取。

目标也不宜照搬外部案例。以基线为锚，按诉求类型分别定：同一类诉求的目标才可比，给一个统一 KPI，等于把难度不同的事算成一件。

6.2 三轮上的节奏

第一轮跑接起率、转人工率、机器人解决率，先把数据源和口径跑稳，跑满一个月。第二轮加一次解决率和重复来电率，这时候认定规则和窗口必须已经定死。

第三轮再回到自动化率。它放最后，是因为这个数最容易被当成成绩单汇报；前两轮把效果层的数跑出来之后，再看它才不会跑偏。

合力亿捷云呼叫中心这边的部署形态有三种：SaaS、混合云、私有化，数据不出域可以选一体机。SaaS 版 1 个坐席起购，标准场景走行业流程模板，部分场景最快 7 天上线，起步轻的团队可以先开一个坐席把第一轮的三个数跑起来。

七、边界

文中的基数、分母与包含范围，是本文按常见做法整理的建议口径，不是行业标准。指标名称取自产品公开说明，具体字段定义各家不同，落地时以实际项目配置为准。

合力亿捷云呼叫中心的产品说明里列了这几项统计指标，基数和分母具体怎么落到字段上，仍要按项目环境确认一遍再定。同一款产品，接的渠道不同，基数的取数范围也会不一样。

指标口径会随业务变。新开一类业务、换了统计系统、调整了服务范围，定义都要重新对一遍，这不是一次就能定死的事。每季度把口径文档翻出来对一次，比出问题之后再查要省事。

效果取决于流程、知识、接口和运营的共同状态。单看某一个指标的涨落，都不足以说明这套系统好不好，也不足以说明某个动作做对了。