顧客要求與真人交談。機器人說有人即將加入，卻一直沒人出現。要改善這種體驗，先決定請求會送到哪裡，以及由誰回覆。
這篇指南區分即時轉接與客服工單，並以 Agentkit 目前的升級處理行為說明設定上的限制。接著提供可依客服團隊調整的政策與驗收項目。產品細節於 2026 年 10 月 6 日查核。範例僅供說明，並非客戶成效。
該如何設計客服機器人交接真人的觸發條件？
針對明確要求真人、回答反覆無法解決問題，以及超出機器人權限的事項設定觸發條件，並在上線前逐一測試。Agentkit 可透過六個已連接的外部客服或 CRM 系統建立客服紀錄，但通用的 Escalate to Human 動作不會讓真人加入聊天。
選擇接收目的地，收集該目的地需要的聯絡資訊，並告訴顧客接下來會發生什麼事。成功建立工單只代表請求已記錄，不代表有人已讀取，或會在特定時間內回覆。
選擇團隊能實際提供的交接方式
即時轉接需要有人值班的管道，以及支援真人接續對話的整合。工單交接則記錄請求，供後續處理。顧客需要知道自己會獲得哪一種服務。
Agentkit 的通用 Escalate to Human 動作支援 Zendesk、Freshdesk、Help Scout、Intercom、HubSpot 與 Salesforce。目的地會收到工單、案件或對話，實際類型依服務供應商而定。Salesforce Live Chat 是另一個獨立動作。選擇 Salesforce 作為通用升級處理的目的地，會建立案件，而非即時聊天工作階段。
Agentkit Help Desk 是另一個內建目的地。它需要已儲存的對話、具有 Help Desk 存取權的方案，以及為該代理啟用 Help Desk。也必須有請求者的有效電子郵件地址。網站聊天工單在 Help Desk 收件匣中沒有回覆編輯器，也不會在小工具中新增真人即時回覆管道。啟用流程前，團隊需要另一個後續聯繫途徑，例如自己的客服電子郵件。
若使用外部目的地，先連接服務供應商，並確認方案支援該動作。接著為代理新增並啟用動作。使用不影響實際業務的測試請求，檢查權限與接收團隊的收件匣。
依客服決策設計觸發條件
從團隊能解釋的決策開始。不要把每次提及「真人」或每句負面表達，都當成同一種請求。
| 觸發條件 | 範例 | 要測試的政策 |
|---|---|---|
| 明確要求 | 「請讓我跟真人交談。」 | 提供實際支援的客服途徑，並收集必要的聯絡資訊。 |
| 反覆無法解決 | 「這個回答還是沒有解決我的問題。」 | 停止重複相同建議，並提供升級處理選項。 |
| 超出機器人權限 | 有爭議的扣款，或變更帳號存取權的請求 | 交由負責團隊處理，不要自行編造決定或確認未經授權的變更。 |
| 急迫或挫折 | 「我的帳號被鎖住，沒辦法工作。」 | 盡快提供協助，同時說明實際的後續聯繫管道。不要承諾無人值班的緊急回應。 |
| 已驗證的客戶規則 | 已知帳號符合不同客服途徑的資格 | 使用可信的客戶資料與已設定的途徑。訪客自稱 VIP 並不代表身分已驗證。 |
這些是建議政策，不是內建的確定性觸發開關。Agentkit 動作中的 When to use 指示會引導模型。自然語言指示需要以不同說法與支援語言測試。單靠這些指示，並不能提供可靠的情緒評分、VIP 查詢或固定的回答拒絕次數計數器。
Intercom 的升級處理文件區分自然語言指引、依資料設定的規則，以及升級後的分派。這些區分有助於評估流程，但不表示 Agentkit 實作了 Intercom 的規則系統。
提供真人需要的實用脈絡
針對已連接的外部服務，Agentkit 升級處理會收集主旨、問題摘要、有效電子郵件地址，以及可取得時的姓名。工單脈絡最多包含最近 50 則已儲存的非工具訊息。每則呈現的訊息上限為 2,000 個字元。可取得時，也會包含目前的請求。
這是有範圍限制的脈絡，不是提供完整逐字稿的承諾。摘要上限為 2,000 個字元，主旨上限為 150 個字元。呈現的對話紀錄包含訊息文字，不包含附件檔案。接收端服務供應商也可能有其他限制。在較長的聊天中，可能需要在摘要再次說明較早的訂單編號。確認所選目的地實際顯示哪些內容。內建 Help Desk 工單會連結至已儲存的對話，不要假設其畫面與外部供應商的工單內文相同。
只詢問團隊需要的資訊。輸入的電子郵件地址可供後續聯繫，但不是顧客擁有某個帳號的證明。不要要求訪客在聊天中貼上密碼、付款卡資料或私人憑證。
實用的摘要應說明顧客需要什麼、機器人已嘗試什麼，以及還有哪些問題未解決。若團隊需要標示升級原因或指定佇列，應設定並驗證該流程，不要假設通用動作會自動提供。
說明後續安排，不要編造可用性
使用工單流程時，告訴顧客客服會透過約定的管道聯繫。只有在接收團隊負責且能履行時，才提供回覆時間承諾。不要只因為建立了工單，就說「客服人員即將加入」。
針對非服務時間的請求，收集必要的電子郵件地址與問題摘要，再回報實際建立結果。若連線已失效或工單建立失敗，提供可用的替代聯絡途徑。令人安心的訊息不能取代缺少的客服紀錄。
Chatbase 的 Zendesk 整合公告也明確區分這兩種管道。其工單流程透過電子郵件後續聯繫，Sunshine 整合則是另一條即時聊天途徑。承諾即時轉接前，先確認實際整合。
可調整的示範指示
以下政策是工單流程的起點，不是經過測試的分類器或可執行的分派規則。範本以英文提供。
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
將觸發條件指引放在動作的 When to use 指示中，並讓顧客看到的後續安排與代理指示一致。測試完整流程，包括接收端的收件匣，不要只檢查機器人的措辭。
上線前檢查流程
使用虛構請求與你能控制的客服地址。下列案例是驗收表，不是已執行的測試結果。
| 測試案例 | 要確認的事項 |
|---|---|
| 明確要求真人 | 收集必要資料後，提供或呼叫正確且已啟用的動作。 |
| 兩次未解決的回答 | 機器人提供升級處理，而非重複相同建議。這個門檻是你的測試政策，不是內建計數器。 |
| 對話或聯絡人紀錄中沒有已知的電子郵件地址 | 嘗試建立紀錄前，機器人先詢問有效電子郵件地址。 |
| 長對話 | 接收紀錄包含實用的近期脈絡，重要的較早資訊保留在摘要中。 |
| 服務供應商已中斷連線 | 機器人回報失敗，並提供已設定的替代客服途徑。 |
| Help Desk 已停用 | 不宣稱已成功建立內建工單。 |
| 非服務時間的請求 | 機器人正確說明後續聯繫，不編造即時佇列或回覆時間。 |
| 重複要求升級處理 | 檢查是否重用既有紀錄，以及顧客是否取得正確狀態。 |
記下接收紀錄的 ID，並確認指定團隊能找到它。在每個提供服務的語言中，重複測試觸發案例。聊天中看似正確的訊息，只是驗收的一部分。
分別衡量建立紀錄與真人回覆
追蹤升級嘗試、成功建立紀錄、傳遞失敗，以及第一次真人回覆所需的時間。使用接收端客服系統的時間戳記或自行設置的量測方式計算回覆時間。僅靠 Agentkit 對話紀錄，無法建立完整的交接時間或交接後滿意度儀表板。
抽查已升級的案件，找出缺少的脈絡與重複詢問。若調查滿意度，應在分數旁保留回覆數與管道。聊天機器人 KPI 指南說明為何「不需真人介入」與「問題已解決」需要分別定義。
先從一個支援的目的地與負責後續處理的團隊開始。設定升級處理動作，執行驗收案例並確認接收成功，再邀請顧客使用。
相關閱讀：
