客服中心導入 AI 應答踩雷案例：客訴處理時間為什麼反而拉長

一間電信服務商的客服中心，原本維持二十多人的編制，分成電話、線上客服、社群訊息三個窗口。主管每季都要為排班和加班費傷腦筋，尤其帳單週期一到，進線量會直接翻倍。看過幾家同業的成功分享後，主管決定一次到位：把線上客服與社群訊息全面換成生成式 AI 應答，電話窗口則導入語音機器人做前端分流，目標是讓 AI 承接八成以上的進線，客服人員只處理真正需要人工判斷的案子。預算編了將近半年，選型也做得很仔細，看起來是一個規劃周全、風險可控的專案。

系統上線的頭兩週，數字看起來很漂亮。AI 應答的即時性沒話說，客戶打字問完幾乎立刻有回覆，主管在會議上分享「進線量的七成已經不需要人工介入」，士氣一度很高。問題是從第三週開始慢慢浮現的，而且不是一眼就能看出來的技術當機，而是客訴悄悄變多、變久。

為什麼 AI 答得又快又順，客訴卻不減反增

追查客訴紀錄才發現，問題出在 AI「答得出來」不等於「答對」。系統串接的知識庫是把過去客服 SOP 文件、常見問題整理稿直接匯入，但這些文件本身就存在版本落差，有些資費方案早就調整過，文件卻沒同步更新；AI 在回答時又習慣把不確定的內容講得很肯定，不會主動說「這部分我不確定，幫你轉真人確認」，於是客戶拿到一個講得斬釘截鐵、但內容過時或錯誤的答案。更麻煩的是，當客戶追問細節、AI 答不上來時，系統的轉真人機制設計得不夠明確，經常在原地打轉兩三輪才轉出去，客戶到真人手上時已經帶著怒氣重講一次，客服人員還要花時間釐清「AI 到底跟你說了什麼」。

這類問題背後的根本原因，通常不是模型能力不夠，而是導入前沒有把「知識庫的正確性與即時性」當成第一優先的工程項目，而是想著先上線、之後再慢慢補資料。對電信、金融這類資費規則、方案條款經常異動的產業來說，知識庫沒有建立固定的更新機制，AI 應答的風險會比想像中高很多。

代價：多花的不只是時間，還有客戶對窗口的信任

這段磨合期大概持續了將近兩個月。客服主管後來統計，這段時間的客訴平均處理時間不但沒有縮短，反而比導入前多花了將近一倍，原因是每一件牽涉 AI 誤答的客訴，都要多一道「先跟客戶道歉、確認正確資訊、視情況補償」的流程。原本設計 AI 是為了省人力，結果客服人員一邊要處理真人客訴，一邊要回頭盯著 AI 的對話紀錄抓錯，工作量不減反增，有幾位資深客服人員私下反映「還不如全部自己接比較快」，團隊士氣也受到影響。

更難量化但同樣重要的，是客戶對客服窗口的信任成本。有客戶在社群上公開抱怨「客服機器人亂講方案內容，問到後來還要重講一次」，雖然沒有演變成大規模公關危機，但主管坦言，那段時間確實讓一部分老客戶對線上客服窗口失去信心，轉而打電話進來，反而增加了電話窗口的負擔，等於把問題從一個管道推到另一個管道，並沒有真正解決。

後來怎麼調整：先縮小 AI 的守備範圍，再逐步放大

團隊沒有整套下架系統，而是重新劃定 AI 能回答的範圍。第一步是把知識庫拆成「已驗證、允許 AI 直接回答」與「需要人工核實」兩層，只有確定資費、流程沒有異動疑慮的內容才開放給 AI，任何涉及金額爭議、方案異動、投訴情緒字眼的對話，一律在第一輪就轉真人，不讓 AI 硬撐著回答。第二步是替知識庫建立固定的更新窗口，規定資費或方案異動時，必須同步更新到 AI 知識庫，列為上線流程的一部分，而不是事後才補。第三步是把 AI 的回答加上明確的信心標示，對於系統判斷信心不足的問題，直接讓 AI 主動說「這部分請讓我幫你確認，稍等一下」，而不是硬答一個聽起來很篤定但可能是錯的答案。

調整之後，AI 承接的範圍雖然比原本設定的八成小了不少，大概退回到五成左右，但客訴處理時間才慢慢回到導入前的水準，並且開始比導入前更短。主管後來的心得是，一開始把目標設得太滿，反而是踩雷的起點。

客服中心導入 AI 應答，真正該提防的不是回覆速度不夠快，而是「答得快」掩蓋了「答得對不對」這個更根本的問題。導入前，先確認知識庫有沒有人固定維護、轉真人的門檻設在哪裡，以及第一階段願意讓 AI 承接的範圍是不是保守一點開始。這幾件事沒想清楚，上線初期看起來很順的數字，很可能只是問題還沒爆出來而已。