AI 客服何時轉真人：例外情境與交接驗收表

文章目錄

• 1. 列出 AI 不能自行處理的問題
• 涉及金額認定與個案裁量的問題
• 帶有法律或合規性質的詢問
• 情緒明顯升高或重複申訴的對話
• 2. 設計轉真人的觸發條件
• 關鍵字與意圖觸發
• 對話輪次與重複提問觸發
• 使用者主動要求轉人工
• 3. 定義最少必要交接資訊
• 必要欄位：沒有就無法處理
• 建議欄位：能提升接手效率
• 欄位格式建議：結構化勝過長篇摘要
• 4. 測試轉接失敗與離線情況
• 真人客服離線時的應對設計
• 系統異常導致轉接失敗的備援
• 真人客服滿線時的排隊機制
• 5. 用情境表驗收接手流程
• 驗收情境矩陣範本
• 接手確認表：真人客服端的核對清單
• 驗收頻率與回饋機制

AI 客服何時轉真人沒有單一公式，但有可驗證的判斷依據：當對話涉及金額認定、法律爭議、或使用者情緒明顯升高時，系統應在設定的輪次內強制轉接，而非持續嘗試用罐頭回覆安撫。許多企業導入 AI 客服後，把「轉真人」當成最後才補的功能，結果上線後才發現，使用者卡在沒有出口的對話框裡，比完全沒有 AI 客服更糟。這篇文章不談 AI 客服該用哪個平台，而是談一件更實際的事：AI 處理不了的時候，接下來怎麼辦。

本文重點摘要

• AI 客服轉真人的核心判斷依據，是問題是否涉及金額認定、法律責任或使用者情緒升高
• 交接資料若缺少對話逾時紀錄與使用者已表達訴求，真人客服平均要多花時間重新確認狀況
• 沒有離線備援機制的轉真人設計，在非上班時間等同於讓使用者卡在無人回應的對話框
• 驗收 AI 客服轉真人流程，應該用情境表逐一測試而非只看系統上線與否
• AI 客服無法自行處理退費金額認定、帳務爭議與需要人工裁量的客訴，這類情境必須設計強制轉接

列出 AI 不能自行處理的問題

設計轉真人機制之前，得先承認 AI 客服的能力邊界在哪裡。坊間常把這件事講得很玄，說 AI「理解不了情境」，但實際拆解後，問題通常集中在幾個具體類型，而不是模糊的「AI 不夠聰明」。

涉及金額認定與個案裁量的問題

退費金額、折扣幅度、瑕疵品賠償比例，這類問題的共通點是「答案要看個案」。假設一位消費者詢問訂單退費進度，AI 客服可以查詢訂單狀態並回覆；但若對方主張商品有瑕疵要求全額退款加運費補償，這已經涉及公司內部裁量權限，AI 若擅自承諾等同做出企業無法反悔的決定。電子商務交易涉及的定型化契約與消費爭議，依消費者保護法相關規定本就需要明確處理程序，不是客服機器人單方面能拍板的事。

帶有法律或合規性質的詢問

使用者詢問個資如何被使用、要求刪除帳號資料、或質疑某項條款是否合法，這類對話一旦 AI 給出不精確的回答，風險不是「使用者不滿意」，而是企業可能要為錯誤資訊負責。台灣個人資料保護法對於資料蒐集、處理與利用有明確規範，客服系統在這類詢問上應該被設計成直接轉接，而不是嘗試自行生成解釋。

情緒明顯升高或重複申訴的對話

使用者用大寫字母、連續驚嘆號、或是同一個問題問第三次，這些都是情緒升高的訊號。AI 客服如果偵測不到這類訊號，只會持續用制式回覆循環應答，反而加深對方的挫折感。

AI 客服的能力邊界不是「聰不聰明」，而是「有沒有裁量權」。沒有裁量權的問題，再厲害的語言模型也不該自己拍板。

設計轉真人的觸發條件

企業要如何選擇適合的 AI 客服轉真人時機？答案是：先設定可量化的觸發條件，而不是依賴 AI 自行「感覺」該不該轉接。觸發條件通常分成三類，彼此可以並行設計，不互相排斥。

關鍵字與意圖觸發

當使用者輸入包含「退費」「投訴」「律師」「客訴」「消保官」等字詞，或對話意圖被分類為「要求賠償」「法律諮詢」時，應立即觸發轉接，不需要等待對話輪次累積。這類觸發條件設計相對單純，但要注意關鍵字清單需要定期檢視更新，否則容易遺漏口語化的表達方式，例如「我要申訴」跟「這樣我沒辦法接受」語意接近，但字面完全不同。

對話輪次與重複提問觸發

假設同一位使用者在 3 輪對話內重複相同問題，或 AI 連續 2 次給出「無法理解您的問題」這類回應，系統應自動轉接。這個門檻值沒有放諸四海皆準的標準答案，但業界實務上常見的設計是落在 2 到 4 輪之間，太短會讓本可由 AI 處理的簡單問題也被轉走，增加真人客服負擔；太長則會讓使用者在無效對話中消耗耐心。

使用者主動要求轉人工

這點看似理所當然，但不少企業的 AI 客服設計裡，使用者講「我要找真人」卻仍被導向常見問題頁面。這是典型的反面教材：系統邏輯把「轉真人」當成最終手段而非使用者選項，結果使用者得連續講三次才成功跳出對話框。正確做法是把「轉真人」設計成任何時間點都能主動觸發的指令，不綁定在特定流程節點之後。

轉真人的門檻不該讓 AI 自己判斷，而該由企業事先寫死規則。

定義最少必要交接資訊

轉真人失敗最常見的原因，不是系統技術問題，而是交接資料不完整，導致真人客服得從頭問一次「請問您的問題是？」，使用者的耐心在這個瞬間流失大半。這裡整理一份可直接套用的交接欄位清單，依必要程度分類。

必要欄位：沒有就無法處理

• 使用者識別資訊（會員編號、訂單編號或聯絡方式，依系統設計擇一）
• 觸發轉接的原因分類（金額爭議／法律詢問／情緒升高／主動要求／其他）
• AI 與使用者的完整對話紀錄（非摘要，含時間戳記）
• 使用者已明確表達的訴求（例如「要求全額退款」）
• 轉接時間與等待佇列位置

建議欄位：能提升接手效率

• 使用者過去 30 天內的客服互動次數（判斷是否為重複申訴）
• 訂單相關的物流或金流狀態快照
• AI 已嘗試過的解決方案（避免真人客服重複提出相同方案）
• 情緒分析標記（如果系統有此功能，標示對話情緒強度）

欄位格式建議：結構化勝過長篇摘要

交接資料不該是一段 AI 生成的長文摘要，而應該是結構化的欄位表單。真人客服在幾秒內掃過表單就能掌握狀況，遠比閱讀一段 200 字摘要更快。表單化設計也方便事後稽核與統計，例如分析哪一類觸發原因佔比最高，藉此回頭優化 AI 客服的自動應答範圍。

交接資料的價值不在「多」，在「真人客服看完能不能立刻接話」。超過 5 秒讀不完的摘要，使用者等於又被晾在那裡一次。

測試轉接失敗與離線情況

假設一家零售業者的 AI 客服系統在平日晚上十點收到轉真人請求，但真人客服的上班時間是早上九點到晚上六點，這時候系統該怎麼回應？這是導入前最容易被忽略、卻在上線後最常出包的環節。

真人客服離線時的應對設計

常見的錯誤做法是系統持續顯示「正在為您轉接客服人員」的訊息，使用者卻永遠等不到回應，對話視窗變成一個黑洞。正確設計應該包含：明確告知目前非服務時間、提供預計回覆時間範圍、並同步開放其他聯絡管道（例如 LINE 官方帳號訊息或客服信箱），讓使用者的訴求不會因為離線而消失。

系統異常導致轉接失敗的備援

轉真人的 API 串接若發生逾時或錯誤，使用者畫面不該直接卡死或跳出技術錯誤訊息。建議的備援邏輯是：系統先嘗試重試一次，若仍失敗則記錄此次對話並提供替代聯絡方式，同時觸發內部告警通知技術人員。這類異常狀況若沒有被記錄下來，企業永遠不知道究竟流失了多少本該被妥善處理的客訴。

真人客服滿線時的排隊機制

尖峰時段所有真人客服同時忙線是常態，而非例外。這種情況下，系統應提供排隊位置與預估等待時間，而不是讓使用者完全不知道自己的訊息是否已經送出。部分企業會在這個環節設計「AI 先行安撫並嘗試再次釐清問題」的過渡機制，但要留意不能讓使用者誤以為這代表問題已被處理。

轉真人失敗不是罕見意外，是每個 AI 客服系統都會遇到的常態，差別在於有沒有備援。

用情境表驗收接手流程

AI 客服轉真人的驗收該怎麼進行？答案是透過情境表逐一測試，而不是只確認系統是否成功上線。下方提供一份可直接套用的驗收情境矩陣範本，企業可依自身業務類型增減項目。

驗收情境矩陣範本

接手確認表：真人客服端的核對清單

真人客服接手對話後，應該在系統上對照以下項目確認資料完整，而不是憑感覺判斷資訊是否足夠：

• 對話紀錄時間戳記是否完整，無缺漏片段
• 使用者訴求欄位是否已填寫，而非空白或「其他」
• 觸發原因分類是否與實際對話內容相符
• 是否有重複客訴紀錄需要優先處理
• AI 已嘗試的解決方案是否已標註，避免重複提出

驗收頻率與回饋機制

情境表不是上線前測一次就結束，建議至少每季重新測試一輪，尤其在 AI 客服的意圖分類模型更新、或新增產品服務類別之後。企業也可以建立真人客服的回饋管道，讓第一線人員回報「哪些轉接資料常常缺漏」，這份第一手回饋往往比系統日誌更快抓到實際落差。

驗收 AI 客服轉真人流程，不是看系統有沒有上線，是看情境表裡每一項測試能不能打勾。

AI 客服轉真人這件事，技術門檻其實不高，真正困難的是流程設計：什麼時候該轉、轉接時帶什麼資料、系統出包時怎麼辦。我們在協助企業規劃 AI 導入專案時，常把這三個問題當成優先於功能選型的前提條件，因為使用者體驗的落差往往不在 AI 回答得準不準，而在轉真人那一刻是否順暢。網站與客服系統的串接、資料欄位設計、以及後續的流程驗收，都屬於需要事前規劃的技術決策，而不是上線後才補救的細節。

評估 AI 客服導入與轉真人流程設計

若貴公司正在規劃 AI 客服導入，或既有系統的轉真人機制需要重新檢視，歡迎與我們聯繫，討論適合貴公司業務情境的流程規劃與技術建議。