客服機器人轉真人的目標，是讓客戶在需要協助時抵達能處理問題的人，並讓接手人知道對話進行到哪裡。若只設計一個「轉真人」按鈕，卻沒有指定接收團隊、工作狀態與無人值班時的安排，客戶仍可能重複提問或停在沒有下一步的畫面。
以下使用虛構零售情境：客戶在 LINE 詢問退貨，機器人先說明已核准的一般程序；遇到個別訂單或例外，就交給客服確認。說明政策與核准退款是不同工作。機器人不能因為客戶提出要求，就聲稱退款或訂單變更已經完成。
先確認帳號、服務工具及實際連接路徑。imBee 的公開收件匣頁面列有 LINE 管道，但指定帳號的接入方式、權限及功能仍須確認。產品有列出一個管道，不能代替帳號的設定與驗收，也不能推出所有帳號都具有相同功能。
把第一個使用範圍限制在一種常見問題，並定義完成條件。客戶知道下一步、查詢進入指定待處理清單、客服有背景並接受處理，才形成一個可以驗證的交接。若需要讀取訂單系統，也要另行確認資料連接與存取權限。
不要只用「機器人答不了」作為轉交條件。這個說法難以測試，也容易讓機器人繼續猜測。先列出可觀察的情況，例如客戶直接要求真人、問題超出知識範圍、必要資料不足、政策內容衝突，或處理需要特定權限。
每種情況應對應一個目的地及對外說明。需要退款例外的查詢，可能交給具備決策權限的人；一般操作問題可交客服。實際分類由團隊確認，不應為了自動化而建立沒有人負責的待處理清單。簡單且有負責人的路徑，比複雜但無法維護的分類更有用。
把未知資訊與客戶事實分開。如果客戶只說「東西有問題」，機器人不能自行推定商品故障、退款資格或訂單編號。可按核准流程提出必要問題，或轉交人員判斷。不要讓摘要把推測變成後續處理的事實。
也要設定重複失敗時的轉交規則。客戶已說明同一問題，卻一再收到無關回答，應有可用的人工出口。這是團隊選擇的服務設計，具體次數及觸發方式要依實際情境驗收，不是所有管道通用的固定數字。
| 情況 | 處理方式 | 需要確認 |
|---|---|---|
| 明確要求真人 | 進入人工路徑 | 目的地及可用狀態 |
| 知識沒有涵蓋 | 保留未知，轉交客服 | 問題與已有回覆 |
| 需要例外核准 | 轉交有權限人員 | 決策責任 |
| 資料不足 | 必要澄清或人工跟進 | 不虛構資料 |
| 內容互相衝突 | 交負責人核實 | 有效來源版本 |
好的交接讓客服可以繼續處理，而不是要求客戶把剛說過的話全部重講。背景應包含客戶原始問題、已提供的說明及轉交原因。若使用摘要，也保留可核對的對話來源，讓人員能辨識是否漏掉重要條件。
不要把所有資料都塞進一段摘要。與目前任務無關的個人資訊可能沒有必要傳遞。先定義哪些欄位有助於接手，再確認資料來源及使用權限。缺少的資料應標示為待確認，不能為了填滿表格而補寫內容。
例如虛構退貨查詢的摘要可以寫明：客戶詢問例外、機器人已說明一般程序、需要客服審查。不能寫成例外已獲核准。若沒有查過訂單系統，也不應把付款或物流狀態描述成已知。
摘要與實際動作必須分開。接手人要知道哪些資訊只是對話陳述、哪些已經由系統驗證，以及哪些動作尚未完成。這樣可以避免客服根據一段流暢但不可靠的文字，誤以為前一個步驟已經辦妥。
| 交接內容 | 應包含 | 應避免 |
|---|---|---|
| 問題 | 客戶的需求及必要條件 | 把推測寫成事實 |
| 已有回覆 | 機器人說明過的內容 | 宣稱未驗證的操作 |
| 轉交原因 | 需人工判斷或補充資料 | 模糊的『有問題』 |
| 狀態 | 待接受、已接受或待核實 | 預設已處理完畢 |
轉交後要有明確負責人與狀態。查詢進入某個待處理清單，不等於已經有人接受。團隊應能看出待接受、已接受及仍需其他人協助的工作，並知道誰要檢查未處理項目。這些狀態不一定需要複雜系統，但必須在實際流程中可觀察。
多人協作時，確認一個對話由誰主導回覆，何時可以重新指派，以及原負責人如何知道責任已經移交。否則可能出現多人同時回覆，或每個人以為別人已接手。以具體演練確認責任變更，比只閱讀權限表更直接。
非服務時間也需要安排。客戶應看到真實的聯絡或待處理說明，不能被承諾即時回覆。確認工作如何留在可見清單，以及恢復服務後由誰接受。不要把自動回覆已發送當作查詢已解決。
imBee 公開資料描述指派與團隊協作。指定帳號、管道、待處理清單及權限仍需實際測試。此處提供交接需求，不聲稱任何團隊已經完成設定，也不承諾固定回應時間。
準備虛構案例，分別從客戶端及客服端執行。客戶提出轉真人要求，客服確認查詢出現在正確位置、對話內容完整，以及能接續回覆。記錄實際結果，不只截取按鈕顯示的畫面。
測試一般問答、缺少資料、要求例外、沒有可用職員及重新指派。對每個案例寫下預期結果、來源及驗收人。若某個管道或帳號不支援預期功能，把它列成待解問題或調整流程，不要把另一個管道的成功結果套用過去。
保存失敗與修正後的測試。需要讀取訂單或執行動作的流程，另行驗證系統連接、權限及結果。機器人說「已處理」不是完成證據。人工接受查詢與完成客戶請求也要分開記錄。
測試資料不必使用真實客戶資訊。日後如果要從實際對話整理案例，先確認資料處理、存取及審核方法。清楚標示測試背景，使團隊不會把示範情境當成實際服務承諾。
先讓已經驗收的範圍投入使用，其他問題保留人工出口。操作人員要知道來源、責任、錯誤回報方法及例外待處理清單。不要只向專案團隊說明流程，卻讓日常接手人員自行猜測。
觀察重複提問、缺少背景、無人接受及錯誤指派。成功指標應反映客戶是否抵達合適人員、背景是否足夠及問題是否按團隊定義完成。轉接按鈕被點擊的次數，是使用量，不是交接成功數。
來源、指令、權限或值班安排改變後，重跑原有測試。新發現的失敗加入題庫，保留前後版本。這樣可以找出改善是否真的生效，以及有沒有讓原本通過的路徑退步。
擴展語言時，檢查觸發條件、客服摘要及對外說明的意思是否一致。導覽可以切換語言，不表示客服知識和實際帳號設定已經在該語言驗收。對每個預計投入使用的版本確認實際答案。
最好的交接不是把客戶快速推出機器人，而是讓下一位負責人能夠接續工作。明確條件、必要背景、接受責任及可核對結果，應一起構成驗收標準。
不算。還要確認目的地、必要背景、接手人接受及客戶的下一步。無人在線的情況也要測試。
仍須確認指定帳號、連接方式及方案的實際支援和設定。管道列名不能代替部署驗收。
進入已定義且可用的人工路徑，提供真實下一步，避免反覆要求客戶先完成無關的機器人問答。
原始需求、必要事實、已提供的說明及轉交原因。標示待確認資料，避免傳遞無關資訊或把推測寫成事實。
保留可見的待處理工作，使用團隊可以履行的說明，並指定恢復服務後的接手責任。
看正確指派、背景完整、接受責任與實際處理結果。按鈕點擊量或自動訊息數本身不能證明成功。
資料、指令、權限、管道連接或值班安排改變時。增加語言也應檢查相應答案和交接說明。
與 imBee 討論客服交接流程透過產品示範，與我們討論你的通訊管道、團隊與對話轉接需求。
