项目实施与运营
AI客服转人工，需要交接哪些信息？
用户在 AI客服处遇到问题，转给人工时最怕两件事：客户要把说过的话重讲一遍，坐席看不到前面发生了什么。所以转人工不只是"把会话转过去"，而是要把已经核实的信息、已经执行的动作和还没解决的问题一起交过去。
什么情况下需要人工继续处理
机器人向人工升级会话，触发条件应由业务来确定，而不是按固定话术机械触发。常见的四种情况：
● 用户明确要求人工：客户自己提出要找人
● 知识范围外的问题：资料里没有答案，或涉及未授权的判断
● 需要进一步业务判断：例如价格协商、特殊情况处理
● 连续无法确认需求：多轮对话仍未弄清客户要什么
第四种尤其容易被忽略。客户说不清、AI 也问不明白时，与其继续绕，不如早点交给人工——继续追问只会让客户失去耐心。
交接单可以包含哪些字段
优先传递能帮助下一位处理者继续工作的必要信息。不要因为技术上什么都能传，就把所有内容无差别展示给坐席——信息太多等于没有重点，也会带来不必要的权限风险。
举例来说，"已确认需求"这一项要把原话、系统推断和确认结果分开标注。混在一起写，坐席看到的是一句"客户想退款"，却不知道这是客户明确说的，还是系统猜的——两种情况的处理方式完全不同。
| 字段 | 用途 | 检查点 |
|---|---|---|
| 身份核验状态 | 知道哪些信息已核对 | 未核验不能当已核验 |
| 已确认需求 | 减少重复询问 | 区分原话、推断与确认结果 |
| 动作及结果 | 避免重复预约或重复发送 | 区分已请求、成功、失败 |
| 未解决事项 | 明确下一步职责 | 指定接收人或队列 |
坐席繁忙或无人接听怎么办
建议提前确认等待、回呼或其他服务入口，并把可兑现的时间安排讲清楚。说"稍后联系您"却不说大概什么时候，客户只会更焦虑，也容易重复进线。
测试时不要只覆盖"有人接听"这一条路径。下面几种情况都要验证，否则上线后一遇到就卡住：取消、超时、转接失败，以及恢复后的重复处理。
如何验收交接是否完成
可以用相同任务标识把机器人记录、转接事件和坐席处理结果串起来，再核对下面四点：
- 用户是否知道当前由谁服务。
- 坐席是否真正拿到需要的上下文。
- 人工判断和最终标注是否保存。
- 未解决事项是否有明确后续处理。
AI客服向人工交接时保留哪张接续单
本页讨论的是客户主动进线后的客服交接，与外呼营销的初筛转接不是同一类场景——前者是客户带着问题来找你，后者是你主动联系客户，交接的信息结构不同。
有一点要始终守住：只有已核实的信息才能写成确定状态。系统推断的内容要标明是推断，不能和客户亲口确认的内容混在一起写。
| 检查项 | 填写或判断方法 | 验收依据 |
|---|---|---|
| 交接原因 | 知识不足、业务权限或客户需要人工 | 按实际服务边界选择接收人员 |
| 已确认内容 | 身份核验状态、需求、已执行动作 | 不重复询问已有明确结果 |
| 待处理内容 | 尚未解决问题、失败原因与负责人 | 检查实际接续及后续处理记录 |
常见问题
7×24 机器人在线等于人工也随时在线吗？
不等同。人工服务时段与无人值守时的处理方式需要单独说明。机器人可以全天候响应，但涉及人工判断的问题，仍要看坐席的排班安排。
身份识别失败还能回答问题吗？
可以。按项目规则回答无需身份信息的公开问题；涉及具体业务记录时，应先核实身份再继续。这两类问题建议在话术设计时就分开。
把所有历史对话都给人工最好吗？
不是。应优先提供准确摘要和必要上下文，并按业务权限确认可见范围。给得太多，坐席反而找不到重点。
转接成功怎样定义？
建议同时核对坐席接续事件与实际处理记录，避免只统计"请求已发出"。请求发出只说明发起了转接，不等于人工真的接住并继续处理。