网站客服转人工：先定义触发规则再开发

网站 AI 客服最容易被拖到最后的功能，是「转人工」。作者认为顺序应该反过来：对商业网站来说，机器人答不上来的访客，可能恰好带着具体需求；转接是否顺畅，直接影响这次咨询能不能继续。

这篇给出的不是模型选型建议，而是一份可以拆成开发任务的交接规格：什么时候转、收集什么、传给谁、如何承诺回复时间，以及上线后看哪些指标。它适用于 OpenAI、Claude、Gemini，也不要求团队一开始就配齐在线客服。

转人工的决定，不能只交给主模型

作者把转接条件分成五类，并要求在写代码前确定下来：

• 用户明确要求人工，对应 USER_REQUEST。用简单分类器或关键词表识别「找客服」「给我打电话」等表达。
• 检索没有找到超过阈值的相关内容，或者模型承认不知道，对应 LOW_CONFIDENCE。
• 涉及受限话题，对应 RESTRICTED_TOPIC。例如超过指定金额的退款、投诉、法律问题、医疗或财务建议，以及具体账户问题。
• 出现询价、预约、询问开工时间等购买信号，对应 BUYING_SIGNAL。
• 同一个问题换着说了三次，或者连续三次表示答案没帮助，对应 LOOP。

这些名称不是为了让枚举好看。后续分配队列、统计转接原因、排查知识缺口，都需要稳定的标识。

受限话题一旦命中，就直接转人工，不先让机器人试答。

购买信号则允许机器人先收集必要信息，再交给人员尽快跟进。两类情况的业务目的不同，不能都塞进一个含糊的「无法回答」分支。

真正要交接的是上下文，不是一条通知

作者建议转接前只补齐两项：联系方式及联系授权，以及一句经访客确认的问题摘要。摘要可以由机器人起草，避免让用户重新填写已经讲过的事情。

授权记录要包含布尔值、时间戳和当时展示的文案。原文特别提到英国和欧盟访客，但没有给出通用合规结论；具体措辞仍需业务的隐私负责人确认。

下面这段 payload 定义了机器人和人工处理系统之间的数据契约，可以作为接口设计的起点：

{
  "version": 1,
  "conversation_id": "c_8f2a...",
  "reason": "BUYING_SIGNAL",
  "summary": "Wants a WhatsApp chatbot for 3 clinics, asks about timeline",
  "visitor": {
    "name": "Jordan",
    "email": "jordan@example.com",
    "consent": { "given": true, "at": "2026-11-11T09:12:44Z", "text_id": "consent-v3" }
  },
  "page_url": "https://example.com/pricing/",
  "utm": { "source": "google", "campaign": "brand" },
  "transcript_url": "https://internal.example.com/conversations/c_8f2a",
  "retrieval": { "top_score": 0.41, "sources": ["/services/", "/faq/"] }
}

重点看 version、transcript_url 和 retrieval：接口需要版本，聊天记录需要访问控制，检索分数需要留下来复盘。示例中的 0.41 是记录值，不是推荐阈值。

作者建议向邮件或聊天工具发送记录链接，避免复制整段对话，让个人数据集中保存。page_url 和 UTM 则帮助销售判断咨询来自哪个页面、哪次推广。

人工端可以是 Intercom、Zendesk、Slack、邮件或 CRM 任务。作者通常用 webhook 接入 n8n、Make、Zapier，再向不同系统分发，因为路由规则往往比机器人代码变化更频繁。这是他们的实现经验，原文没有提供维护成本对照。

营业时间改变承诺，交接之后还要改变会话状态

凌晨两点收到咨询，不能照样回复「马上有人联系你」。作者建议保留相同的转接流程，只根据营业时间切换提示：

{
  "timezone": "America/Chicago",
  "hours": { "mon-fri": "09:00-18:00" },
  "in_hours_message": "I'm passing this to the team now. Most replies arrive within 15 minutes.",
  "out_of_hours_message": "The team is offline right now. I've saved your question and they'll reply by email on the next working day."
}

要注意 timezone 和 hours：示例是工作日 09:00-18:00，营业时提示多数回复在 15 分钟内到达，非营业时承诺下一个工作日通过邮件回复。15 分钟只是配置示例，不能直接当成自己团队的服务能力。覆盖 Dallas、Toronto 等多个市场时，作者建议每个队列独立配置时间表。

转接完成后，机器人应明确交代三件事：由谁接手、预计何时回复、通过哪里回复。随后停止在该线程继续答题，或者清楚标注后续答案来自自动系统。

上线后要看四组数据：各原因的转接率、区分营业内外的首次人工回复时间、BUYING_SIGNAL 转成预约通话或报价的比例，以及排名前 20 的 LOW_CONFIDENCE 问题。

阈值没有通用答案。作者建议保守起步，记录每次分数，两周后复盘 50 次转接，再调整。

我的判断

这份规格最有价值的地方，是把「转人工」展开成了可追踪的业务流程。只调用一次通知接口，无法保证有人接手，更无法让访客知道接下来会发生什么。

但它仍是经验方案。作者没有提供转化率提升、漏转率或不同识别方案的对照数据，也没说明关键词匹配如何处理否定表达、多语言和误触发。

低置信度问题变少，也不能单独证明机器人变好，还要看咨询量和问题分布有没有变化。购买信号回复变慢，可能是人手不足，也可能是识别规则把太多普通咨询送进了销售队列。

另外，这份规格还没写清重复投递、接口失败、队列无人领取和人工接单回执。「已经发出转接请求」和「确实有人接手」需要分别确认。 相比直接接入完整在线客服系统，邮件加 CRM 任务适合先跑通流程；代价是需要更明确地管理跟进责任。

能拿来做什么

• 给网站 AI 客服补功能时，先确定五类转接原因及处理规则，再做按钮和弹窗；前端同步展示当前由机器人还是人工处理。
• 在 Node 接口中固定带版本的交接结构，保留摘要、来源页面、授权记录和检索分数，让不同人工渠道共用一份上下文。
• 从团队实际能兑现的回复时间出发配置提示；暂时没有在线值守能力时，可以先接邮件和 CRM 任务。
• 上线两周后复盘 50 次转接，把高频低置信度问题用于更新内容，并检查购买信号是否得到及时跟进。