AI 语音客服的人工转接不是失败按钮，而是完整服务流程的一部分。系统要先判断何时不该继续、找到正确席位、带走已确认资讯，并在满线、断线或企业系统异常时留下可追踪的下一步。只把电话丢回总机，让来电者全部重讲，并没有完成真正的上下文交接。
使用者明确要求真人、连续误解、必要栏位无法确认、涉及金流或权益、高风险关键字、企业 API 回传不可处理状态，以及模型或电话服务异常，都可以成为接手条件。条件要写成可记录的原因码，而不是只依模型自由判断。这样客服才能知道为何收到电话，运营端也能分辨流程设计与模型品质问题。
| 触发原因 | AI 应做的事 | 人工收到的重点 |
|---|---|---|
| 使用者要求真人 | 立即确认并进入适当伫列 | 来意、已确认身分与等待状态 |
| 重复误解或低信心 | 停止猜测并说明将转接 | 原始问题、失败栏位与重问次数 |
| 敏感或高风险事项 | 不执行不可逆动作 | 风险分类与相关案件资料 |
| 企业系统失败 | 不宣称成功，建立待处理状态 | API 状态、请求识别与是否可重试 |
| 人工席位不可用 | 提供排队、回拨或建立待办 | 联系方式、时段与追踪识别 |
计划转接是流程本来就设计由真人完成，例如 AI 先搜集资料再送到特定专员；异常升级则是 AI 无法理解、系统失败或使用者不满而退出。两者混在一起会让团队误以为所有转人工都是自动化失败，也可能掩盖真正的误解问题。Google Cloud 的虚拟客服指标同样区分 planned transfer、escalation、resolved 与 abandoned。
AI 应用可以提出转接目标与原因，但代表号、分机、技能群组、营业时间、排队、溢出与录音延续通常由 PBX、SIP 平台或联系中心处理。导入前要确认盲转、谘询转、保留原号码、跨系统会话识别及转接失败事件。只说「支援 SIP」不足以证明现有电话环境能完成所有路由。
人工席位至少需要知道来电目的、已确认栏位、未解问题、企业系统查询结果、已执行动作与失败原因。原始录音、完整逐字稿或敏感栏位是否显示，应依角色和目的决定；能用摘要与必要栏位完成工作，就不应把所有资料全部暴露。席位画面还要标示哪些值由使用者确认、哪些只是模型推测。
| 资料 | 用途 | 控制方式 |
|---|---|---|
| 转接原因码 | 判断优先顺序与下一步 | 固定分类，不让模型输出任意权限指令 |
| 已确认栏位 | 避免使用者重复回答 | 标示确认时间与来源 |
| 未解问题 | 让人工直接接续对话 | 和模型摘要分开呈现 |
| 系统状态 | 避免重复查询或建单 | 附唯一请求识别与最终状态 |
| 安全摘要 | 快速理解脉络 | 遮罩非必要个资并限制原文存取 |
若席位满线，可让使用者选择等待、指定时段回拨或建立工单；若转接 API 失败，应保留原通话、重试到备援伫列，或明确说明后续处理。断线后能否回拨，要先确认联系目的、号码使用与企业政策。每一条降级路径都要产生案件识别与前端可见状态，不能把错误写进 log 后让使用者自行重打。
转接率只能说明有多少通进入人工，不能单独判断好坏。应搭配计划转接、异常升级、误分流、排队放弃、首次解决、总处理时间及使用者重复说明的比例。若某个意图大量计划转接，可能代表流程设计正确；若某个栏位反覆造成异常升级，才是对话、资料或模型需要修正的讯号。
GoGoCha 公开内容可证明电话入口、共用派单后端、即时通知，以及网站、LINE、App 与运营介面整合；它没有公开 PBX 型号、客服技能伫列、满线策略或转接 SLA。这些属隼讯可依企业环境客制并透过 POC 验收的范围，不能包装成 GoGoCha 已验证的完整客服席位成果。
公开案例与可验证证据
GoGoCha AI 电话与即时派单技术案例