AI 客服與真人客服，不是二選一

AI 客服擅長快速處理重複問題，真人客服擅長理解例外、情緒與責任。企業如果只問「哪一個比較好」，很容易選錯方向。

更實際的問題是：哪一段交給 AI，哪一段必須由人決定，以及交接時如何避免客戶從頭再說一次。

AI 客服適合處理的工作

AI 適合處理規則清楚、資料可查、結果容易驗證的工作，例如：

• 回答營業時間與服務範圍。

• 解釋商品規格與基本使用方式。

• 提供付款、運送與退換貨規則。

• 收集訂單編號與問題類型。

• 查詢已授權的訂單狀態。

• 將長對話整理成摘要。

• 在非營業時間先接住問題。

這些工作量通常大，但不一定需要高度人類判斷。

真人客服比較適合的工作

真人更適合處理：

• 規則以外的例外。

• 客訴、憤怒與信任修復。

• 退款、賠償與商業協商。

• 身分、帳號與資料安全事件。

• 需要跨部門確認的案件。

• 可能造成法律或重大財務影響的承諾。

• 公司尚未制定標準答案的問題。

真人的價值不只是說話更像人，而是能承擔判斷與責任。

七種情況應立即轉真人

一、客戶明確要求真人

不要用更多機器回答阻擋客戶。可以先收集必要資料，但應清楚說明後續安排。

二、AI 連續兩次沒有解決問題

重複改寫同一段答案只會增加挫折。系統應辨識重複追問或負面回應。

三、涉及退款、賠償或例外授權

AI 可以說明一般規則和收集資料，但最終決定應依企業授權流程處理。

四、涉及個人資料或帳號安全

包含疑似盜用、付款異常、密碼與身分驗證。此時需要安全流程，而不是一般問答。

五、客戶情緒明顯升高

當客戶表示生氣、受騙、要投訴，或使用強烈負面語句，應優先由真人接手。

六、知識庫沒有可靠答案

AI 應清楚表示需要進一步確認，不能用看似合理的內容填補空白。

七、答案可能造成高風險後果

醫療、法律、財務、安全及重大合約承諾，都不應由一般客服 AI 自行做決定。

好的轉接流程長什麼樣？

最差的轉接，是顧客等了很久後，真人第一句又問：「請問發生什麼事？」

好的交接應把以下資訊一起交給真人：

• 客戶的原始問題。

• 已確認的訂單、商品或帳號資訊。

• AI 已提供過的答案。

• 尚未解決的核心問題。

• 轉接原因與風險標示。

• 客戶目前的情緒或急迫程度。

真人應先確認自己已看過摘要，再補問缺少的資訊。

AI 與真人的建議分工

第一層：AI 接待

辨識問題、回答基本資訊並收集必要資料。

第二層：AI 查詢與整理

在權限允許下查詢訂單或會員狀態，整理案件摘要。

第三層：真人判斷

處理例外、情緒、退款、客訴與需要授權的決定。

第四層：回饋知識庫

把真人經常補充的答案整理成正式規則，讓 AI 下次可以處理。

這是一個循環，而不是一次安裝完成的專案。

不要只用「AI 解決率」評估成效

如果只追求讓 AI 不轉真人，系統可能會把本來該交接的案件留太久。

更合理的指標包括：

• 客戶是否需要重複說明。

• 第一次有效解答率。

• 平均解決時間。

• 轉接後真人是否取得完整摘要。

• 錯誤回答與客訴數量。

• 哪些問題持續無法回答。

• 客戶在解決問題後的滿意程度。

有些轉接是系統正確辨識風險，不應全部視為失敗。

中小企業如何開始？

先選一個客服量高、規則清楚的場景，例如出貨進度或退換貨說明。

接著：

1. 整理正式答案。

2. 標出 AI 不能決定的範圍。

3. 設定七種轉真人條件。

4. 建立交接摘要格式。

5. 用真實對話測試。

6. 每週檢查錯答與不必要的轉接。

當這一個場景穩定後，再擴大到下一類問題。

常見問題

AI 客服可以取代全部真人客服嗎？

大多數企業不適合。AI 能減少重複工作，但例外、情緒、責任與授權仍需要真人。

轉真人是不是代表 AI 失敗？

不一定。遇到高風險或資料不足時正確轉接，反而是安全設計成功。

AI 客服可以在下班時間處理什麼？

可以回答基本問題、收集資料、查詢已授權資訊並建立案件，但要清楚說明真人回覆時間。

如何避免客戶重複說明？

轉接時把對話摘要、已確認資料、已嘗試的答案與轉接原因一起交給真人。

建議內部連結

• 「AI 客服」連回 `/ailab/zh-tw/blog/what-is-ai-customer-service`。

• 「知識庫沒有可靠答案」連到 AI 客服知識庫教學。

• 「自己架設」連到自架 AI 客服文章。

• 從 `/ailab`、`/ailab/knowledge` 與相关文章加入「AI 客服真人接手」錨文字。

---

Codex 更新指示

1. 不要建立新網址，更新上述六個既有頁面。

2. 保留原頁面已存在且正確的產品資訊；本文內容作為主要新版正文。

3. 每頁只保留一個 H1，文章中的主要段落使用 H2，子段落使用 H3。

4. SEO title、meta description 與 canonical 必須寫入頁面 metadata。

5. FAQ 要顯示在頁面正文中；只有內容與頁面可見文字一致時，才加入 FAQ 結構化資料。

6. 在 `/guides`、`/ailab`、`/ailab/knowledge` 與相關文章補入上述內部連結。

7. 不要修改既有 slug，也不要把英文 `/guides` 文章改成中文。

8. 更新後執行網站 build、路由檢查、頁面 metadata 檢查與站內死連結檢查。

9. 確認 MyQi 隱私政策與正式系統確實符合「原始餐點照片不作長期保存，只保存使用者確認的結構化營養結果」；若正式行為不一致，先修正正文與政策，不可直接發布該段。

10. 發布後重新提交 sitemap，並在 Search Console 持續比較這六頁的曝光、平均排名與點擊率。