
AO2 FIELD GUIDE · N056 · AI 問答與 RAG 應用
聊天機器人真人接手需保留已確認條件、待解問題與來源,並追蹤接單及回覆狀態。附交接資料規格與例外清單,避免送出通知就宣稱完成轉接。
轉接不是把整份對話丟給客服,而是讓合適的人知道客戶要完成什麼、哪些資訊已確認,以及還缺哪一個判斷。使用者也應知道目前是排隊、已接單還是需要補資料,不必從頭再說一次。
聊天機器人真人接手:先定義觸發與責任
需要人工判斷、資料衝突、權限不足或使用者明確要求聯絡人,都可能觸發接手。先列出原因與分派角色,避免所有問題都丟進同一信箱。技術選型可能由產品或工程窗口處理,售後則需要設備與故障條件;若分派責任不清,對話摘要再完整也只會停在等待。
轉接前清楚告知將交出哪些資料、用於什麼目的,以及接下來如何聯絡。只收集完成任務必要的資訊,不要求使用者在一般聊天框輸入密碼、病歷或不必要的個人資料。涉及限制文件時,交接本身也要遵守權限,不能因接手者是同事就整包轉寄。
| 欄位 | 內容 | 注意事項 |
|---|---|---|
| 案件 ID | 同一邏輯交接的識別碼 | 重試沿用並核對 |
| 需求摘要 | 客戶要完成的決定 | 事實與推測分開 |
| 已知條件 | 型號、版本與用途 | 避免再次詢問已提供資料 |
| 待確認 | 缺少資訊或衝突點 | 指定判斷角色 |
| 來源及回覆 | 已引用文件與先前說法 | 保留版本與權限 |
摘要應分清使用者事實、系統推測與待確認
把客戶已說明的型號、版本與需求列成可核對欄位,另列系統提供過的來源與尚未解決的問題。若 AI 推測使用情境,明示為推測,不寫成客戶確認。需要時讓使用者看見摘要並修正,再送交接單;避免語句精簡後反而改變原意。
假想 IoT 模組詢問:客戶提供硬體型號但不知道韌體版本,AI 找到兩份適用條件不同的文件。交接單應保留已知型號、缺少版本、兩份來源及衝突功能。不能只寫「客戶詢問相容性,請回覆」,否則接手人仍要重新閱讀整段對話並再次索取相同資料。
送出、接收與完成回覆是三個狀態
建立案件後,記錄交接識別碼、分派角色與目前狀態。通知成功只表示訊息送到某個系統,不代表有人接受處理;有人接單也不代表已回覆客戶。將這些狀態分開,並讓使用者看得懂目前進度。無法承諾回覆時間時,說明處理方式與可替代入口,不填入未經核准的服務時限。
| 狀態/情境 | 對使用者說明 | 內部驗收 |
|---|---|---|
| 已送出 | 已建立待處理事項 | 可查案件與分派 |
| 已接單 | 對應窗口正在處理 | 有負責人與時間 |
| 待補資料 | 只列缺少的必要條件 | 原資料不重複索取 |
| 無人可接 | 提供留言或替代聯絡方式 | 有後續處理責任 |
| 接口失敗 | 明示尚未完成與可用退路 | 可重試且不重複建單 |
Microsoft 的 一般接待平台交接文件示範以轉接訊息與上下文銜接真人,且特定平台整合可能需要開發與接待系統能力。它不是所有聊天機器人自動具備的功能;導入前仍要確認實際通路、接口、排隊與分派方式。
沒人在線與接口故障都要有可完成的退路
非服務時段可以改建待辦,告知使用者已留下什麼、如何補充與查詢;不要顯示永遠等不到人的「正在連線」。若接口失敗,保留必要的安全紀錄與可重試狀態,讓使用者能用替代方式聯絡。重新送出時以原交接識別碼核對,避免同一件事建立多筆案件。
使用者離開後回來,也應能接續案件狀態,而不是強迫再跑一次問答。接手者要求補資料時,將問題限縮到真正缺少的條件。若需要轉給另一團隊,保留前一位處理者的判斷與轉派原因,避免每一層都把案件退回使用者重新敘述。
用例外情境驗收交接品質
測試要包含已知條件完整、必要欄位缺漏、使用者更正摘要、沒有可用接手者、接口逾時及重複送出。由實際接單角色查看案件,確認能否辨認問題與來源。若只有開發者看到成功訊息,而業務收件匣沒有可處理資料,流程尚未通過驗收。
涉及生技製藥的詢問,尤其要將一般商務聯絡與專業判斷分派清楚。對話可協助收集適當的非敏感需求,不能在未取得合適條件與審核時作產品、醫療或法規承諾。結案紀錄也應連回實際回覆,讓知識維護者知道哪些問題值得補成核准內容,而不是只統計轉接次數。
常見問題
整份對話都交給業務不是最完整嗎?
整份對話適合回查,不一定適合快速接手。交接摘要可固定包含需求、產品與版本、已確認條件、仍未解問題、引用來源及承諾過的下一步,並保留必要對話位置供查核。讓業務先看摘要,再視需要讀原文;不要把模型猜測混入已確認事實。驗收時請未參與對話的人接手,確認是否還需重問已知資料,並檢查摘要與原始紀錄有沒有矛盾。
寄出通知就能顯示已轉接嗎?
不能直接等同。至少區分已建立轉接案件、已通知、有人接單及已回覆四種狀態,為每種狀態指定可確認的紀錄與負責人。若通知失敗,保留案件並安排重試或替代窗口;若通知成功但無人接單,則按已定義的規則升級處理。測試通知失敗與無人回應兩種情境,確認使用者不會一直看到「已有人處理」卻實際沒人接手。
接手後還能回到機器人嗎?
可以,但應有明確的處理權切換。人工接手後,機器人應知道哪些內容可以繼續回答、哪些案件需等待真人;交回機器人時保存處理結果、未完成事項與可使用資料。若人工與機器人同時更新狀態,需有衝突處理規則。驗收時模擬接手、人工補資料、回交與再次追問,確認不重複通知,也不將內部備註帶入對外回答。
來源與方法範圍
查核日期:2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明;工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例,不作客戶實績、產品資格或效果背書。