金融客服 AI Copilot 落地:讓客服少查資料、答對法遵話術,首次解決率如何拉升

去年底,我們坐進一家民營銀行的客服中心,戴上耳機聽線。第三通電話,一位客戶問信用卡分期的提前結清怎麼算違約金。客服人員按了靜音,開了三個系統的分頁,翻產品條款,又切到另一個內部 Wiki 查法遵用語,前後花了一分五十秒。客戶在那頭等到開始不耐煩。

這不是個案。那個下午我們統計,平均每通電話,客服要在對話中查兩到三次資料,每次查詢卡住的時間,佔了整通通話的三成以上。而且查回來的答案,還不一定對——因為法遵話術半年前改過一版,舊的說法還留在某個人的筆記裡。

問題從來不是客服不夠努力。是他們被逼著同時當搜尋引擎、法規顧問和情緒安撫者。

金融客服 AI Copilot 到底在解什麼

先把話說清楚。金融客服 AI Copilot,是一個坐在客服人員螢幕側邊、即時把「這句話該怎麼答、依據哪條規定、合規用語是什麼」推到他眼前的輔助系統。 它不取代人,而是把人從「翻資料」這件事裡拉出來,讓人專心處理客戶。

金融業的特殊之處在於,答錯的代價很高。一句「這個保證獲利」可能就是一張罰單。所以這裡的 Copilot 不能只是接個大型語言模型、丟個 prompt 就上線。它必須答得準,而且每一句話都要能追溯來源。

這就是為什麼我們不做「通用問答」,而是用 RAG(檢索增強生成)把兩套知識庫掛進去。

為什麼一定要 RAG,而不是直接問模型

直接問模型的問題,是它會「自信地編」。你問它某張信用卡的循環利率,它可能給你一個看起來很合理、但其實是三年前的數字。在金融場景,這種幻覺是不能接受的。

RAG 的做法不一樣。客服提問時,系統先去檢索企業自己的知識庫,把最相關的幾段條款、費率表、話術範本撈出來,再讓模型「根據這些內容」組織回答。模型只負責語言表達,事實由知識庫負責。

我們通常會掛兩套進去。一套是產品知識庫:費率、條款、辦卡流程、常見爭議處理。另一套是法遵知識庫:主管機關規定的揭露義務、禁止用語、標準話術。兩套分開維護,因為更新頻率和負責的部門根本不同——產品部改費率,法遵部改用語,各改各的,系統各自即時反映。

關鍵的一點:每一段回答,Copilot 都會標出「這句話來自哪份文件、哪個版本」。這條稽核軌跡,是整套系統能不能通過內稽和金管會檢查的生死線。Demo 的時候沒人在乎來源,上線之後稽核第一個問的就是它。

上線三個月,數字怎麼變

我們接手的那家銀行,導入前後量了兩個核心指標:首次解決率(FCR)和平均處理時長(AHT)。這是客服中心最不會騙人的兩個數字。

FCR 拉高的原因不神祕:客服不用轉單、不用「我查一下再回電您」,當下就答得完整。AHT 縮短,是因為查資料的死時間被砍掉了。而法遵用語錯誤大幅下降,靠的是 Copilot 直接把「這種情況該講這句、不能講那句」推到眼前,新人不必靠記憶硬背。

我要誠實講一個踩過的雷。上線第一個月,FCR 其實只動了三個百分點,團隊差點以為失敗了。後來發現,問題不在系統,在知識庫本身——有些條款寫得太行話,模型檢索得到、但客服看不懂,還是得自己再翻譯一次。我們花了兩週,陪法遵和資深客服一起把高頻問題的答案重寫成「可以直接照唸」的口語版。改完之後,數字才真正起飛。

這件事後來變成我們的固定認知:Copilot 的天花板,是知識庫的品質,不是模型的聰明程度。

落地的難,不在技術,在採用

技術上,把 RAG 接起來、串上客服系統,大概三到四週能做出一個能動的版本。真正難的是後面那件事——讓客服「真的去用」。

我們見過太多系統,功能齊全,但客服嫌它慢半拍、嫌側邊欄擋螢幕,乾脆關掉。所以我們的工程師會直接坐在客服旁邊,看他怎麼接電話、在哪一步卡住、什麼時候會忽略提示。有個細節是我們現場才發現的:資深客服根本不看整段答案,他們只要「關鍵那一句」和「來源連結」。於是我們把介面改成先出一句話結論,要細節再展開。採用率從四成一路爬到八成五,靠的就是這種現場的來回。

一句話收尾

在 Tenten,我們做金融客服 Copilot 的順序永遠是:先搞定知識庫和稽核軌跡,再讓工程師進場陪客服調到願意用,最後才看 FCR 和 AHT 的數字說話。Demo 很美不算數,螢幕側邊那個 Copilot 真的被按下去、而且答對了,才算數。