AO2 / INSIGHTS — 把知識變成下一步

聊天機器人如何把問題交給真人,才不必重新問一次?

READING INDEX

這篇指南怎麼讀

先理解問題,再選擇方法。把值得採用的一步,帶回日常工作。

聊天機器人真人接手概念封面:讓接手的人看見同一問題,以幾何圖示呈現本文的資料與判斷關係。
AO2 原創主題視覺|讓接手的人看見同一問題

AO2 FIELD GUIDE · N056 · AI 問答與 RAG 應用

聊天機器人真人接手需保留已確認條件、待解問題與來源,並追蹤接單及回覆狀態。附交接資料規格與例外清單,避免送出通知就宣稱完成轉接。

轉接不是把整份對話丟給客服,而是讓合適的人知道客戶要完成什麼、哪些資訊已確認,以及還缺哪一個判斷。使用者也應知道目前是排隊、已接單還是需要補資料,不必從頭再說一次。

聊天機器人真人接手:先定義觸發與責任

需要人工判斷、資料衝突、權限不足或使用者明確要求聯絡人,都可能觸發接手。先列出原因與分派角色,避免所有問題都丟進同一信箱。技術選型可能由產品或工程窗口處理,售後則需要設備與故障條件;若分派責任不清,對話摘要再完整也只會停在等待。

轉接前清楚告知將交出哪些資料、用於什麼目的,以及接下來如何聯絡。只收集完成任務必要的資訊,不要求使用者在一般聊天框輸入密碼、病歷或不必要的個人資料。涉及限制文件時,交接本身也要遵守權限,不能因接手者是同事就整包轉寄。

人工接手資料規格
欄位內容注意事項
案件 ID同一邏輯交接的識別碼重試沿用並核對
需求摘要客戶要完成的決定事實與推測分開
已知條件型號、版本與用途避免再次詢問已提供資料
待確認缺少資訊或衝突點指定判斷角色
來源及回覆已引用文件與先前說法保留版本與權限

摘要應分清使用者事實、系統推測與待確認

把客戶已說明的型號、版本與需求列成可核對欄位,另列系統提供過的來源與尚未解決的問題。若 AI 推測使用情境,明示為推測,不寫成客戶確認。需要時讓使用者看見摘要並修正,再送交接單;避免語句精簡後反而改變原意。

假想 IoT 模組詢問:客戶提供硬體型號但不知道韌體版本,AI 找到兩份適用條件不同的文件。交接單應保留已知型號、缺少版本、兩份來源及衝突功能。不能只寫「客戶詢問相容性,請回覆」,否則接手人仍要重新閱讀整段對話並再次索取相同資料。

送出、接收與完成回覆是三個狀態

建立案件後,記錄交接識別碼、分派角色與目前狀態。通知成功只表示訊息送到某個系統,不代表有人接受處理;有人接單也不代表已回覆客戶。將這些狀態分開,並讓使用者看得懂目前進度。無法承諾回覆時間時,說明處理方式與可替代入口,不填入未經核准的服務時限。

交接狀態與例外
狀態/情境對使用者說明內部驗收
已送出已建立待處理事項可查案件與分派
已接單對應窗口正在處理有負責人與時間
待補資料只列缺少的必要條件原資料不重複索取
無人可接提供留言或替代聯絡方式有後續處理責任
接口失敗明示尚未完成與可用退路可重試且不重複建單

Microsoft 的 一般接待平台交接文件示範以轉接訊息與上下文銜接真人,且特定平台整合可能需要開發與接待系統能力。它不是所有聊天機器人自動具備的功能;導入前仍要確認實際通路、接口、排隊與分派方式。

沒人在線與接口故障都要有可完成的退路

非服務時段可以改建待辦,告知使用者已留下什麼、如何補充與查詢;不要顯示永遠等不到人的「正在連線」。若接口失敗,保留必要的安全紀錄與可重試狀態,讓使用者能用替代方式聯絡。重新送出時以原交接識別碼核對,避免同一件事建立多筆案件。

使用者離開後回來,也應能接續案件狀態,而不是強迫再跑一次問答。接手者要求補資料時,將問題限縮到真正缺少的條件。若需要轉給另一團隊,保留前一位處理者的判斷與轉派原因,避免每一層都把案件退回使用者重新敘述。

用例外情境驗收交接品質

測試要包含已知條件完整、必要欄位缺漏、使用者更正摘要、沒有可用接手者、接口逾時及重複送出。由實際接單角色查看案件,確認能否辨認問題與來源。若只有開發者看到成功訊息,而業務收件匣沒有可處理資料,流程尚未通過驗收。

涉及生技製藥的詢問,尤其要將一般商務聯絡與專業判斷分派清楚。對話可協助收集適當的非敏感需求,不能在未取得合適條件與審核時作產品、醫療或法規承諾。結案紀錄也應連回實際回覆,讓知識維護者知道哪些問題值得補成核准內容,而不是只統計轉接次數。

常見問題

整份對話都交給業務不是最完整嗎?

整份對話適合回查,不一定適合快速接手。交接摘要可固定包含需求、產品與版本、已確認條件、仍未解問題、引用來源及承諾過的下一步,並保留必要對話位置供查核。讓業務先看摘要,再視需要讀原文;不要把模型猜測混入已確認事實。驗收時請未參與對話的人接手,確認是否還需重問已知資料,並檢查摘要與原始紀錄有沒有矛盾。

寄出通知就能顯示已轉接嗎?

不能直接等同。至少區分已建立轉接案件、已通知、有人接單及已回覆四種狀態,為每種狀態指定可確認的紀錄與負責人。若通知失敗,保留案件並安排重試或替代窗口;若通知成功但無人接單,則按已定義的規則升級處理。測試通知失敗與無人回應兩種情境,確認使用者不會一直看到「已有人處理」卻實際沒人接手。

接手後還能回到機器人嗎?

可以,但應有明確的處理權切換。人工接手後,機器人應知道哪些內容可以繼續回答、哪些案件需等待真人;交回機器人時保存處理結果、未完成事項與可使用資料。若人工與機器人同時更新狀態,需有衝突處理規則。驗收時模擬接手、人工補資料、回交與再次追問,確認不重複通知,也不將內部備註帶入對外回答。

來源與方法範圍

查核日期:2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明;工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例,不作客戶實績、產品資格或效果背書。

KEEP EXPLORING

把觀點,連成自己的方法。

從同一個問題延伸,繼續找出能在企業現場採用的做法。

YOUR NEXT STEP

讓下一步,從具體的問題開始。

帶著目前的網站、產品資料或工作流程,和 AO2 一起釐清值得先改善的地方。

返回頂端