AI 轉接真人客服：聊天機器人最艱難的任務

2026 年 5 月出現的兩個數字，擺在一起顯得格外不安。

第一個數字來自 Zendesk 的《2026 年 CX 報告》：今年約有 80% 的例行客戶互動，將完全由 AI 處理。訂單狀態查詢、退款資格確認、常見問題式的查詢、密碼重設——這一長串「我只是想快速得到答案」的需求，正以十八個月前廠商圈以外沒人預料到的速度，被聊天機器人與語音代理程式吸收。

第二個數字來自 SurveyMonkey 的客服趨勢研究：79% 的美國人表示，他們仍偏好與真人互動，而非 AI 代理程式。並非每次都是如此——但只要有選擇，這就是他們的預設偏好。

兩個數字都是真的，它們描述的是同一個市場。要調和這兩者，答案不是「AI 正在勝出」或「AI 正在失敗」。真正的關鍵在於：決定顧客對你客服觀感的那個瞬間，並不是機器人乾淨俐落處理掉的那 80%，而是那道接縫——從機器人轉交到真人的那一刻——以及顧客如何感受這次轉接：是否受到尊重、是否夠快、是否完整。

那道接縫，就是 AI 轉接真人客服。它是大多數聊天機器人部署案中最常被忽略的一環，而在 2026 年，這正是決定哪些公司能帶來顧客滿意度成長、哪些公司會淪為 CNBC 報導「顧客有多討厭聊天機器人」的設計選擇。

「轉接」真正的意思

這個詞常被隨意使用。實際上，轉接是一個具體的事件：對話從聊天機器人轉移到真人手上，而真人能接續機器人先前的進度，顧客不必再重複一次自己的問題。

以下三件事，能區分真正的轉接，與大多數團隊實際上線的那種替代品：

1. 一個能穩定觸發的條件——聊天機器人辨識出「這是該升級轉接的時刻」，並採取行動。

2. 脈絡的移交——真人在接手對話時，已經知道機器人先前知道的一切。

3. 連貫的顧客體驗——顧客不必重新輸入問題、重新提供訂單編號，或重新開啟聊天串。

大多數聊天機器人部署案至少會在其中兩項上失敗。觸發條件變成「顧客打了『真人』兩個字」，而移交則變成「這是逐字稿，祝你好運」。這不是轉接，這只是附上一份紀錄的轉向。

為什麼團隊會做出糟糕的轉接

轉接之所以被低估，有一個結構性原因：它不屬於任何一個團隊。聊天機器人團隊衡量的是分流率，支援團隊衡量的是真人接手後的解決時間與 CSAT。沒有一個儀表板會顯示那道接縫，所以接縫就一直是壞的。

另一個結構性問題，是「好的轉接」很難單獨測試。聊天機器人很容易做展示，但轉接需要聊天機器人、分派層、收件匣或佇列、真正有排班的客服人員，以及一份能正常運作的脈絡承載內容。只要其中任何一項缺席，即使其餘部分都正常，顧客感受到的轉接體驗依然是破碎的。大多數公司在第一天，五個要素裡最多只有兩個做得夠好。

五種應該觸發轉接的情況

翻閱 2025 年到 2026 年上半年的客服事後檢討報告，會發現同樣幾種轉接觸發條件一再出現。表現最強的部署案會在全部五種情況下都觸發轉接；表現最弱的則只在顧客明確要求時才觸發。

明確要求是基本門檻。真正拉開差距的，是其他四項。能偵測到情緒升溫並主動提出轉接真人的聊天機器人，即使真人還在排隊等候，顧客也會覺得受到尊重；而忽略同樣線索、持續嘗試分流的聊天機器人，則會被解讀為在敷衍、甚至操弄顧客的感受。

移交給真人的內容

這是區分「真正轉接」與「隨便揮手打發」的關鍵部分。當觸發條件成立時，聊天機器人傳遞給真人客服的內容，決定了接下來的對話感覺是連貫的，還是得從頭開始。

一份完整的脈絡承載內容應包含：

大多數團隊最常略過的兩個欄位，是推測意圖與轉接原因，而它們恰好是最重要的兩項。逐字稿本身在即時情境下並不好讀——一位同時處理三段對話的客服人員，沒有 90 秒可以慢慢瀏覽十八輪對話。一句話的意圖摘要，加上一個標示清楚的轉接原因（「情緒升溫，第三次拒絕答案」），能把轉接所需的時間從九十秒縮短到三秒。

空佇列問題

即使是設計完美的轉接，也會遇到一個殘酷的現實：真人不會永遠都在線上。轉接設計必須因應三種不同的真人可用狀態，而大多數設計都沒有做到。

**狀態一：客服人員立即可用。**最佳情況。顧客被告知真人即將加入，客服人員在 30 到 60 秒內接手，對話無縫延續。CSAT 的影響是正向的。

**狀態二：客服人員即將可用。**誠實告知預估等候時間（「大約 4 分鐘後會有客服人員加入」）。顧客可以選擇：留在聊天中等候，或留下聯絡資訊，改以電子郵件或電話接收回覆。機器人不會試圖用更多的機器人對話填補等候時間——它會就此停下。

**狀態三：沒有客服人員可用（非上班時段）。**大多數轉接就是在這裡崩潰的。機器人要嘛假裝有客服人員即將加入，結果一路等到逾時；要嘛聳聳肩說「客服已下班」，然後就此撒手不管。這兩種做法都不能接受。正確的做法，是建立一張結構化的工單，內含推測意圖、識別資料與完整的脈絡承載內容——並明確告知顧客真人何時會回覆，而且真的信守這個承諾。

潛在客戶收集表單，是狀態三裡的無名英雄。一個會說「目前沒有真人在線上，但如果你留下電子郵件，並簡短說明你的需求，我會確保明天早上 9 點有人回覆你」的聊天機器人，和「客服目前離線，請寄信給我們」有本質上的不同。前者感覺像是一次轉接，後者感覺像是被放棄。

如果你是在 Agentkit 上打造這套流程，潛在客戶收集動作正是能把狀態三，轉變為可挽回體驗的基礎元件：結構化欄位、經過驗證的資料，直接送進實際會回覆的團隊收件匣。

轉接決策樹

以下是表現最強的部署案實際採用的邏輯，經過簡化。

On every customer message:
  if explicit_human_request:
    handoff(reason="explicit", priority="immediate")
    return

  if message_classifies_as_sensitive_topic:
    handoff(reason="sensitive", priority="high")
    return

  if sentiment_score < threshold OR emotion in {anger, frustration}:
    handoff(reason="emotional", priority="high")
    return

  if customer_segment in {VIP, churn_risk}:
    handoff(reason="vip", priority="elevated")
    return

  attempt_bot_response()

  if customer_rejects_two_in_a_row:
    handoff(reason="dissatisfaction", priority="normal")
    return

這段虛擬碼有兩個地方，與常見的粗糙實作方式明顯不同。

首先，對於好幾種觸發條件，轉接檢查會在機器人嘗試作答之前就先執行。一個常見的錯誤，是讓機器人先回答，只有在答案失敗時才考慮升級轉接——那正是常見問題式循環被寫進程式碼裡的樣子。對敏感主題而言尤其如此：機器人不該先試一次，而應該立刻轉接。

其次，不滿意觸發條件需要真正偵測到顧客表達了「不」——這正是提示詞工程發揮作用之處：機器人需要一套結構化的方式，把「這沒有幫助」辨識為一種狀態，而不是繼續尋找下一個常見問題答案。我們在聊天機器人提示詞工程一文中，詳細討論過這部分的提示詞設計。

衡量轉接是否奏效

如果轉接就是那道接縫，你需要的是衡量接縫本身的數字，而不是機器人或真人單獨的表現。以下四項值得追蹤：

第一項指標，是產品團隊長期以來最少被量測的一項。從機器人說出「讓我幫你找人」，到真人真正加入之間，若等候了 90 秒，那正是聊天機器人累積的好感瞬間蒸發的地方。你不衡量它，就無法修正它。關於更完整的指標體系，請參閱聊天機器人 KPI 與指標。

Agentkit 適合扮演的角色

轉接不是單一功能，而是由多個基本元件拼接而成的模式。以下是 Agentkit 這一側真正重要的元件：

• 潛在客戶收集與自訂表單——轉接觸發時，機器人以結構化方式收集識別資料與推測意圖摘要的方法。所有方案皆可使用。
• Webhook 與 Zapier——將脈絡承載內容遞送到你的真人團隊實際使用的收件匣、服務台或 CRM（Intercom、Zendesk、HubSpot、Linear、Slack）的傳遞管道。Hobby 方案（$29.99/月）以上適用。
• 問與答——為那些永遠不該升級轉接的問題，提供高精準度、手動調校的答案。釘選的答案能減少誤判造成的轉接。
• 提示詞自訂——你在此撰寫觸發邏輯的地方：「如果顧客提到超過 $50 的退款，不要嘗試作答，改為收集他們的訂單與電子郵件。」
• 聊天記錄——用來衡量觸發條件分布、轉接所需時間，以及轉接後結果的分析介面。

坦白說：Agentkit 並不會取代你的服務台。它是那扇前門，決定哪些對話該由機器人處理、哪些該進入收件匣，以及雙方在接手時各自知道些什麼。把前門當成整棟建築來看待，正是那些 Klarna 式的公司，在過度押注 AI 之後，又得重新聘回客服人員的原因。

轉接設計檢查清單

在把聊天機器人推上線給真實使用者之前，轉接正是最該壓力測試的部分。最基本的檢查項目包括：

1. 不論用什麼措辭、什麼語言，只要顧客要求真人，機器人就會立即轉接。
2. 機器人至少能偵測並轉接三種非明確表達的觸發條件（至少包含情緒、敏感主題、重複不滿）。
3. 脈絡承載內容包含推測意圖與觸發原因，而不只是逐字稿。
4. 非上班時段的流程會收集結構化的聯絡資料，並設定明確的期望，而不是一句空泛的「我們會再與你聯絡」。
5. 轉接所需時間有被量測，並與分流率顯示在同一個儀表板上。
6. 轉接後的 CSAT 與機器人自行解決的 CSAT 分開追蹤。
7. 一旦轉接被觸發，機器人就會停止繼續嘗試提供協助，只會說「客服人員即將加入」，然後等待。

最後一項看似微小，卻很重要。已經升級轉接後還持續推薦文章的聊天機器人，會顯得急切又笨拙。正確的做法，是乾脆地停下，並顯示明確的「你正在排隊等候」狀態。

2026 年的定調

開頭那兩個數字之間的張力——80% 由 AI 處理，79% 偏好真人——並不能靠選邊站來化解。答案在於理解：那 79% 的人，並不是在抽象意義上排斥 AI，他們排斥的是糟糕的轉接。過去十五年來，每一套「請按 1 使用英文」的語音選單，以及每一個不斷循環常見問題的客服機器人，都在訓練他們認定：一旦自己想要真人，系統就會跟他們對抗。

2026 年真正勝出的部署案，是那些顛覆這個假設的做法。機器人能處理的時候就負責處理，不能處理的時候，轉接就快速又乾淨。顧客感覺自己被引導，而不是被困住。這種體驗不是內建在模型裡的，而是被設計出來的。

機器人處理的那 80% 只是基本門檻，它分派出去的那 20%，才是決定顧客忠誠度的地方。

免費建立你的聊天機器人 →

不需信用卡。

延伸閱讀：

• 為什麼顧客討厭 AI 聊天機器人（以及如何打造他們不討厭的那種）
• 聊天機器人 vs. 即時客服：哪個適合你的公司？
• 聊天機器人潛在客戶開發：收集、篩選、轉換
• 客服聊天機器人：部署、調校、衡量