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 電話與即時派單技術案例