客户放弃了，你的看板却把它算成成功。

设想一位客户请客服机器人修改收货地址。机器人解释了设置入口在哪里。客户却在手机上找不到，关掉聊天窗口，决定明天再处理。

你的报表上又多了一次“已解决”。

这是一个假设的失败场景，并非对某家公司客户经历的描述。但它揭示了一个比聊天机器人的语气更值得采购方关注的问题：你的系统凭什么认定事情已经办完？

放弃继续沟通的客户，看起来可能与已经得到帮助的客户非常相似。如果你的指标分不清两者，现在庆祝还太早。

销售承诺已经从回答问题转向完成任务

10月7日，Fin 发布了 Fin 4，内容包括客户智能体能力升级、运营自动化和人工审核。这是供应商对产品发布的介绍，并不是我们的测试结论。参见 Fin 4 发布公告。

客服软件变得更有能力，当然值得欢迎。能够安全解决账户问题的系统，比只能解释解决方法的系统有用得多。这也让“成功”的定义更加重要。给出回答、完成修改和让客户满意彼此相关，却是不同的衡量对象。

看看“已解决”背后的定义

Fin 的公开规则区分“确认解决”和“推定解决”：得到回答后，客户可能确认满意，也可能未再求助就离开。规则还说明，客户不回答澄清问题不计为解决；如果客户回到同一对话继续求助，原来的解决记录会被扣除。参见 Fin 的结果定义。

这些限定条件很重要。把它描述成对所有被放弃的聊天收费，并不公平。推定可以是有用的报告信号；如果要求每个人都说一句谢谢，也会漏掉很多成功的互动。

问题在于，把这个信号当成它无法证明的更强结论。想知道地址是否改好了，就检查地址记录。想知道客户是否觉得得到帮助，沉默仍然意味着不确定。应该让这种不确定性保留在报表里。

人工客服也一样。关闭工单是一个管理动作。你仍然需要知道究竟完成了什么。

百分比更好看，完成的工作可能没变

Fin 还公开了一项报告口径调整：把没有机会作答的对话移出解决率的分母。这会提高解决率，但不会改变解决数量、自动化率或计费。参见 Fin 性能指标更新说明。

这种分析有合理目的：衡量系统有机会尝试的工作。采购方需要保留这些区别。指标定义改变后，百分比提高了，本身并不能证明更多客户获得了帮助。

比较两个月或两家供应商之前，先写清哪些对话纳入计算、哪些被排除，以及什么事件才算成功。否则，一整场会议可能都在为算术鼓掌。

沿着一条请求检查到底

回到前面修改地址的假设。对于符合条件的订单，我会要求实施团队在测试账户里演示完整流程：

1. 确认请求者身份。 核实此人是否有权修改这笔订单。知道订单号，并不自动意味着拥有操作权限。
2. 检查是否还允许修改。 已经发货的订单，与等待发货的订单，需要不同的处理方式。
3. 执行获准的修改，再读取结果。 权威订单记录中应当出现目标地址。聊天里一句自信的回复不能代替这条记录。
4. 如实处理不确定状态。 如果更新超时，重试前先确认结果。告诉客户哪些信息已知，哪些仍需检查。
5. 保留可用的人工交接。 需要人工介入时，把请求和相关上下文交给有能力处理的人，并明确告诉客户下一步是什么。

测试中还应包含不允许修改的订单，以及更新失败的情况。系统正确拒绝不安全的修改，并让合适的人介入，即使没有自动完成修改，也可能很好地服务了客户。

获得这种价值，不需要给 AI 无限权限。先定义允许的操作、验证方式和审批边界。语言模型可以帮助理解请求，但应用程序仍然必须执行规则。

看看那些突然安静下来的对话

对于已经上线的系统，可以先审查一批工作量可控的样本。涵盖推定解决、确认解决和人工交接，并分布在常见请求类型中。把第一次审查当作诊断，而不是对整个服务作出统计上精确的判断。

逐个记录客户想做什么、系统说了什么、实际改变了什么，以及还有哪些未知。如果有正当方式关联记录，就检查同一个问题是否通过其他渠道再次出现。一封新邮件可能对应一个老问题。

分别保留这些报告类别：已提供回答、操作已验证、客户已确认、人工交接、未解决和未知。它们可能重叠，但这比把每次互动都塞进同一个绿色方框更有信息价值。

然后修复你发现的原因。可能机器人没有执行权限，可能帮助文章指向了错误页面，也可能交接落进了无人负责的收件箱。换一个更会说话的模型，并不会自动解决这些问题。

值得付费完成的工作

我希望 AI 客服配得上看板上显示的信心。这需要连接业务系统、合理配置权限、测试异常恢复，并让指标对应客户真正要完成的任务。措辞更漂亮只是其中一部分。

如果客服指标看起来很健康，客户却反复带着同一个问题回来，告诉 Rosecraft 你使用的平台，以及哪类请求总是出错。我们可以帮助确定调查范围，并构建缺失的集成、工作流或验证环节。

即使看板显示一切正常，你也愿意听听真正需要修复的问题吗？给我们留言。带上业务流程，我们从它实际做了什么开始。