案例拆解:一家銀行把 AI 客服從 Demo 推上生產線的 90 天——採用率、工時與踩過的坑

上線第 90 天,我們交出的數字是這樣的:內部客服專員的採用率 71%,第一線人工回覆的平均處理工時從 8.4 分鐘降到 3.1 分鐘,AI 草稿的直接採用率 63%。這不是 Demo 那天的數字。Demo 那天什麼都漂亮。

先講清楚這個銀行 AI 導入案例的起點。這家區域型銀行的信用卡客服中心,先前已經自己接過一套通用的 LLM 客服工具,PoC 跑得很順,主管群看完簡報全體通過。三個月後我們進場盤點時,實際天天在用的專員大概兩成。系統沒壞,是它不懂這家銀行怎麼做事。

前兩週:我們坐在客服旁邊，不寫任何一行程式

FDE 前線部署的第一守則,是先別急著建東西。我們派了兩位工程師直接坐進客服中心,戴上耳機聽線,看專員怎麼在五個內部系統之間切換查一筆爭議款。

真正的問題不在模型。在於這家銀行有 40% 的問題牽涉到「這張卡的這筆交易」,而那筆交易資料鎖在一套 1990 年代的核心主機裡,通用工具根本讀不到。專員之所以不用 AI,是因為 AI 答得出信用卡的一般規則,卻答不出「王先生上週三那筆 3,200 元為什麼被擋」。答不到點上的助手,不如自己查。

這一課我們用兩週買到,值得。

第 3 到 6 週:RAG 接進主機，而不是接進 FAQ

我們重建了知識檢索層。把過去被丟進向量庫的那份 200 頁 FAQ 降級為背景資料,真正的主力改成即時查詢:專員打開一筆對話,系統用去識別化的方式把該筆交易的狀態、爭議標記、風控備註一起帶進 context,再讓模型生成回覆草稿。

這裡踩了第一個大坑。第一版我們讓 AI 自動抓取客戶全部帳戶資料塞進 prompt,合規長官在資安審查會議上直接喊停——過度蒐集,違反最小必要原則。我們花了整整九天重做權限層,改成「專員當前處理的那一筆」才可見,並且每一次 AI 讀取都寫審計日誌。慢,但這關過不了就沒有上線。

第二個坑是幻覺,而且是最危險的那種。測試時模型信誓旦旦報了一個根本不存在的「30 天免息緩衝期」。金融業這種話一出去就是客訴甚至裁罰。我們的處理不是調 prompt 求神,而是加了一道規則:凡是涉及利率、費用、法遵條款的回覆,一律只能引用知識庫原文,不可改寫,並強制附上來源條目。寧可 AI 說「我需要確認」,也不許它自信地編。

第 7 到 12 週:採用率是設計出來的，不是宣導出來的

工具再好,沒人用等於零。我們做了三件事把採用率從兩成拉起來。

第一,AI 只出草稿,永遠由專員按下送出。這保留了人的判斷與尊嚴,也讓資深專員願意試——它是助手,不是要取代你的東西。第二,我們把入口嵌進他們原本就在用的工單畫面,不是另開一個新分頁。多一個要切換的視窗,採用率就掉一截,這是我們反覆驗證過的。第三,我們每週把「AI 草稿被改動最多的前十類問題」撈出來,拿去修檢索與規則。系統肉眼可見地一週比一週準,專員的信任是這樣長出來的。

下面是這 90 天前後的對照:

我們會誠實說的取捨

有些事我們沒做到。夜間無人時段的全自動應答,原本客戶想要,我們建議暫緩——爭議款與風控情境的自動化風險太高,90 天內不碰,留到信任數據更厚實再談。另外那 29% 沒被日常採用的專員,多半處理的是高度個案化的催收與法務往來,那本來就不該硬推 AI。

把這個案子講完整,是因為我們看太多「Demo 驚艷、上線冷清」的專案。差別從來不在模型多強,而在有沒有人真的坐進現場,把 AI 接上那台老主機、扛過合規審查、陪著專員用到願意信任。這就是我們在 Tenten 做 FDE 前線部署的方式:工程師進場,一路扛到採用率長出來為止。Demo 很美不算數,上線且有人天天在用,才算數。