YundaDesk采购会上最容易让人心动的一句话，大概就是「我们的 AI 客服独立解决率 95%」。听起来像是坐席可以直接砍掉大半。但你只要多问一句「怎么算的」，十有八九对方会顿一下。因为这个数字太容易被算法「优化」出来：把 AI 接住了算解决，把一次回复算闭环，把客户后来追问的成本藏到统计窗口之外。
先说结论：我们不承诺固定解决率
YundaDesk 不会在合同里写「AI 独立解决率不低于 XX%」。不是藏着掖着，是因为这个数字取决于你的知识库质量、你的产品复杂度、你的客户群体。任何在签合同前给你一个通用承诺的人，要么没打算认真测，要么就是拿一套讨巧的算法给你看着舒服。真正该谈的不是「承诺多少」，而是「怎么测、能不能一直变好、每一条能不能查」。
先把口径说清：Handled、Resolved、Stayed Resolved
很多「自动解决率」好看的地方，不在 AI 有多强，而在口径混在了一起。至少要把三层拆开：
| 口径 | 中文解释 | 能说明什么 | 不能说明什么 |
|---|---|---|---|
| Handled | AI 接住并给出回复 | AI 覆盖了多少会话入口 | 客户问题是否真的解决 |
| Resolved | 没转人工、没负面反馈、会话当下闭环 | AI 可能独立完成了一次服务 | 客户之后是否又回来追问 |
| Stayed Resolved | 在 24-72 小时观察窗口内没有同一问题重开 | 这次服务大概率真的结束了 | 不代表所有复杂问题都适合自动化 |
更诚实的独立解决率，应该接近 Stayed Resolved，而不是 Handled。如果一个供应商把「AI 回复过」直接叫「AI 已解决」，那其实是在汇报接待量，不是在汇报解决质量。自动化率不是客户体验本身，必须用客户是否回来追问、是否要求人工、是否留下负面反馈来校准。
从接住会话到真正解决的口径漏斗
可直接套用的公式
先定观察窗口，再定分子分母。下面这组口径适合用在月度看板、试点复盘或供应商对比里：
| 指标 | 建议公式 | 解读 |
|---|---|---|
| AI handled rate | AI 已回复会话数 / 可由 AI 接待的会话数 | 衡量 AI 覆盖率，不等于解决率。 |
| AI first-contact resolution | AI 首次回复后未转人工且未追加坐席回复的会话数 / AI 已回复会话数 | 衡量第一轮服务是否足够完整。 |
| True AI resolution rate | 观察窗口内未转人工、未负评、未同一问题重开的 AI 会话数 / AI 已回复会话数 | 最接近「AI 独立解决」的主指标。 |
| Deflection rate | 原本可能进入人工队列但被 AI 闭环的会话数 / 原本可能进入人工队列的会话数 | 衡量 AI 减少人工负载的程度。 |
| Handoff rate | AI 回复后转人工的会话数 / AI 已回复会话数 | 越高，说明知识、权限或置信度边界需要调整。 |
| 72h re-contact rate | 72 小时内同一问题再次联系的会话数 / AI 标记已解决会话数 | 用来校准「看似解决」的水分。 |
| AI-resolved CSAT | AI 标记已解决会话中的满意评价数 / AI 标记已解决且有评价的会话数 | 衡量被 AI 解决的体验质量。 |
| Knowledge gap rate | 因知识缺失、政策不清或答案被纠正产生学习建议的会话数 / AI 已回复会话数 | 衡量知识库还欠多少债。 |
这里最关键的是：不要只看一个 headline percentage。Handled rate 可以告诉你 AI 有没有接住流量，handoff rate 和 re-contact rate 告诉你接住之后有没有掉，AI-resolved CSAT 告诉你客户是否认可这个结果，knowledge gap rate 告诉你下一轮该补哪里。
什么才算「真正解决」
一个客户问题，只有满足这几条，才算 AI 真正独立解决了：
- 客户没有在之后一段时间内（比如 24-72 小时）就同一问题重新发起对话
- 对话没有被坐席主动接管或补充回答
- 客户没有留下负面反馈或要求转人工的表态
- 问题本身有明确边界（比如查物流、问退换货政策），不是需要人工判断的复杂个案
反过来说，如果客户问完之后又发了一条「还是不太懂，能帮我看看具体订单吗」，哪怕 AI 之前那条回复看起来对答如流，这轮对话也不该算进「独立解决」里。解决率衡量的是客户体验的终点，不是 AI 有没有说话。
三种常见的注水手法
这三招单独看都不算「造假」，但叠在一起，能把一个真实解决率 60% 的系统包装成「95% 自动解决」。所以拿到一个解决率数字时，先问对方分子分母怎么定义、观察窗口多长、有没有剔除重复问题。
诚实测量该看的四个维度
与其争论一个笼统的百分比，不如把它拆成四个可以分别核实的维度：
| 维度 | 该问的问题 |
|---|---|
| 覆盖范围 | 这个解决率是全部会话的，还是只统计了某几个简单场景？ |
| 观察窗口 | 客户多久没再回来，才算「没有重开」？ |
| 复核路径 | 有没有人工抽样复核过 AI 判定为「已解决」的对话？ |
| 趋势而非快照 | 这个数字是上线当天的，还是过去一个季度的曲线？ |
其中最容易被忽略但最重要的是最后一条：单次快照没有意义，变化的方向才有意义。 一个从 55% 慢慢爬到 72% 的诚实曲线，比一个凭空冒出来的 95% 更值得信任，也更能反映你的知识库和团队投入是不是真的在起作用。
诚实解决率看趋势，不看单点宣传数
为什么受控学习能让这个数字「真实」提升
YundaDesk 招牌的「越用越聪明」，本质上就是在为解决率的真实提升铺路，而不是靠调整统计口径。当 AI 答不上、坐席补答、或者坐席点了「纠正 AI」，系统会把这次经验生成一条待确认的学习建议，进老板的评审台。只有你确认采纳，它才会沉淀为技能或知识，下一次同类问题才有可能被 AI 独立接住。
这意味着解决率的提升路径是可解释的：上个月 AI 答不上「海外仓退货怎么走」，坐席补了一次，你采纳了这条学习建议，这个月同类问题的独立解决率理论上应该往上走一截，而且你能拿这条具体的学习记录去对照验证，不是一句「模型升级了」就糊弄过去。想了解这套闭环具体怎么运作，可以看 越用越聪明是怎么做到的。
可追溯：每一条「已解决」都能被翻出来查
诚实测量的另一半，是可追溯性。如果一个供应商没法让你把「解决率」拆回到具体的一条条对话记录，这个数字基本没法核实，也没法用来改进任何东西。
在 YundaDesk 的共享工作台里，每一次 AI 独立回复、每一次转人工、每一次坐席接管补答，都是完整留痕的对话记录，可以按时间、渠道、问题类型筛出来复核。这也是为什么高风险场景（退款、赔付、改价）从来不进「AI 独立解决」的统计：这些永远走人工审批，AI 不会自动执行，更不该被算进「自动解决」的功劳簿。想理解这条边界具体划在哪，可以看 AI 先接、人工兜底怎么分工。
落地自查清单
如果你现在就想核对自己团队（或正在考察的供应商）的解决率是不是真实，可以对着这份清单过一遍：
- 「已解决」的定义里，是否包含客户 24-72 小时内没有重开同一问题
- 分母是否包含全部渠道、全部问题类型，而不是只挑简单场景
- 是否有人工抽样复核过被标记为「已解决」的对话
- 是否能同时看到 handled rate、handoff rate、72h re-contact rate 和 true AI resolution rate
- 退款、赔付、改价等高风险场景是否被排除在「AI 独立解决」统计之外
- 学习建议采纳后，能否对照验证对应问题类型的解决率变化
把这几条过一遍，比记住任何一个「行业平均解决率」都管用。
一个诚实的解决率，应该经得起你抽十条对话去对照。如果供应商不愿意让你抽查，这个数字大概率不值得信。