2026 年 9 月 4 日
你的 AI 客服，什么时候该停下来
好用的 AI 客服，不在于让每段对话都全程自动化，而在于认得清自己的边界：该交出去时就交出去，而且不让客户从头再说一遍。
一位客户告诉客服，导出已经失败了两次。AI 讲了一遍导出流程，请对方重试；客户回来再问，得到的还是同一套回答。客户关掉了聊天窗口。仪表盘记下一次“拦截成功”，客服负责人看到转人工的次数又少了。没有人记下：导出依然是失败的。AI 客服的价值，不在于它能一直说下去，而在于它能推动问题往前走——包括知道什么时候该停下来。
拦截率奖励的是硬撑，不是判断力
拦截率回答的只是一个很窄的分流问题：这段自动化对话，是不是在人工介入之前就结束了？这对人力规划有意义，但客户真正要办的事有没有办成，它一个字也说明不了。
在实际落地中，这条界线正在变得模糊。Dialpad 2026 年对 150 位客服负责人的调查发现，39% 的人把“客户不再回复”算进了“已解决”的定义里，51% 的人只要没有人工介入就算结案，不管问题到底有没有处理。追踪拦截率的团队，比追踪解决率的更多。这份样本来自零售和医疗行业的负责人，不能当作通用的 SaaS 基准。但这些定义本身就是一个值得警惕的信号：一支客服团队，完全可能在一个自己从未真正观察到的结果之上，搭起一整套精细的度量体系。
规模更大的一项研究——Ada 与 NewtonX 针对 2,000 名消费者和 500 位企业负责人的调研——发现，只有四分之一的消费者表示，自己最近一次找 AI 客服的问题，在没有人工参与的情况下被彻底解决。研究还发现，44% 的企业把 AI 和人工的服务交互放在一起统计。厂商赞助的研究照例要打个折扣来看，但这两项发现暴露的是同一个归因问题：团队看得到自动化碰过某个工单，却不知道到底是哪一环把问题解决了。
来看三段同样关于导出失败、同样“拦截成功”的对话：
1. AI 发现日期范围无效，客户改正之后，导出顺利完成。
2. AI 给了一篇客户早就读过的文章链接，客户随即放弃。
3. AI 说会联系客服团队，但实际上根本没有发出任何工单。
只有第一段真正解决了问题。可在拦截率仪表盘上，这三段对话毫无区别。
对话结束，只能证明对话结束了。没有其他信号佐证，它证明不了客户把事办成了、看懂了回答，或者还打算继续用下去。
停下来，要有理由
解决办法不是把全局置信度阈值调低。置信度本身可能校准得很差，而且一个信心十足的 AI 客服，照样可能缺少把事情办完所需的数据或权限。要不要转人工，应该由可观测的失败状态来决定。
失败状态 · 产品能拿到的证据 · 正确的下一步
答案缺乏依据 · 当前页面和经过审核的知识来源里都没有这条信息 · 说明缺了什么，并提供转人工的通道
执行失败 · 按有限次数的重试策略重试之后，预期状态仍未出现 · 保留这次尝试的记录，把问题移交出去
权限边界 · 请求需要 AI 不具备的判断、特批或访问权限 · 把问题交给有权限的人负责
明确意愿 · 客户要求找真人 · 直接转人工，不争辩，也不再绕一轮机器人
紧迫度上升 · 截止时间、反复来询或越积越多的挫败感，都会抬高拖延的代价 · 更早提供转人工的通道
这几种状态各不相同。缺一篇帮助文章，是知识问题；一个按钮反复报同一个错，是产品或账户问题；退款要特批，是权限问题。无论哪一种，都不是把话说得更流畅就能解决的。
客户本人的要求也应当一锤定音。Gartner 在 2026 年初调查了 3,566 名 B2B 和 B2C 客户，发现 87% 的人认为，企业用生成式 AI 提供服务时，能联系到真人必不可少。一条看得见的人工通道，并不等于承认自动化这条路走失败了，它本身就是服务产品的一部分。
转人工怎么发起，决定了补救的效果
很多产品名义上提供人工客服，却要客户自己摸索出某句“咒语”，或者连着拒绝机器人三次，又或者在菜单里翻来翻去。转人工在流程图里是存在的，到了界面上却走不通。
发表在《Decision Support Systems》上的三项在线实验，研究了聊天机器人失败后发起人工介入的四种方式：被动入口、输入文字请求、点击按钮，以及系统自动发起。不同方式带来的补救满意度并不一样，而问题越紧急，差异就越大。仅凭论文摘要，还不足以断言哪一种机制在所有场景下都最好。但它确实说明了一点：怎么发起，本身就是补救体验的一部分，而不是包在外面、无关紧要的一层壳。
一套实用的系统，会同时提供不止一条通道：
– 始终保留人工选项，不要求客户先失败一次才能用。
– 客户直接要求找真人，就把它当作指令来执行，而不是当成需要化解的异议。
– AI 一旦发现自己碰到了证据、执行或权限上的极限，就主动提出转人工。
– 遇到已知的严重故障或紧急场景，自动打开转人工入口；但未经客户确认，不发送任何消息，也不共享任何数据。
时机很重要，因为介入得晚，接手的就是一个已经疲惫的客户，和一个投入度更低的人工客服。一项在阿里巴巴旗下淘宝客服业务中开展的随机现场实验发现，人工尽早介入，有助于让员工在升级过来的对话里持续保持投入。研究还发现，由技术问题触发的升级和由情绪触发的升级，结果并不相同。这只是来自一个大型电商平台的预印本，算不上普适的运营准则，但它支持一个有用的区分：升级逻辑应当针对失败的类型和时机做出反应，而不只是看一个笼统的情绪分数。
这里说的主动，不是悄悄替客户提交一张工单，而是缩短两者之间的距离：一头是系统已经识别出的失败，另一头是客户自己能掌控的、清晰的补救选项。
移交的是问题的状态
把对话记录丢进队列，总比什么都不发强。但这仍然算不上交接设计。
对话记录记下的是消息的先后顺序，而下一位客服人员需要知道的，是这件事进展到了哪一步。移交时，至少要让以下六件事一目了然：
1. 客户的目标。用客户自己的话说，他们想做成什么？
2. 相关状态。他们用的是哪个账户、哪个对象、哪个页面路由、哪个套餐或哪个工作流？
3. 尝试过什么。AI 建议过或做过什么，每一步之后又发生了什么？
4. 卡点。是哪个报错、哪项缺失的权限、哪条没有依据的信息，或者哪次失败的状态变更，让事情停了下来？
5. 紧急程度。有没有截止时间、反复失败、对账单的影响，或者其他需要优先处理的理由？
6. 经客户同意的证据。客户选择共享了哪些诊断信息？
原始对话要一直保留，因为自动生成的摘要，可能恰好漏掉那个会改变诊断结论的细节。在它上方放一份简明的问题草稿，人工客服就不必从二十轮对话里重新拼凑事情的原委。
这份草稿不应把人工客服框死在 AI 的理解里。2026 年一项针对机器人转人工客服对话的分析发现，在纠正误解时，聊天机器人倾向于泛泛而谈，而人工客服会追问更具体的问题。好的移交，既让人工客服抢先一步，也给他们留出空间，去问机器人漏掉的那个问题。
诊断信息需要单独的规则。当前所在的页面、最近的控制台报错、账户状态，都能让技术问题的诊断快上许多，但其中也可能包含客户并不想分享的信息。说清楚会收集哪些数据，默认关闭这个选项，让客户自己决定。只有当收集上下文不会让补救过程变成又一次失信时，上下文才有价值。
– 客户的目标排在 AI 摘要之前。
– 每次尝试都与观察到的结果一一对应，人工客服就不会重复那些已经失败的建议。
– 问题的实时状态与完整对话记录分开呈现。
– 敏感的诊断信息可选、具体，并经用户同意。
– 人工客服可以修正摘要，并继续追问。
把“现在由谁负责”说清楚
从 AI 决定升级，到真正有人接手这个问题，中间有一段很脆弱的时刻。产品常常用含糊的话一笔带过，比如“我已经通知团队了”。这句话可能意味着有了一份草稿，可能是触发了一个 webhook，可能是一张工单进了队列，也可能什么都没发生。
界面应当如实呈现真实状态。AI 准备的是草稿，就叫它草稿。让客户可以修改主题和正文。显示回复会发到哪个联系地址。发送前先请客户确认。服务器接收之后，展示一个编号，并诚实地说明接下来会发生什么。如果不知道多久会有回复，就不要编一个出来。
AI 的角色也需要干净利落地收尾。问题一旦移交，它就不该再越过人工队列，继续抛出各种猜测性的解决办法。它可以确认已收到、保留对话，并继续回答其他问题。这个问题，现在归客服团队负责。
这种清晰，不只是一句让人安心的文案。它构成了一组可审计的状态：草稿已创建、客户已编辑、客户已发送、团队已接收、人工已回复、问题已解决。每个状态失败时都看得见，也都可以重试。聊天气泡里一句含糊的承诺，做不到这一点。
衡量整个补救过程，而不是单一渠道
分析的单位应当是客户的问题，而不是一次自动化会话。否则，一次失败的聊天加上随后一封成功解决问题的邮件，会被记成一次“拦截成功”的 AI 交互，外加一张毫不相干的人工工单。仪表盘为前者喝彩，把后者记作成本，可它们其实是同一段服务旅程。
结果模型不需要第一天就有一个完美、通用的问题标识符。可以先这样做：客户、意图、受影响的对象都相同，而且落在合理的时间窗口内，就把这些交互关联起来。匹配规则要可解释，并允许客服人员手动纠正。然后，把结果分开来看：
– 经验证的 AI 解决：产品记录到了所请求的状态变更，或者客户确认那条信息类的回答解决了问题。
– AI 辅助解决：自动化收集了信息或完成了有用的工作，随后由人工解决了同一个问题。
– 合理升级：请求越过了事先声明的知识、能力或权限边界，并送到了正确的负责人手里。
– 本可避免的升级：答案或操作本在范围之内，但自动化没能交付。
– 未解决或结果未知：客户放弃了、重复反映同一问题，或者离开时留下的证据不足以判断结果。
拦截率可以和这些类别一起追踪，但不能凌驾于它们之上。再补上几项指标：多久由人工接手、客户需要重述问题的比例、同一问题的重复联系次数，以及最终是否解决。对抽样的案例，复核移交过去的状态是否准确、是否充分。具体的时间窗口和证据门槛，要与所办的事相匹配：账户设置可以立即验证，账单争议则可能要拖上好几天。
这样一来，激励机制就变了。AI 客服能证明自己成功时，记它一次自主解决；人工才是合适的负责人时，记它一次干净的助攻。而把客户困在自动化渠道里、耗到精疲力尽，不记任何功劳。
Barkan 如何对待这条边界
Barkan 的设计目标，是在问题发生的地方解决日常的操作类问题：它依据的是客户当前屏幕上实际渲染出的界面，以及已接入的产品知识。当这两处都无法支撑一个回答，或者访客明确要求反馈问题时，Barkan 会为网站的客服团队起草一条消息，而不是凭记忆去填补空白。
我们把这条消息做成了草稿，而不是一个在后台执行的动作。访客可以修改主题和正文，填写接收回复的邮箱，并决定是否附上技术细节。这个诊断信息选项默认不勾选。只有访客点击发送之后，工单才会进入网站的客服收件箱，并附上对话内容，以及访客同意提供的页面上下文或最近的报错。
这个流程并不能证明问题最终得到了解决，它也不该假装能证明。它守住的是三者之间的区别：一个回答、一次提议的升级、一张已发出的工单。工单后来有没有解决，仍然是另一个独立的结果。
AI 客服一定会失败。产品要决定的是：这次失败会变成一个死循环、一次无声的离开，还是一场准备充分的补救。
在访客所在的页面上直接给出指引；当自动化到了极限，再给他们一条先确认、后发送的通道，直达你的团队。
“大多数用户并不想再得到一个答案。他们要么想有人指路，要么想有人直接把事办好。这就是产品的全部。”
Gabriel Lancelot
Barkan 联合创始人
