AI 客服遇到不知道的問題怎麼辦？設計誠實回覆與查證流程
整理 AI 客服遇到資料缺口時的判讀、誠實回覆、必要追問、查證進度、人工交接與未知問題入庫流程。
當 AI 客服遇到資料不足，最重要的不是把空白補成流暢答案，而是讓顧客知道哪些事已能確認、哪些仍待查，以及下一步如何取得依據。實務上，缺口可能來自資料沒有涵蓋特定情境、顧客尚未提供必要條件，或答案需要核對即時紀錄。本文整理一套從辨識缺口到回寫知識的流程，讓不確定有清楚出口，也不把一般說明誤當成個案結論。
什麼訊號代表來源不足
判斷來源不足，看的不是語氣是否流暢，而是回答裡每個關鍵主張能否追到可用資料。先把問題拆成對象、條件、時間、例外與顧客要採取的動作，再逐項對照核准知識、文件及本次對話提供的資訊。若資料只說明一般做法，卻沒有涵蓋眼前這個人、這筆訂單或這種情況，就不能把常見原則包裝成個案結論。
第一個訊號是找不到直接回答的段落，或搜尋只找到相近名詞，沒有相同條件與結果。第二是來源彼此衝突、版本或日期不明，或文件只談流程的一半。第三是問題需要帳戶、交易、庫存或即時狀態，但手邊只有靜態說明。第四是顧客的描述缺少辨識事項的必要細節，例如訂單是哪一筆，或操作發生在哪個步驟。
把缺口具體寫下來，比籠統標成「不知道」更能指引下一步。可記錄「已找到取消流程，但未找到此訂單是否完成取消的紀錄」，或「找到兩個版本，無法判斷哪份適用」。同時標明哪些部分仍可回答，例如已知的處理步驟與未知的個案狀態，避免因一項缺口而把整題都當成無解。
操作上可採三格判讀：有直接且適用的證據、只有一般原則、沒有足以支持的來源。第一格才可直接答覆；第二格要限定在一般資訊並詢問個案條件；第三格先暫停結論，轉入查證或交接。假設顧客問款項是否已退回，退款流程文件只能說明通常步驟，未能證明這筆款項的實際狀態，兩者應分開標示。
如何明確說明尚未確認
說明不確定，重點是把已知、未知與下一步分開，讓顧客不必從含糊的客套話猜答案。先用一句話回應問題，再交代根據什麼可以確認、目前缺少哪個證據，最後說明會如何補足。避免只說「可能」或「應該」後面接一個肯定結論；這種寫法把猜測藏在語氣裡，顧客仍會把它當成承諾。
可採用固定句型：「依目前可查到的＿＿，我能確認＿＿；但還不能確認＿＿，因為缺少＿＿。我會先＿＿，並在＿＿時再回覆你。」空格應填具體資料與動作，不要只寫「系統顯示」卻不指出是哪一筆、哪個欄位，也不要宣稱查過其實沒有查看的紀錄。
假設顧客問某筆款項是否已退款，資料只列出申請已送出。合適的答覆是：「我能確認退款申請已送出；目前沒有足夠資料確認款項是否已入帳。我會核對這筆申請的後續狀態，再告訴你查到的結果。」此例不補寫未知日期，也不推定相關單位已完成處理。
若只有一般知識而非個人紀錄，可明確標記適用範圍：「一般流程是＿＿；但這不能確認你的案件目前在哪一步。」如果來源互相矛盾，說明正在比對的資料及尚未採用哪個結論，不必把內部搜尋細節全交代給顧客。
用語也應與證據強度相稱：直接紀錄支持的事實可直接陳述；合理但未驗證的推測要明確標為可能性，並先確認對方是否需要依此採取行動；沒有來源時不提供推測性指示。送出前再檢查每句肯定語是否有對應依據，避免開頭謹慎、結尾卻保證結果。
先問哪個必要條件
問資料前先確認答案差異會不會改變處理方式。若缺少的條件不影響回覆，就不要把查詢負擔交給顧客；若可能導致不同建議或操作，才問最少的必要問題。客服可以先說明用途，讓顧客知道回答這一項是為了比對哪個流程，而不是例行索取一串資料。
把問題縮到一輪可回答的範圍：先問辨認紀錄所需的條件，再視結果追問下一個分支。不要一次列出所有可能資料，也避免要求密碼、完整付款資訊等不適合在對話中提供的敏感內容。若安全核對需由正式流程完成，就引導顧客到已確認的管道，不要請他把秘密貼進聊天。
假設顧客說無法登入，可能的分支包括忘記密碼、驗證未完成或看見特定錯誤。第一輪可問：「你目前停在哪個畫面？如果有錯誤文字，請貼上不含個人資料的部分。」這能先判斷要查哪一段說明；不必同時索取裝置、所在地、帳號資料與完整操作歷程。
對訂單、預約或交易類問題，通常要先界定是哪一筆紀錄與發生時間；但具體索取項目應依組織核准的查核程序決定，不能憑想像製作一套身分驗證規則。若顧客暫時無法提供，說明目前能提供的一般資訊、哪些部分仍待確認，以及可使用的替代聯絡方式。
提問後要回到原問題，不要讓蒐集資料變成目的。收到回答就檢查它是否真正補上缺口；若仍不足，指出還缺哪個條件及原因，再問一項。若取得資料後仍找不到證據，就停止追問，轉入查證或人工處理。
查證期間怎麼告知進度
查證需要時間時，先告訴顧客目前進到哪一步，而不是留下沒有回應的空白。進度訊息應有三項：已完成的查核、仍在等待或比對的資料、下一次更新會由什麼事件觸發。若尚無可靠完成時間，就不要編一個時限；只有確實能做到且已安排提醒時，才承諾何時再提供進度。
狀態文字要能被下一位接手者讀懂，例如「已核對顧客提供的紀錄，正比對適用版本」或「已送交負責人確認，尚未取得回覆」。避免只說「處理中」，也不要把已送出請求說成已完成。進度只能反映真實動作，未進行的查核不能寫成正在查。
更新節奏依問題風險與實際流程安排；如果一時沒有新結果，也可簡短說明仍在等待哪項資料，以及下一次更新的安排。若原定更新時間已過，應主動補充延遲原因與新的可行節點，不要等顧客再問才承認沒有進展。若根本不能預估節點，就說明下一個可觀察的事件，而非給出猜測日期。
假設訂單狀態要由另一位同仁核實，第一次訊息可說：「我已整理訂單識別資訊，正在等狀態紀錄確認；確認後會回覆結果。如果先收到新資料，我會提前更新。」這句只在確實已整理並送查時適用。若尚未送交，應改成「我會先整理必要資訊」，並在完成後再回報，不能預支未做的進度。
每次更新只保留顧客做決策所需的資訊：目前確定的事、仍未定的事，以及顧客此刻是否需要採取行動。內部工具細節或無關轉述不會讓結果更清楚。查證若影響顧客下一步，應清楚說明現在可等待、補資料，或使用已知的替代方式，並交代替代方式的適用限制。
何時轉交人工處理
轉人工的標準應先寫成可觀察條件，不能只靠模型自評「不確定」。需要個案帳務、權限或即時紀錄，而自助查詢拿不到；核准來源互相衝突；同一缺口在補問後仍未解；顧客的決策可能受錯誤答案實質影響；或對話出現投訴、急迫情況與特殊例外，都可列為轉交候選。實際條件要依組織風險與責任分工設定。
可設計簡單分流：能由已核准來源回答的一般問題直接答；可透過一項補充資料排除歧義的先問；涉及敏感判斷、衝突紀錄或超出授權的決定，先保留結論並交給負責角色。轉交不是把顧客推回起點，應附上已確認內容、缺少的證據、已問過的條件與顧客希望解決的事。
交接摘要使用中性描述，不寫「顧客不配合」等判斷。標明原始問題、已檢查來源及版本、互相矛盾處、下一個待確認問題，必要時引用對話中的關鍵原句。只帶完成工作所需資料；敏感欄位依既定存取規則處理，不在摘要複製不必要的完整資訊。
假設顧客提供的截圖與文字紀錄顯示不同狀態，系統不能自行選一個看似合理的答案。可先告知兩項資料不一致、暫不下結論，並說明已轉請能核對原始紀錄的人員確認；同時記下截圖時間與紀錄來源，避免接手者重新詢問顧客已提供的內容。
轉交後仍要讓責任清楚：說明接下來由哪個角色或管道回覆，若尚不能指定人名，就不虛構負責者；若需要補件，集中列出並說明原因。人工確認後，把已核實的答案帶回顧客原本的問題，說明適用範圍與限制，讓交接形成閉環而非只改變處理人。
如何將未知問題入庫
未知問題入庫的目的，是讓下一次能找到可引用的答案，而不是把對話原文堆成無人整理的資料夾。每筆紀錄先保留問題意圖、缺口類型、查證後的結論、證據來源與版本、適用條件、負責維護的角色及是否可公開回答。沒有可靠結論時，狀態就維持待查，不要把猜測寫進知識庫。
記錄前先去除姓名、聯絡方式、訂單識別碼與其他不必要個資，保留重現問題所需的最少脈絡。若多位顧客以不同說法詢問同一件事，可合併意圖但保留代表性問法；若看似相同、實際條件不同，就分開記錄，避免一個通用答案誤套到不同情況。
分類宜採能促成行動的缺口，例如沒有來源、來源過期、條件不全、資料衝突、需要個案紀錄或需要人工判斷。為每類指定下一步與負責角色，並設定何種證據到位才可關閉；「已讀」或「已討論」不能算答案完成。維護者應能回到來源核對，而非只相信舊筆記。
整理時依影響範圍與重複情形排序：可能導致錯誤操作的問題先核實，重複出現的問法可優先整理成清楚條目，單次例外則保留查核線索。排序不要用未證實的流量數字假裝精確；若沒有計數資料，可用實際收到的案例說明為何先處理某題。
答案完成後，以原始問法和常見改寫各自檢索一次，確認找到的是同一個核准答案，且例外條件清楚。再由內容負責者確認來源仍適用、更新時間和失效條件；涉及流程變更時同步更新舊版本或標示停用。下次遇到不確定問題時，也能沿用這筆記錄追查，直到有足夠證據才解除待查狀態。
下一步，可以挑一則最近無法確認的對話，依序標出缺少的證據、要問的必要條件和查證負責角色，再把核實後的答案整理入庫。想進一步了解 ReplyBot，請前往 ReplyBot 官網。