{"content_id":"2doywe7tfr","slug":"why-ai-chatbots-do-not-reduce-call-center-calls","locale":"zh-hant","schema_type":"TechArticle","category":"ai_data","category_name":"AI 資料","title":"即使有AI聊天機器人，客服中心來電仍不減的原因","summary":"即使聊天機器人的使用者增加，若缺乏處理權限、情境理解與真人客服銜接，客服中心的來電與營運成本仍可能無法減少。應衡量客戶的問題是否獲得解決，而非自動處理率，並設計讓AI與客服人員共享情境的完整旅程。","sponsorship_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["聊天機器人使用量增加，可能代表諮詢需求與接觸點增加，因此無法直接證明客服中心來電有所減少。","說明資訊的能力，與實際處理退款、取消及帳戶變更的權限，是彼此不同的能力。","聊天機器人失敗後打進來的電話會集中於複雜案例，因此即使通話量相同，平均處理時間與情緒勞動也可能增加。","有效的轉接會將對話摘要、客戶驗證狀態、已執行的措施與失敗原因一併傳遞給客服人員。","核心績效指標應著重於旅程完成率、再次諮詢率、總解決時間與客戶付出的努力，而非單純的攔截率。"],"content_markdown":"AI 聊天機器人的對話量大幅增加，並不代表客服中心的來電或諮詢成本會自動減少。聊天機器人回答問題，與徹底解決客戶的問題是兩回事；失敗的自動化反而可能將更複雜、情緒更激動的詢問推向人工客服。\n\n在營運現場觀察到的核心悖論如下：聊天機器人的使用量增加，但整體來電量幾乎維持不變，而客服人員收到的詢問難度與平均處理時間卻有所上升。要理解這種現象，不能只看各管道的使用量，而必須檢視客戶完整的問題解決旅程。\n\n## 聊天機器人使用量與來電減少不一致的原因\n\n聊天機器人使用量並非結果指標，而更接近接觸點的活動量。僅憑訪客增加、擴大聊天機器人曝光、變更應用程式內的入口位置，或原有 FAQ 使用者轉移管道，對話件數就可能增加。\n\n例如，即使聊天機器人對話增加了 300%，在下列情況下，來電量也不會減少。\n\n- 訂單與訂閱用戶同步增加，帶動整體諮詢需求上升。\n- 原本使用搜尋與 FAQ 的使用者轉向聊天機器人，但電話使用者仍然不變。\n- 同一位客戶使用聊天機器人後，又針對同一問題來電。\n- 聊天機器人成為新的諮詢入口，讓過去可能放棄的客戶也開始尋求協助。\n- 需要透過電話處理的複雜問題，其占比並未下降。\n\n因此，分析時除了單純的對話件數，還必須分別檢視下列指標。\n\n| 指標 | 計算方式或意義 | 注意事項 |\n|---|---|---|\n| 電話接觸率 | 電話諮詢件數 ÷ 訂單數、訂閱數或活躍客戶數 | 必須校正因業務成長造成的諮詢量增加。 |\n| 轉接率 | 轉為人工客服的聊天機器人工作階段 ÷ 聊天機器人總工作階段 | 低並不一定代表好。隱藏轉接按鈕也可能使其降低。 |\n| 再次詢問率 | 在一定期間內針對同一問題再次聯絡的客戶比例 | 即使管道不同，也必須辨識是否為同一問題。 |\n| 旅程完成率 | 實際完成目標作業的客戶 ÷ 嘗試該作業的客戶 | 必須區分提供回答與實際處理完成。 |\n| 首次接觸解決率 | 無須額外聯絡，便在首次互動中解決的比例 | 若客服人員未經客戶確認便自行標記完成，數據會失真。 |\n| 總解決時間 | 從首次接觸到最終解決所經過的時間 | 也應包括等待、管道切換與重新驗證的時間。 |\n| 平均處理時間 | 客服作業所耗總時間 ÷ 處理件數 | 自動化後若只剩困難案例，該數值可能上升。 |\n\n## AI 即使回答也無法解決問題的三項結構性限制\n\n### 1. 說明能力與執行權限的差異\n\n生成式 AI 能快速說明政策、使用方法、商品資訊等文件中已有的內容。然而，客戶的實際需求往往包含多個階段的業務處理。\n\n例如，客戶要求「我已取消訂閱卻又被扣款，請幫我退款」時，系統可能必須執行下列作業。\n\n1. 驗證客戶及帳戶。\n2. 查詢取消時間與付款紀錄。\n3. 判定是否為重複扣款或符合退款條件。\n4. 確認核准權限與例外政策。\n5. 執行退款並記錄結果。\n\n若聊天機器人未連接內部付款、訂單系統，或沒有執行權限，就只能提供說明。若客戶必須自行尋找選單重新處理，即使從企業角度看是「回答完成」，從客戶角度看仍是尚未完成。\n\n無條件賦予敏感作業廣泛權限也不是解決方案。退款、變更個人資料、恢復帳戶等功能，需要身分驗證、最小權限、金額上限、核准程序、稽核日誌，以及失敗時的復原機制。\n\n### 2. 缺乏問題中未顯現的情境\n\n只憑「請推薦適合帶小孩去的度假地點」這句話，很難得出適當結果。因為孩子年齡、交通時間、預算、食物過敏、泳池安全與醫療可及性等限制條件，都可能改變結果。\n\n補足情境的方法包括下列要素。\n\n- 用來確認必要條件的後續問題\n- 在客戶同意的範圍內運用訂單與諮詢紀錄\n- 表達商品、政策、地區、對象與例外關係的知識圖譜\n- 一致定義用語與關係的本體論\n- 查詢最新政策文件與實際庫存、預約系統\n\n本體論或知識圖譜只是可行的實作方式，並非所有聊天機器人的必要條件。對簡單業務而言，結構化 API 與明確的對話流程可能更有效率。重要的是，不讓模型透過猜測填補空白，而是使其詢問必要資訊，或從可信賴的系統中查詢。\n\n### 3. 自動化失敗後留下的高難度詢問\n\n聊天機器人處理簡單詢問後，客服人員相對會接到更多複雜的例外案例。這可以視為案例組成發生變化。即使來電件數不變或略有減少，只要剩下的通話時間變長，總客服時間與成本就可能無法下降。\n\n若客戶已在聊天機器人中重複說明同一件事，轉接客服人員後卻又必須從頭再說一次，情緒負擔也會增加。原本只是單純確認付款的問題，可能擴大成包含對自動化失敗不滿的客訴。\n\n不過，不能斷定平均處理時間上升就是聊天機器人所致。商品故障、政策變更、新進客服人員占比、季節性等因素也會造成影響。比較導入前後時，應控制詢問類型與客戶群體，並分別分析使用聊天機器人後來電的群體，以及直接來電的群體。\n\n## 解決方案不是阻擋詢問，而是順暢轉接\n\n轉接是將 AI 無法解決的對話交由人工客服處理的過程。良好轉接的目的，不是讓客戶長時間困在聊天機器人裡，而是迅速偵測自動化的限制，讓下一個處理問題的主體能不中斷地接續作業。\n\n出現下列訊號時，可以建議轉接人工客服。\n\n- 客戶明確要求轉接客服人員。\n- 相同或類似問題反覆出現。\n- 回答可信度低於標準，或找不到依據文件。\n- 涉及付款爭議、帳戶遭竊、法律威脅、安全問題等高風險情況。\n- 負面情緒持續存在，或客戶拒絕接受回答。\n- 聊天機器人執行的作業失敗或進入例外狀態。\n\n客服人員的畫面不應只傳遞完整對話紀錄，而應提供可直接用於作業的結構化資訊。\n\n| 傳遞資訊 | 具體內容 |\n|---|---|\n| 客戶意圖 | 客戶最終想要的結果 |\n| 核心事實 | 訂單編號、發生時間、商品、金額等已確認資訊 |\n| 驗證狀態 | 以何種方式完成身分驗證及其有效範圍 |\n| 執行紀錄 | 聊天機器人查詢或執行的作業及結果 |\n| 失敗原因 | 權限不足、政策例外、API 錯誤、可信度低等 |\n| 對話摘要 | 客戶主張、已提供的說明、尚待確認的問題 |\n| 情緒與風險訊號 | 不滿程度，以及是否存在資安、安全或法律風險 |\n| 依據 | 使用的政策文件版本與相關系統紀錄 |\n\nAI 產生的摘要可能出錯，因此也必須能夠一併查閱原始對話。驗證資訊與敏感個人資料只能在必要範圍內傳遞，並應管理存取權限與保存期間。\n\n## 劃分 AI 與人員角色的三階段營運模型\n\n依據業務風險、例外發生頻率與判斷責任來劃分自動化程度，會更加安全。\n\n| 領域 | 適合的業務 | AI 的角色 | 人員的角色 |\n|---|---|---|---|\n| 自動化 | 營業時間說明、物流查詢、低風險預約變更 | 查詢、說明、執行作業 | 發生例外時介入 |\n| 協作 | 複合商品詢問、政策例外審查、一般客訴 | 整理情境、搜尋依據、提出回答草稿 | 確認事實、最終判斷與溝通 |\n| 人員專責 | 法律爭議、高額退款、帳戶遭竊、安全危機、嚴重情緒安撫 | 搜尋紀錄並提供輔助資料 | 負責任地判斷、核准、修復關係 |\n\n分類標準不應是「AI 是否擅長撰寫句子」，而應是處理錯誤時造成的損害，以及能否復原。金錢、法律、安全風險較高或經常發生例外的業務，適合保留人工審查與核准階段。\n\n## 將 KPI 從阻擋率轉為旅程完成率\n\n阻擋率或自動處理率，通常是指未轉交客服人員的工作階段比例。然而，只要提高轉接難度，或即使客戶放棄解決問題，數值也可能變好。因此，若將其作為單一 KPI，可能誘發與客戶體驗方向相反的最佳化行為。\n\n以旅程為中心的衡量體系，應回答下列問題。\n\n1. 客戶想要的作業是否確實完成？\n2. 是否針對同一問題再次聯絡？\n3. 在解決前經過多少個管道與步驟？\n4. 客戶重複提供相同資訊或進行驗證多少次？\n5. 從首次接觸到最終解決花了多少時間？\n6. 自動化錯誤是否導致金錢損失或違反政策？\n\n建議的儀表板可由結果、投入、營運、風險四個層次構成。\n\n- **結果：**旅程完成率、首次接觸解決率、再次詢問率\n- **客戶投入：**總解決時間、重複說明次數、管道切換次數、客戶費力度分數\n- **營運：**電話接觸率、平均處理時間、等待時間、客服人員占用率\n- **品質與風險：**錯誤回答率、未經核准的作業率、敏感資訊外洩、異議與復原件數\n\n成本也不應只根據來電件數計算。應比較每次旅程的總成本，其中包括 AI 推論成本、系統串接、品質評估、資安控制、人工審查時間與錯誤復原成本。\n\n## 情境推論、協調與轉接管線\n\n實用的客服 AI 並非單一對話視窗，而更接近多個系統相互連接的管線。\n\n### 1. 情境推論\n\n掌握客戶意圖與必要條件，並查詢經客戶同意使用的客戶資訊及最新業務資料。不應只依賴模型記憶，而應使用政策文件、訂單系統、帳戶狀態等權威來源。\n\n### 2. 協調\n\n決定將請求送往哪項工具或哪位負責人。執行前，應確認驗證狀態、權限、金額上限與風險等級。若失敗，不應無限重試，而應轉入復原程序或人工客服。\n\n### 3. 轉接\n\n彙整客戶目標、已確認事實、已執行作業、失敗原因與下一步建議措施，並傳遞給客服人員。客服人員確認原文與依據後，再接續處理。\n\n### 4. 結果記錄與學習\n\n儲存最終是否解決，以及客服人員的修正內容。對於重複發生的失敗，不應只重新訓練模型，而應區分問題源自政策文件、API、業務權限或畫面流程，並據此改善。\n\n## 驗證導入成效的實驗設計\n\n若只比較導入前後的整體來電量，便難以排除業務成長與季節性的影響。如條件允許，應將相似客戶群或詢問類型分組，分階段部署，並共同觀察下列項目。\n\n- 每 1,000 筆訂單或每 1,000 名活躍客戶的來電件數\n- 使用聊天機器人後 24 小時或 7 天內，因相同原因再次詢問\n- 各詢問類型的完成率與平均處理時間\n- 轉接人工客服前後的客戶投入與滿意度\n- 客服人員修改 AI 摘要的比例\n- 自動執行的錯誤率，以及人工復原所需時間\n- 客服人員的認知負擔、情緒耗竭與工作滿意度\n\n此外，應事先定義「解決」的含義。顯示回答、客戶結束對話、後端作業成功，以及客戶確認結果，彼此並不相同。退款等需要後續處理的業務，必須確認實際交易狀態。\n\n## 給產品團隊的檢查清單\n\n- 是否區分聊天機器人能回答的事項與實際能執行的事項？\n- 是否透過後端結果確認各項業務的成功條件？\n- 客戶是否能隨時明確要求轉接人工客服？\n- 是否將重複問題、低可信度與風險性表述作為轉接訊號？\n- 客服人員是否不只能看到對話摘要，也能查看原文與依據？\n- 客戶是否無須再次重複驗證與說明？\n- 對 AI 可執行的金額與權限，是否設有上限及核准程序？\n- 是否衡量各詢問類型的再次詢問率與總解決時間？\n- 客服人員的回饋是否會反映到知識文件、工具與業務流程改善？\n- 實際營運負責人是否定期以客戶身分完整測試聊天機器人旅程？\n\n## 結論\n\nAI 聊天機器人的成功，不能只依據對話量或阻擋人工客服的比例來判斷。若客戶的目的未實際達成，聊天機器人就不是問題解決管道，而會成為來電前必須經過的額外步驟。\n\n有效的設計不會隱藏 AI 的限制。將標準化、低風險的業務自動化；在需要判斷的業務中協助客服人員；並將高風險情況迅速交由具備經驗的人員處理。當這套機制再結合能一併傳遞對話與業務狀態的轉接流程時，AI 就不再是阻擋客服中心來電的防護牆，而能成為縮短客戶解決問題時間的工具。","content_html":"\u003cp\u003eAI 聊天機器人的對話量大幅增加，並不代表客服中心的來電或諮詢成本會自動減少。聊天機器人回答問題，與徹底解決客戶的問題是兩回事；失敗的自動化反而可能將更複雜、情緒更激動的詢問推向人工客服。\u003c/p\u003e\n\u003cp\u003e在營運現場觀察到的核心悖論如下：聊天機器人的使用量增加，但整體來電量幾乎維持不變，而客服人員收到的詢問難度與平均處理時間卻有所上升。要理解這種現象，不能只看各管道的使用量，而必須檢視客戶完整的問題解決旅程。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%81%8A%E5%A4%A9%E6%A9%9F%E5%99%A8%E4%BA%BA%E4%BD%BF%E7%94%A8%E9%87%8F%E8%88%87%E4%BE%86%E9%9B%BB%E6%B8%9B%E5%B0%91%E4%B8%8D%E4%B8%80%E8%87%B4%E7%9A%84%E5%8E%9F%E5%9B%A0\" class=\"anchor\" id=\"聊天機器人使用量與來電減少不一致的原因\"\u003e\u003c/a\u003e聊天機器人使用量與來電減少不一致的原因\u003c/h2\u003e\n\u003cp\u003e聊天機器人使用量並非結果指標，而更接近接觸點的活動量。僅憑訪客增加、擴大聊天機器人曝光、變更應用程式內的入口位置，或原有 FAQ 使用者轉移管道，對話件數就可能增加。\u003c/p\u003e\n\u003cp\u003e例如，即使聊天機器人對話增加了 300%，在下列情況下，來電量也不會減少。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e訂單與訂閱用戶同步增加，帶動整體諮詢需求上升。\u003c/li\u003e\n\u003cli\u003e原本使用搜尋與 FAQ 的使用者轉向聊天機器人，但電話使用者仍然不變。\u003c/li\u003e\n\u003cli\u003e同一位客戶使用聊天機器人後，又針對同一問題來電。\u003c/li\u003e\n\u003cli\u003e聊天機器人成為新的諮詢入口，讓過去可能放棄的客戶也開始尋求協助。\u003c/li\u003e\n\u003cli\u003e需要透過電話處理的複雜問題，其占比並未下降。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e因此，分析時除了單純的對話件數，還必須分別檢視下列指標。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e指標\u003c/th\u003e\n\u003cth\u003e計算方式或意義\u003c/th\u003e\n\u003cth\u003e注意事項\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e電話接觸率\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e電話諮詢件數 ÷ 訂單數、訂閱數或活躍客戶數\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e必須校正因業務成長造成的諮詢量增加。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e轉接率\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e轉為人工客服的聊天機器人工作階段 ÷ 聊天機器人總工作階段\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e低並不一定代表好。隱藏轉接按鈕也可能使其降低。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e再次詢問率\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e在一定期間內針對同一問題再次聯絡的客戶比例\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e即使管道不同，也必須辨識是否為同一問題。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e旅程完成率\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e實際完成目標作業的客戶 ÷ 嘗試該作業的客戶\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e必須區分提供回答與實際處理完成。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e首次接觸解決率\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e無須額外聯絡，便在首次互動中解決的比例\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e若客服人員未經客戶確認便自行標記完成，數據會失真。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e總解決時間\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e從首次接觸到最終解決所經過的時間\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e也應包括等待、管道切換與重新驗證的時間。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"指標\"\u003e平均處理時間\u003c/td\u003e\n\u003ctd data-label=\"計算方式或意義\"\u003e客服作業所耗總時間 ÷ 處理件數\u003c/td\u003e\n\u003ctd data-label=\"注意事項\"\u003e自動化後若只剩困難案例，該數值可能上升。\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai-%E5%8D%B3%E4%BD%BF%E5%9B%9E%E7%AD%94%E4%B9%9F%E7%84%A1%E6%B3%95%E8%A7%A3%E6%B1%BA%E5%95%8F%E9%A1%8C%E7%9A%84%E4%B8%89%E9%A0%85%E7%B5%90%E6%A7%8B%E6%80%A7%E9%99%90%E5%88%B6\" class=\"anchor\" id=\"ai-即使回答也無法解決問題的三項結構性限制\"\u003e\u003c/a\u003eAI 即使回答也無法解決問題的三項結構性限制\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-%E8%AA%AA%E6%98%8E%E8%83%BD%E5%8A%9B%E8%88%87%E5%9F%B7%E8%A1%8C%E6%AC%8A%E9%99%90%E7%9A%84%E5%B7%AE%E7%95%B0\" class=\"anchor\" id=\"1-說明能力與執行權限的差異\"\u003e\u003c/a\u003e1. 說明能力與執行權限的差異\u003c/h3\u003e\n\u003cp\u003e生成式 AI 能快速說明政策、使用方法、商品資訊等文件中已有的內容。然而，客戶的實際需求往往包含多個階段的業務處理。\u003c/p\u003e\n\u003cp\u003e例如，客戶要求「我已取消訂閱卻又被扣款，請幫我退款」時，系統可能必須執行下列作業。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e驗證客戶及帳戶。\u003c/li\u003e\n\u003cli\u003e查詢取消時間與付款紀錄。\u003c/li\u003e\n\u003cli\u003e判定是否為重複扣款或符合退款條件。\u003c/li\u003e\n\u003cli\u003e確認核准權限與例外政策。\u003c/li\u003e\n\u003cli\u003e執行退款並記錄結果。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e若聊天機器人未連接內部付款、訂單系統，或沒有執行權限，就只能提供說明。若客戶必須自行尋找選單重新處理，即使從企業角度看是「回答完成」，從客戶角度看仍是尚未完成。\u003c/p\u003e\n\u003cp\u003e無條件賦予敏感作業廣泛權限也不是解決方案。退款、變更個人資料、恢復帳戶等功能，需要身分驗證、最小權限、金額上限、核准程序、稽核日誌，以及失敗時的復原機制。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-%E7%BC%BA%E4%B9%8F%E5%95%8F%E9%A1%8C%E4%B8%AD%E6%9C%AA%E9%A1%AF%E7%8F%BE%E7%9A%84%E6%83%85%E5%A2%83\" class=\"anchor\" id=\"2-缺乏問題中未顯現的情境\"\u003e\u003c/a\u003e2. 缺乏問題中未顯現的情境\u003c/h3\u003e\n\u003cp\u003e只憑「請推薦適合帶小孩去的度假地點」這句話，很難得出適當結果。因為孩子年齡、交通時間、預算、食物過敏、泳池安全與醫療可及性等限制條件，都可能改變結果。\u003c/p\u003e\n\u003cp\u003e補足情境的方法包括下列要素。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e用來確認必要條件的後續問題\u003c/li\u003e\n\u003cli\u003e在客戶同意的範圍內運用訂單與諮詢紀錄\u003c/li\u003e\n\u003cli\u003e表達商品、政策、地區、對象與例外關係的知識圖譜\u003c/li\u003e\n\u003cli\u003e一致定義用語與關係的本體論\u003c/li\u003e\n\u003cli\u003e查詢最新政策文件與實際庫存、預約系統\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e本體論或知識圖譜只是可行的實作方式，並非所有聊天機器人的必要條件。對簡單業務而言，結構化 API 與明確的對話流程可能更有效率。重要的是，不讓模型透過猜測填補空白，而是使其詢問必要資訊，或從可信賴的系統中查詢。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-%E8%87%AA%E5%8B%95%E5%8C%96%E5%A4%B1%E6%95%97%E5%BE%8C%E7%95%99%E4%B8%8B%E7%9A%84%E9%AB%98%E9%9B%A3%E5%BA%A6%E8%A9%A2%E5%95%8F\" class=\"anchor\" id=\"3-自動化失敗後留下的高難度詢問\"\u003e\u003c/a\u003e3. 自動化失敗後留下的高難度詢問\u003c/h3\u003e\n\u003cp\u003e聊天機器人處理簡單詢問後，客服人員相對會接到更多複雜的例外案例。這可以視為案例組成發生變化。即使來電件數不變或略有減少，只要剩下的通話時間變長，總客服時間與成本就可能無法下降。\u003c/p\u003e\n\u003cp\u003e若客戶已在聊天機器人中重複說明同一件事，轉接客服人員後卻又必須從頭再說一次，情緒負擔也會增加。原本只是單純確認付款的問題，可能擴大成包含對自動化失敗不滿的客訴。\u003c/p\u003e\n\u003cp\u003e不過，不能斷定平均處理時間上升就是聊天機器人所致。商品故障、政策變更、新進客服人員占比、季節性等因素也會造成影響。比較導入前後時，應控制詢問類型與客戶群體，並分別分析使用聊天機器人後來電的群體，以及直接來電的群體。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%A7%A3%E6%B1%BA%E6%96%B9%E6%A1%88%E4%B8%8D%E6%98%AF%E9%98%BB%E6%93%8B%E8%A9%A2%E5%95%8F%E8%80%8C%E6%98%AF%E9%A0%86%E6%9A%A2%E8%BD%89%E6%8E%A5\" class=\"anchor\" id=\"解決方案不是阻擋詢問而是順暢轉接\"\u003e\u003c/a\u003e解決方案不是阻擋詢問，而是順暢轉接\u003c/h2\u003e\n\u003cp\u003e轉接是將 AI 無法解決的對話交由人工客服處理的過程。良好轉接的目的，不是讓客戶長時間困在聊天機器人裡，而是迅速偵測自動化的限制，讓下一個處理問題的主體能不中斷地接續作業。\u003c/p\u003e\n\u003cp\u003e出現下列訊號時，可以建議轉接人工客服。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e客戶明確要求轉接客服人員。\u003c/li\u003e\n\u003cli\u003e相同或類似問題反覆出現。\u003c/li\u003e\n\u003cli\u003e回答可信度低於標準，或找不到依據文件。\u003c/li\u003e\n\u003cli\u003e涉及付款爭議、帳戶遭竊、法律威脅、安全問題等高風險情況。\u003c/li\u003e\n\u003cli\u003e負面情緒持續存在，或客戶拒絕接受回答。\u003c/li\u003e\n\u003cli\u003e聊天機器人執行的作業失敗或進入例外狀態。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e客服人員的畫面不應只傳遞完整對話紀錄，而應提供可直接用於作業的結構化資訊。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e傳遞資訊\u003c/th\u003e\n\u003cth\u003e具體內容\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e客戶意圖\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e客戶最終想要的結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e核心事實\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e訂單編號、發生時間、商品、金額等已確認資訊\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e驗證狀態\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e以何種方式完成身分驗證及其有效範圍\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e執行紀錄\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e聊天機器人查詢或執行的作業及結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e失敗原因\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e權限不足、政策例外、API 錯誤、可信度低等\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e對話摘要\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e客戶主張、已提供的說明、尚待確認的問題\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e情緒與風險訊號\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e不滿程度，以及是否存在資安、安全或法律風險\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"傳遞資訊\"\u003e依據\u003c/td\u003e\n\u003ctd data-label=\"具體內容\"\u003e使用的政策文件版本與相關系統紀錄\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAI 產生的摘要可能出錯，因此也必須能夠一併查閱原始對話。驗證資訊與敏感個人資料只能在必要範圍內傳遞，並應管理存取權限與保存期間。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%8A%83%E5%88%86-ai-%E8%88%87%E4%BA%BA%E5%93%A1%E8%A7%92%E8%89%B2%E7%9A%84%E4%B8%89%E9%9A%8E%E6%AE%B5%E7%87%9F%E9%81%8B%E6%A8%A1%E5%9E%8B\" class=\"anchor\" id=\"劃分-ai-與人員角色的三階段營運模型\"\u003e\u003c/a\u003e劃分 AI 與人員角色的三階段營運模型\u003c/h2\u003e\n\u003cp\u003e依據業務風險、例外發生頻率與判斷責任來劃分自動化程度，會更加安全。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e領域\u003c/th\u003e\n\u003cth\u003e適合的業務\u003c/th\u003e\n\u003cth\u003eAI 的角色\u003c/th\u003e\n\u003cth\u003e人員的角色\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"領域\"\u003e自動化\u003c/td\u003e\n\u003ctd data-label=\"適合的業務\"\u003e營業時間說明、物流查詢、低風險預約變更\u003c/td\u003e\n\u003ctd data-label=\"AI 的角色\"\u003e查詢、說明、執行作業\u003c/td\u003e\n\u003ctd data-label=\"人員的角色\"\u003e發生例外時介入\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"領域\"\u003e協作\u003c/td\u003e\n\u003ctd data-label=\"適合的業務\"\u003e複合商品詢問、政策例外審查、一般客訴\u003c/td\u003e\n\u003ctd data-label=\"AI 的角色\"\u003e整理情境、搜尋依據、提出回答草稿\u003c/td\u003e\n\u003ctd data-label=\"人員的角色\"\u003e確認事實、最終判斷與溝通\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"領域\"\u003e人員專責\u003c/td\u003e\n\u003ctd data-label=\"適合的業務\"\u003e法律爭議、高額退款、帳戶遭竊、安全危機、嚴重情緒安撫\u003c/td\u003e\n\u003ctd data-label=\"AI 的角色\"\u003e搜尋紀錄並提供輔助資料\u003c/td\u003e\n\u003ctd data-label=\"人員的角色\"\u003e負責任地判斷、核准、修復關係\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e分類標準不應是「AI 是否擅長撰寫句子」，而應是處理錯誤時造成的損害，以及能否復原。金錢、法律、安全風險較高或經常發生例外的業務，適合保留人工審查與核准階段。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%B0%87-kpi-%E5%BE%9E%E9%98%BB%E6%93%8B%E7%8E%87%E8%BD%89%E7%82%BA%E6%97%85%E7%A8%8B%E5%AE%8C%E6%88%90%E7%8E%87\" class=\"anchor\" id=\"將-kpi-從阻擋率轉為旅程完成率\"\u003e\u003c/a\u003e將 KPI 從阻擋率轉為旅程完成率\u003c/h2\u003e\n\u003cp\u003e阻擋率或自動處理率，通常是指未轉交客服人員的工作階段比例。然而，只要提高轉接難度，或即使客戶放棄解決問題，數值也可能變好。因此，若將其作為單一 KPI，可能誘發與客戶體驗方向相反的最佳化行為。\u003c/p\u003e\n\u003cp\u003e以旅程為中心的衡量體系，應回答下列問題。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e客戶想要的作業是否確實完成？\u003c/li\u003e\n\u003cli\u003e是否針對同一問題再次聯絡？\u003c/li\u003e\n\u003cli\u003e在解決前經過多少個管道與步驟？\u003c/li\u003e\n\u003cli\u003e客戶重複提供相同資訊或進行驗證多少次？\u003c/li\u003e\n\u003cli\u003e從首次接觸到最終解決花了多少時間？\u003c/li\u003e\n\u003cli\u003e自動化錯誤是否導致金錢損失或違反政策？\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e建議的儀表板可由結果、投入、營運、風險四個層次構成。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e**結果：**旅程完成率、首次接觸解決率、再次詢問率\u003c/li\u003e\n\u003cli\u003e**客戶投入：**總解決時間、重複說明次數、管道切換次數、客戶費力度分數\u003c/li\u003e\n\u003cli\u003e**營運：**電話接觸率、平均處理時間、等待時間、客服人員占用率\u003c/li\u003e\n\u003cli\u003e**品質與風險：**錯誤回答率、未經核准的作業率、敏感資訊外洩、異議與復原件數\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e成本也不應只根據來電件數計算。應比較每次旅程的總成本，其中包括 AI 推論成本、系統串接、品質評估、資安控制、人工審查時間與錯誤復原成本。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E6%83%85%E5%A2%83%E6%8E%A8%E8%AB%96%E5%8D%94%E8%AA%BF%E8%88%87%E8%BD%89%E6%8E%A5%E7%AE%A1%E7%B7%9A\" class=\"anchor\" id=\"情境推論協調與轉接管線\"\u003e\u003c/a\u003e情境推論、協調與轉接管線\u003c/h2\u003e\n\u003cp\u003e實用的客服 AI 並非單一對話視窗，而更接近多個系統相互連接的管線。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-%E6%83%85%E5%A2%83%E6%8E%A8%E8%AB%96\" class=\"anchor\" id=\"1-情境推論\"\u003e\u003c/a\u003e1. 情境推論\u003c/h3\u003e\n\u003cp\u003e掌握客戶意圖與必要條件，並查詢經客戶同意使用的客戶資訊及最新業務資料。不應只依賴模型記憶，而應使用政策文件、訂單系統、帳戶狀態等權威來源。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-%E5%8D%94%E8%AA%BF\" class=\"anchor\" id=\"2-協調\"\u003e\u003c/a\u003e2. 協調\u003c/h3\u003e\n\u003cp\u003e決定將請求送往哪項工具或哪位負責人。執行前，應確認驗證狀態、權限、金額上限與風險等級。若失敗，不應無限重試，而應轉入復原程序或人工客服。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-%E8%BD%89%E6%8E%A5\" class=\"anchor\" id=\"3-轉接\"\u003e\u003c/a\u003e3. 轉接\u003c/h3\u003e\n\u003cp\u003e彙整客戶目標、已確認事實、已執行作業、失敗原因與下一步建議措施，並傳遞給客服人員。客服人員確認原文與依據後，再接續處理。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-%E7%B5%90%E6%9E%9C%E8%A8%98%E9%8C%84%E8%88%87%E5%AD%B8%E7%BF%92\" class=\"anchor\" id=\"4-結果記錄與學習\"\u003e\u003c/a\u003e4. 結果記錄與學習\u003c/h3\u003e\n\u003cp\u003e儲存最終是否解決，以及客服人員的修正內容。對於重複發生的失敗，不應只重新訓練模型，而應區分問題源自政策文件、API、業務權限或畫面流程，並據此改善。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E9%A9%97%E8%AD%89%E5%B0%8E%E5%85%A5%E6%88%90%E6%95%88%E7%9A%84%E5%AF%A6%E9%A9%97%E8%A8%AD%E8%A8%88\" class=\"anchor\" id=\"驗證導入成效的實驗設計\"\u003e\u003c/a\u003e驗證導入成效的實驗設計\u003c/h2\u003e\n\u003cp\u003e若只比較導入前後的整體來電量，便難以排除業務成長與季節性的影響。如條件允許，應將相似客戶群或詢問類型分組，分階段部署，並共同觀察下列項目。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e每 1,000 筆訂單或每 1,000 名活躍客戶的來電件數\u003c/li\u003e\n\u003cli\u003e使用聊天機器人後 24 小時或 7 天內，因相同原因再次詢問\u003c/li\u003e\n\u003cli\u003e各詢問類型的完成率與平均處理時間\u003c/li\u003e\n\u003cli\u003e轉接人工客服前後的客戶投入與滿意度\u003c/li\u003e\n\u003cli\u003e客服人員修改 AI 摘要的比例\u003c/li\u003e\n\u003cli\u003e自動執行的錯誤率，以及人工復原所需時間\u003c/li\u003e\n\u003cli\u003e客服人員的認知負擔、情緒耗竭與工作滿意度\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e此外，應事先定義「解決」的含義。顯示回答、客戶結束對話、後端作業成功，以及客戶確認結果，彼此並不相同。退款等需要後續處理的業務，必須確認實際交易狀態。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%B5%A6%E7%94%A2%E5%93%81%E5%9C%98%E9%9A%8A%E7%9A%84%E6%AA%A2%E6%9F%A5%E6%B8%85%E5%96%AE\" class=\"anchor\" id=\"給產品團隊的檢查清單\"\u003e\u003c/a\u003e給產品團隊的檢查清單\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e是否區分聊天機器人能回答的事項與實際能執行的事項？\u003c/li\u003e\n\u003cli\u003e是否透過後端結果確認各項業務的成功條件？\u003c/li\u003e\n\u003cli\u003e客戶是否能隨時明確要求轉接人工客服？\u003c/li\u003e\n\u003cli\u003e是否將重複問題、低可信度與風險性表述作為轉接訊號？\u003c/li\u003e\n\u003cli\u003e客服人員是否不只能看到對話摘要，也能查看原文與依據？\u003c/li\u003e\n\u003cli\u003e客戶是否無須再次重複驗證與說明？\u003c/li\u003e\n\u003cli\u003e對 AI 可執行的金額與權限，是否設有上限及核准程序？\u003c/li\u003e\n\u003cli\u003e是否衡量各詢問類型的再次詢問率與總解決時間？\u003c/li\u003e\n\u003cli\u003e客服人員的回饋是否會反映到知識文件、工具與業務流程改善？\u003c/li\u003e\n\u003cli\u003e實際營運負責人是否定期以客戶身分完整測試聊天機器人旅程？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%B5%90%E8%AB%96\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003eAI 聊天機器人的成功，不能只依據對話量或阻擋人工客服的比例來判斷。若客戶的目的未實際達成，聊天機器人就不是問題解決管道，而會成為來電前必須經過的額外步驟。\u003c/p\u003e\n\u003cp\u003e有效的設計不會隱藏 AI 的限制。將標準化、低風險的業務自動化；在需要判斷的業務中協助客服人員；並將高風險情況迅速交由具備經驗的人員處理。當這套機制再結合能一併傳遞對話與業務狀態的轉接流程時，AI 就不再是阻擋客服中心來電的防護牆，而能成為縮短客戶解決問題時間的工具。\u003c/p\u003e\n","tags":["AI聊天機器人","客服中心","CX","客服自動化","轉接"],"faqs":[{"question":"聊天機器人使用者增加時，客服中心的來電量不是也應該減少嗎？","answer":"不一定。聊天機器人使用量增加，也可能是因為曝光擴大、客戶增加，或原有 FAQ 管道的使用轉移所致。如果同一位客戶使用聊天機器人後又再打電話，即使對話量增加，來電量也可能維持不變。"},{"question":"聊天機器人的攔截率高，就代表自動化成功了嗎？","answer":"僅憑攔截率很難判斷。讓轉接按鈕難以找到，或客戶放棄解決問題時，攔截率也可能升高。必須同時衡量實際業務完成情況、是否再次諮詢、總解決時間與客戶付出的心力。"},{"question":"導入聊天機器人後，平均處理時間為什麼可能增加？","answer":"如果 AI 處理簡單的諮詢，複雜的例外情況和帶有情緒的客訴可能會集中到客服人員身上。由於這種案件組成的變化，即使通話件數減少，每件諮詢的處理時間仍可能增加。"},{"question":"良好的真人客服交接應包含哪些內容？","answer":"應包含客戶的最終目的、身分驗證狀態、已確認的事實、聊天機器人執行的工作、失敗原因、相關政策與對話摘要。AI 摘要可能有錯誤，因此客服人員也必須能夠查看原文與依據。"},{"question":"賦予 AI 退款或取消的權限，就能解決問題嗎？","answer":"部分流程會有所改善，但授予無限制權限並不安全。必須具備身分驗證、最小權限、金額上限、核准條件、稽核日誌與錯誤復原程序，並從低風險業務開始逐步自動化。"},{"question":"客戶服務聊天機器人一定需要本體論和知識圖譜嗎？","answer":"不一定需要。在處理複雜的商品與政策關係時很有用，但簡單業務僅靠結構化 API 和明確的對話流程也能處理。關鍵在於詢問必要的情境資訊，或從可信賴的系統中查詢。"},{"question":"該如何決定轉交客服人員的時機？","answer":"可以根據明確要求真人客服、重複提問、回答可信度低、工作執行失敗、持續的負面情緒，以及付款爭議、帳號遭竊、安全問題等高風險訊號來決定。不應以節省成本為由，讓高風險諮詢長時間停留在聊天機器人環節。"},{"question":"聊天機器人的核心 KPI 應使用哪些指標？","answer":"可以優先查看流程完成率、首次接觸解決率、相同原因的再次諮詢率、總解決時間與重複說明次數。也應一併確認電話接觸率、平均處理時間、錯誤率與每次流程的總成本。"},{"question":"如何驗證聊天機器人是否降低了客服中心成本？","answer":"不應只比較導入前後的總來電量，而應計算依客戶數與交易量校正後的電話接觸率。適合比較各諮詢類型的完成率、再次諮詢、客服時間，以及包含 AI 營運費、人工作業審查和錯誤復原成本在內的每次流程總成本。"}],"sources":[{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"NIST AI 風險管理框架","type":"source"},{"url":"https://cloud.google.com/solutions/contact-center-ai-platform","title":"Google Cloud 聯絡中心 AI 平台","type":"source"},{"url":"https://www.ibm.com/think/topics/ontology","title":"IBM：什麼是本體論？","type":"source"},{"url":"https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/human-in-the-loop","title":"Microsoft Azure 架構中心：人工參與迴圈","type":"source"}],"images":[{"id":626,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NzU5NywicHVyIjoiYmxvYl9pZCJ9fQ==--317ba98209612caa9af6cdc98ef2ee488ef9e21b/ai-97159692.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"단순 문의는 처리하고 복잡한 문제는 대기 줄과 상담원에게 넘기는 AI 챗봇 흐름도","caption":"챗봇이 일부 요청을 해결하지만 오류와 복잡한 문의는 콜센터 상담원에게 이어진다.","description":null},"en":{"alt":"AI chatbot routing simple requests to solutions and complex issues to a call center queue","caption":"The chatbot resolves some requests while errors and complex cases flow to waiting callers and human agents.","description":null},"ja":{"alt":"簡単な問い合わせを処理し、複雑な問題を待機列とオペレーターへ回すAIチャットボット","caption":"チャットボットが一部の依頼を解決する一方、エラーや複雑な相談はコールセンターへ送られる。","description":null},"es":{"alt":"Chatbot de IA que resuelve consultas simples y deriva problemas complejos a la cola del centro de llamadas","caption":"El chatbot resuelve algunas solicitudes, mientras los errores y casos complejos pasan a agentes humanos.","description":null},"id":{"alt":"Chatbot AI menangani permintaan sederhana dan mengalihkan masalah rumit ke antrean pusat panggilan","caption":"Chatbot menyelesaikan sebagian permintaan, sedangkan galat dan kasus rumit diteruskan ke agen manusia.","description":null},"pt":{"alt":"Chatbot de IA resolve pedidos simples e encaminha problemas complexos à fila da central de atendimento","caption":"O chatbot soluciona algumas solicitações, enquanto erros e casos complexos seguem para atendentes humanos.","description":null},"zh-hant":{"alt":"AI 聊天機器人處理簡單需求，並將複雜問題轉入客服中心等候隊伍","caption":"聊天機器人解決部分請求，但錯誤與複雜案件仍會轉交真人客服。","description":null},"de":{"alt":"KI-Chatbot löst einfache Anfragen und leitet komplexe Probleme an die Warteschlange des Callcenters weiter","caption":"Der Chatbot erledigt einige Anliegen, während Fehler und komplexe Fälle an menschliche Agenten gehen.","description":null}}},{"id":627,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NzYwMywicHVyIjoiYmxvYl9pZCJ9fQ==--3ee1a2d62648624b7dfb616c81456a18181d3f5c/ai-6fc792ff.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"고객 문의가 AI 챗봇과 전화·이메일을 거쳐 상담원에게 연결되는 흐름과 분석 대시보드","caption":"AI 챗봇과 여러 문의 채널을 상담원이 이어받아 해결하는 과정을 보여준다.","description":null},"en":{"alt":"Customer inquiry routed through an AI chatbot, phone and email to a human agent, with analytics below","caption":"The illustration shows a human agent resolving inquiries across AI and customer service channels.","description":null},"ja":{"alt":"顧客の問い合わせがAIチャットボットや電話、メールを経て担当者につながる流れと分析画面","caption":"AIと複数の問い合わせ窓口を人間の担当者が引き継いで解決する流れを示している。","description":null},"es":{"alt":"Consulta de una clienta canalizada por chatbot, teléfono y correo hacia una agente, con panel de análisis","caption":"La ilustración muestra a una agente resolviendo consultas procedentes de la IA y otros canales.","description":null},"id":{"alt":"Pertanyaan pelanggan dialihkan melalui chatbot AI, telepon, dan email ke agen, dengan dasbor analitik","caption":"Ilustrasi menunjukkan agen manusia menyelesaikan pertanyaan dari AI dan berbagai kanal layanan.","description":null},"pt":{"alt":"Dúvida de cliente encaminhada por chatbot, telefone e e-mail até uma atendente, com painel de análises","caption":"A ilustração mostra uma atendente resolvendo solicitações vindas da IA e de outros canais.","description":null},"zh-hant":{"alt":"客戶問題經由AI聊天機器人、電話和電子郵件轉交真人客服，下方顯示分析儀表板","caption":"圖中呈現真人客服接手AI與多種服務管道的問題並完成處理。","description":null},"de":{"alt":"Kundenanfrage wird über KI-Chatbot, Telefon und E-Mail an eine Mitarbeiterin geleitet, darunter Analysen","caption":"Die Grafik zeigt, wie eine Mitarbeiterin Anfragen aus KI- und weiteren Servicekanälen löst.","description":null}}}],"published_at":"2026-08-14T01:01:58+09:00","updated_at":"2026-08-14T01:01:58+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/why-ai-chatbots-do-not-reduce-call-center-calls"}