「答不上来就转人工」——听起来是客服 Agent 最不需要设计的一句兜底。但 Intercom 的官方文档写出了三种具体风险：宽泛的转人工指导会推高人工量；客户看到转人工选项后往往会接受，即使 Agent 原本可能解决；如果后台没有配置真人路由目标，Fin 根本不会提供真正的交接。[E2]
也就是说，这句兜底可能比没有更糟：触发太宽，把本可解决的问题送进人工队列；路由不存在，让交接停留在表面。
Intercom 在自己的客服团队里运行 Fin。他们公开材料里最值得借鉴的，并不是「AI 解决了多少问题」，而是逐渐把「转人工」拆成了一条完整流程。[E1]
三层拆分：为什么转、怎么转、转过去之后做什么
第一层是判断什么时候交出去。Fin 默认处理几种信号：客户明确要求真人、出现强烈愤怒，或者对话陷入重复循环。团队还可以用结构化数据添加硬规则，例如问题被识别成 Bug、客户属于某个群体；也可以用自然语言描述较难结构化的行为。[E2]
但判断需要人工，并不等于立刻把整个对话扔给人工。Intercom 把通用的交接动作分成了几种：立即转交、先问客户是否需要真人，或者先补充必要信息。邮件渠道另有一项「Ask for input」能力，可以让同事只提供内部意见、仍由 Agent 完成回复；官方页面明确写明，它目前是邮件渠道的公开测试版，而且不适用于 standalone Fin，不能当成聊天等渠道都具备的通用能力。[E2] 最后，另一个工作流才负责建单、收集信息和分配队列。
「为什么转」与「转给谁、接下来做什么」，就这样被拆开了。
拆分背后是组织设计
这个拆分听起来像产品功能，背后其实是组织设计。Intercom 自己先从高频信息类问题开始，只向一部分客户开放，初始解决率超过 25% 后才扩展到大部分客户群；随后增加专门维护知识的 Knowledge Manager、负责整段对话体验的 Conversation Designer，以及持续优化 Agent 的 AI Support 团队。[E1] Conversation Designer 关心的不只是机器人怎么说，也包括真人接手时看到了什么、客户是否需要重新解释。
Intercom 宣称，到 2026 年 3 月，Fin 已经处理并解决了超过 81% 的客服总量。[E1] 这个数字只能作为厂商自报：公开材料不足以独立复算，而且「解决」包含一种推定状态——Agent 给出答案后，客户没有继续求助，也可能计为解决；若客户后来回到同一对话继续求助，该次解决才会被撤销。[E4]
因此，比追一个漂亮的自动解决率更重要的，是观察交接本身有没有改善结果。
两个独立反证
Intercom 也承认，宽泛规则会让升级量突然上升。客户一旦看到转人工选项，往往会接受，即使 Agent 原本可能继续解决。[E2] 于是「客户不高兴就转人工」这种好心规则，可能把自动客服重新变成人工客服入口。
而且，转交并不会自动修复已经发生的糟糕体验。一项针对淘宝客服的随机现场实验发现，人工介入对技术类失败较能维持服务质量，对情绪类升级的效果更弱；较早介入与更高的人工投入相关。[E5] 这个研究不是对 Fin 的测评，但它提醒我们：等客户彻底恼火后再交给真人，真人接到的已经不是原问题，而是一段需要先修复的关系。
可试小方法：一张 20 条对话的「转人工矩阵」
一个小团队不需要先复制 Intercom 的整套系统。可以先拿最近 20 条真实对话，画一张很小的「转人工矩阵」。
适用前提：已有真人客服队列，且有人能在承诺时间内接手；能回看对话、记录触发原因，并区分自动解决、转交和重复求助；先用于一个低风险、边界清楚的客服主题，不直接覆盖医疗、财务、身份安全等高风险全量场景。
最小动作——从 20 条对话中只定义三类：
- 立即转人工：明确要求真人，或涉及只有人才能批准的风险和权限。
- 先补一个问题再决定：信息不足、问题含糊或只是轻度不满，Agent 仍可能解决，先追问一个关键问题。
- 人工给意见、Agent 继续回复：答案方向可能成立但置信不足——只有当所用工具明确支持这种「人内审」模式时才用（Fin 的该项能力目前仅限邮件公开测试版，且不适用于 standalone Fin）；不支持时由真人直接接手。
每一类只写一个触发条件、交接前必须收集的两项信息、接收队列和承诺时间。先用历史对话回放，再开放少量真实流量。
观察信号：漏转（真人事后判断本应更早接手的比例）、误转（真人只重复 Agent 答案的比例）、客户为了找真人重复表达的次数、人工接手时间和重复求助——而不是只盯着自动解决率。
停止或转人工条件：出现安全、隐私、资金或合规问题的漏转，立即暂停该主题的自动处理；人工队列根本没人接时，不让 Agent 承诺「正在转交」；转交量上升但客户体验和人工处理时间没有改善时，问题通常不在少一条规则，而在规则太宽、或真人接手得太晚。
附：本文证据使用说明
本文属于 Agent 实验室的外部真实实践案例线：写的是具名团队（Intercom）在生产环境里实际怎样运行 Agent，而不是产品介绍。全部事实来自公开一手来源：Intercom 官方博客与帮助文档 [E1]-[E4]、arXiv 公开论文摘要 [E5]，访问时间均为 2026-09-30。81% 解决率、300% 需求增长、100 人编制节省均为 Intercom 对自身团队的自报，无独立审计；「转人工矩阵」是本文从其公开流程提炼的编辑方法，不是 Intercom 原文提供的模板。外部事实归原出处，提炼与错误归本文。