AI 客服 PoC 怎麼做？30 天驗證計畫與上線前檢查清單

當公司決定導入 AI 客服時，最常見的起手式就是把幾份公司文件塞進系統，隨便想個十幾題，然後叫 AI 測試看看。

神奇的是，一開始測試通常都順到不行。

不論是問營業時間還是退換貨規定，AI 都能對答如流。老闆看完 Demo 後非常滿意，拍板點頭說：「很好，那我們準備上線吧！」

但幾週後，當真正的客戶上門，災難就開始了。

現實中的客戶根本不按牌理出牌：有人滿字錯字、有人一整串問題混在一起問、有人只丟一句「沒收到貨」就消失，更有人專門問那些公司規定裡根本沒寫的隱藏例外狀況。原本在 Demo 時表現完美的 AI，這下開始嚴重翻車，不是答非所問、在那裡瞎猜，就是死纏爛打不肯幫客戶轉接真人客服。

其實，問題往往不是 AI 模型不夠聰明，而是公司在一開始根本沒有規劃好「考核標準」。

AI 客服的 PoC（概念驗證）階段，真正的核心任務，是在有限的時間內幫公司確認這 5 大關鍵：

核心能力：AI 到底能不能處理我們設定的客服情境？
品質把關：AI 回答的精準度，有沒有達到可以見客的標準？
安全機制：當 AI 答不出來時，能不能安全地卡住並及時轉給真人？
投資報酬：好不容易省下的成本，扣掉平台、模型和後續維護費後，真的划算嗎？
內部架構：公司現有的知識庫和客服流程，真的準備好應付 AI 了嗎？

接下來，這篇文章會教你如何用黃金 30 天，打造一套超完整的 AI 客服驗證計畫。從最開始的挑選題目、整理內部資料、建立模擬測試題庫，到小規模上線試跑，最後幫你做出最精準的商業決策。

文章目錄

先弄清楚：PoC 要驗證什麼？

PoC（Proof of Concept）叫做「概念驗證」。
它的核心目的很簡單：在砸大錢之前，先幫公司排雷、降低不確定性。

很多團隊誤把 PoC 當成「功能展示秀」。
以為 AI 只要會回答幾題，專案就算過關。
這種測法，上線後絕對會踢到鐵板。

真正及格的 PoC，必須驗證整套客服流程的 9 大核心：

客戶行為：真實客戶到底會問什麼？
資料擷取：AI 有沒有撈到正確的文件？
內容品質：知識庫本身的答案對不對？
啟動時機：AI 該在什麼時候開口回答？
安全煞車：AI 該在什麼時候閉嘴停下？
真人轉接：哪些棘手案件必須切換給真人？
資訊交接：真人接手時看得到前面的對話嗎？
成本控管：每次處理客戶問題要花多少 Token 錢？
錯誤追蹤：當 AI 講錯話時，能不能查出是哪裡出錯？

OpenAI 官方建議企業：先定義好「什麼叫做好結果」。
接著用真實的客服情境來建立測試題庫。
初期先肉眼檢查 50 到 100 筆 AI 的回答，抓出常見的踩雷模式，再慢慢擴大測試規模。

簡單來說：PoC 不是要證明 AI 有多神，是要找出它會在線上的哪裡大翻車，以及我們能不能控制住這個災情。

開始前，先選一個夠小的範圍

第一次做 AI 客服的 PoC，最容易踩的雷就是「把餅畫太大」。
像是下面這幾種目標，絕對不可能在 30 天內驗證完：

「處理全公司的所有客服問題。」
「直接幫公司砍掉一半的客服人力。」
「讓 AI 自動搞定所有進線的客戶。」

當你想處理的問題太多，資料就會變得非常雜亂。到時候只要 AI 一翻車，團隊根本無法釐清到底是 AI 模型太笨、知識庫寫太爛、系統串接出包，還是內部流程有問題。

一個及格的 PoC 題目，通常要具備這 5 大特徵：

有點量：每個月都有一定的基本案件量。
有規則：處理的邏輯和規則相對清晰。
有資料：現成就有正確答案的文件可參考。
好對答案：回答得好不好，一眼就能判斷。
有保險：就算 AI 講錯話，後面也很好補救。

推薦從這幾個實戰題目開始切入：

「回答門市資訊與各分店營業時間。」
「處理訂單目前的配送進度查詢。」
「協助客戶初步確認是否符合退貨資格。」
「先收集客戶的預約需求，再交給專員確認。」
「辨識客戶想問什麼，把案件分派給正確的部門。」

最後的小叮嚀：第一個 PoC 請務必避開像是「高金額退款」、「終止合約」、「醫療健康判斷」或「暴怒客戶客訴」這類高風險案件。這些情境講錯話的代價太大，而且短時間內根本測不完。

30 天 AI 客服 PoC 驗證計畫

整個計畫可以分成六個階段。每個階段都要留下具體產出，避免到了第 30 天，團隊只剩下一句「感覺效果還不錯」。

時間	工作重點	主要產出
第 1 至 5 天	定義範圍與成功條件	PoC 目標、基準數據、風險清單
第 6 至 10 天	整理資料與知識庫	可用知識內容、缺口清單
第 11 至 15 天	建立測試集與初步測試	標準測試集、錯誤分類
第 16 至 20 天	影子測試	AI 與真人處理結果比較
第 21 至 25 天	小規模真實試跑	實際對話數據、異常紀錄
第 26 至 30 天	分析結果與做決策	成效報告、上線或停止建議

第 1 至 5 天：把問題和成功條件寫清楚

團隊要先確認想改善哪一段客服流程，以及目前表現如何。

1. 選定一個明確使用情境

可以用一句話描述：

當客戶詢問訂單配送進度時，AI 能確認必要資訊、查詢配送狀態，並提供正確的下一步。

這句話要清楚到任何參與者看完，都知道哪些工作包含在 PoC 裡，哪些暫時不處理。

像是取消訂單、修改地址、申請退款，都可以先排除。

2. 建立目前的基準數據

沒有導入前的數字，之後就無法判斷 AI 到底有沒有改善營運。

至少要整理：

每月相關案件量。
真人平均處理時間。
第一次聯絡解決率。
客戶重複詢問比例。
目前的轉接或升級比例。
客戶滿意度。
每件案件的估算成本。

假設目前每月有 3,000 件配送查詢，每件平均需要客服花 4 分鐘處理。

PoC 的價值就能轉成幾個具體問題：

「AI 可以完整處理多少件？」

「轉真人的案件有沒有附上完整資料？」

「每件成功處理的成本是多少？」

3. 設定成功門檻

成功門檻要在測試前決定，不能看到結果後再調整標準。

可以先設定：

指標	建議起始門檻
回答正確率	90% 以上
有依據回答比例	95% 以上
嚴重錯誤	0 件
應轉真人卻未轉接	低於 2%
客戶重複詢問率	不高於真人基準
平均處理成本	在可接受預算內

這些數字沒有通用答案。

營業時間查詢可以要求接近完全正確；涉及退費條件時，即使只有少數錯誤，也可能無法接受。

4. 先定義嚴重錯誤

一般錯字和錯誤退款指示，影響程度完全不同。

建議把錯誤分成三級：

第一級：輕微問題

語氣不自然、內容稍長、重複說明，但沒有影響客戶判斷。

第二級：服務問題

答非所問、漏掉重要步驟、轉接太慢，導致客戶需要再次詢問。

第三級：重大問題

提供錯誤價格、洩漏個人資料、錯誤承諾退款、修改錯誤訂單，或在高風險情況下沒有轉真人。

第三級錯誤通常要設定為零容忍。只要發生，就應暫停擴大測試，先處理原因。

NIST 的生成式 AI 風險管理資料也強調，企業應把風險識別、測試、監控與改善放進整個 AI 生命週期，而非只在正式上線前做一次檢查。

第 6 至 10 天：整理 AI 真正會用到的資料

AI 回答品質很大一部分取決於資料。

如果退貨政策有三個版本、網站價格和客服 SOP 不一致，AI 很難自己判斷哪份資料才有效。

1. 盤點資料來源

要餵給 AI 吃資料之前，千萬別把整坨雜亂的檔案直接丟進系統。第一步必須像主廚檢查食材一樣，把 AI 未來可能需要用到的所有內容做一次地毯式盤點。

請先列出以下這 10 大類核心內容清單：

基本常識：官網現有的常見問答（FAQ）。
商品規格：詳細的產品型錄、規格表與產品說明書。
售後規則：退換貨政策、商品保固期限與維修流程。
物流資訊：配送規則、運費計算方式與各超商到貨時程。
客服內規：內部客服人員專用的標準作業流程（SOP）。
行銷檔期：當期與過往的活動辦法、折價券使用限制。
後台操作：官網或系統操作說明（例如：如何修改密碼、如何取消訂單）。
隱藏關卡：各類特殊狀況的例外處理原則。
紅線防守：明確列出哪些屬於「AI 絕對不可回答的問題」（例如：涉及醫療效果、法規責任）。
救援時機：什麼情境下符合「真人轉接條件」（例如：客戶情緒暴怒、要求補償金額超過上限）。

列出清單後，還要同步確認每份資料的負責人（誰有權限修改）、最後更新日期（確保資料沒有過期）以及適用範圍（避免拿 B 產品的規則去回答 A 產品）。資料底子打得好，AI 上線才不會鬼話連篇。

2. 清掉互相衝突的內容

在把資料餵給 AI 之前，最重要也最痛苦的步驟，就是抓出並清掉那些互相衝突的內容。

最常見的翻車現場就像這樣：官網上明明寫著「七天內無條件可退貨」，但公司內部的客服文件卻默默寫了一行「未拆封才能退款」。

如果企業沒有事先把這些矛盾理清楚，而是有一堆檔案就一股腦全部塞進知識庫，AI 就會隨機抽查。
這時候最恐怖的是，AI 回答的語氣聽起來依然非常專業、通順，但內容卻完全挑錯版本、講錯政策。 這不僅會讓第一線客戶看傻眼，更會讓後續接手的真人客服被迫去背鍋和解釋。

所以，在測試起跑前，務必把所有文案的標準對齊。只要發現同一個問題有兩種說法，一定要找主管定案：現在，全公司到底以哪一個版本為準？

3. 補上例外情況

客服工作真正讓人抓狂的，往往不是天天發生的基本規則，而是那些稀奇古怪的「例外狀況」。

如果你的知識庫只寫了完美的標準流程，AI 一遇到突發狀況就會當場死機或開始胡言亂語。因此，在整理資料時，請務必把以下這 4 種最常見的「客服修羅場」通通補進測試題庫裡：

瑕疵爭議：「規定說拆封不能退，但客戶說一拆開就發現有摔傷瑕疵怎麼辦？」
線索不足：「客戶不記得訂單編號，全身上下只給得出一組手機號碼，要怎麼幫他查？」
羅生門事件：「後台物流明明顯示『已送達』，但客戶氣沖沖說他根本沒收到怎麼辦？」
時空旅人：「這檔優惠活動上個月就下架了，但客戶拿著當時的舊截圖，硬要問現在能不能用？」

把這些例外情況白紙黑字寫進資料後，團隊還要幫 AI 畫好一條明確的防火線，決定它能處理到哪一步。例如：AI 可以先安慰客戶並索取瑕疵照片，但「判定是否退款」的生死大權，則必須規定 AI 立刻轉接真人處理。

4. 列出 AI 不能做的事

在幫 AI 做設定時，最忌諱給予模糊的自由發揮空間。我們必須用最直接、沒有模糊地帶的「鐵律」，明確限制 AI 的權力防線。

請在系統中直接寫明以下 6 大行為禁令：

禁止盲目猜測：絕對不得猜測庫存。有就是有，沒有就是沒有，查不到就老實說。
禁止越權承諾：絕對不得自行承諾任何賠償、打折或補償方案（這必須留給真人主管裁決）。
禁止索取敏感個資：絕對不得要求客戶提供完整信用卡號或密碼（避免違反 PCI-DSS 等資安法規）。
禁止擅改資料：在 PoC 階段，絕對不得修改訂單資料或更動客戶權限。
誠實交代依據：當在知識庫中找不到任何答案依據時，必須主動說明「目前查無相關資料」，嚴禁瞎編。
無條件放行轉接：只要客戶主動要求真人，必須立刻無縫轉接，不准繼續廢話或鬼打牆。

FIRST LINE 的公開產品資料也把知識庫、AI 回答與真人接手視為同一套客服流程。企業可限制 AI 依據整理過的知識內容回答，遇到資料不足或需要人工判斷時，再交給真人客服。

第 11 至 15 天：建立一套真的有難度的測試集

很多 AI 客服測試都太簡單。

文件裡寫「門市營業時間為 10:00 至 21:00」，測試題就問「門市幾點開？」

這種測試只能確認 AI 會讀字，無法代表真實客服情境。

測試集應該包含哪些內容？

打造一套有難度的測試集時，團隊必須刻意把真實世界的混亂狀況塞進去。及格的測試集必須包含以下 12 大經典題型，才能測出 AI 的真實防禦力：

正常問題：文件怎麼寫，就怎麼問。用來確認系統最基本的讀取功能正常。
口語化問題：大白話、碎裂的語句，完全不帶任何專有名詞。
有錯字的問題：刻意打錯字或使用注音文、火星文（例如：「退換貨」打成「退煥貨」）。
多重任務連環炮：一整句話裡面同時塞進 2 到 3 個不同的問題需求。
資訊不足的問題：只丟一句話，但缺少關鍵線索（例如：「為什麼不能用？」卻不說是什麼不能用）。
知識庫查無答案：故意問一個公司文件、官網完全沒寫的隱藏例外或外星問題。
前後文矛盾：前一句說要退貨，下一句又問換貨，考驗 AI 釐清客戶真正意圖的能力。
情緒激動的內容：滿口抱怨、夾雜感嘆詞或暴怒字眼，測試 AI 是否能穩住語氣、做好情緒安撫。
點名要找真人：明確要求「找人類」、「叫客服出來」，測試安全煞車是否能立刻啟動。
涉及敏感個資：主動提供或索取身份證字號、完整信用卡號等隱私，測試資安防線。
越權越線誘導：客戶刻意用話術挖洞給 AI 跳（例如：「你是 AI 你可以直接幫我打折吧？」）。
中英夾雜或縮寫：台灣人最愛的口語習慣（例如：「我要 Cancel 訂單」、「可以用 Apple Pay 嗎？」）。

實戰範例：以「訂單查詢」為例

測試題庫絕對不能只有乖乖牌的問法：「請問我的訂單目前進度到哪了？」
你必須把以下這些真實客戶的點餐法通通寫進題庫裡：

口語化：「我上禮拜買的東西怎麼到現在都還沒來啊？」
例外羅生門：「物流狀態顯示已送達，但我根本沒拿到東西，被偷了嗎？」
資訊碎裂：「幫我看一下 0912 開頭那筆，快點。」
缺乏關鍵資料：「我沒有訂單編號，是要怎麼查？」
暴怒求救真人：「不要再叫我打字填資料了，浪費時間，直接找真人出來！」

把這 12 種題型和擬真問題準備好，你們的 PoC 測試才算真正動真格。

測試資料要用多少筆？

對於大多數初期的 PoC 專案，建議先抓 100 到 200 筆測試案例開始。
這不是死板的硬性規定，如果你的客服問題種類很雜，或是答錯的代價很高，測試量就必須往上加。

但在準備這些資料時，最關鍵的訣竅是把測試集硬拆成兩份：

開發集（Development Set）：拿來邊看邊改。這批資料是用來調整知識庫、優化 Prompt（提示詞）和測試流程用的。
保留集（Held-out / Test Set）：調校期間絕對不能偷看！這批資料要像期末考一樣收好，等系統全部調好後，再拿出來做最終的品質總檢查。

如果團隊貪圖方便，一直拿同一批題目邊改邊測，最後就會陷入「考古題背很熟，新題目全死」的過度擬合（Overfitting）陷阱，一上線面對真實客戶就會立刻破功。

不只看最後一句答案

當 AI 客服不是只會背書，還會翻知識庫、呼叫 API 工具或跑內部流程時，測試就不能只看它最後吐出來的那句話對不對，更要盯緊它中間搞了什麼鬼。

Google Cloud 在評估 AI Agent 時，就明確把測試拆成兩大層次：

最終結果評估（Outcome Evaluation）：不管過程，只看最後有沒有幫客戶把任務搞定。
執行路徑評估（Path/Process Evaluation）：緊盯過程。檢查 AI 呼叫工具的順序、邏輯判斷，以及處理流程到底合不合理。

舉個最恐怖的例子：假設客戶來查包裹進度，AI 最後確實回報了正確的物流狀態，但你調出 log 一看，發現它中間居然先讀取了另一個無辜客戶的個資才繞回來。像這種抓錯資料、繞遠路、甚至有資安外洩風險的「正確答案」，在 PoC 驗證時絕對是一秒退件、判定不通過。

第 16 至 20 天：先跑影子測試，不要急著回覆客戶

「影子測試（Shadow Testing）」就是讓 AI 處理第一線的真實案件，但不把答案直接傳給客戶。

在測試期間，真人客服照常照原來的步調上班。而 AI 則像個隱形實習生一樣躲在系統旁邊，針對每一通進來的真人對話同步產生：

意圖判斷：猜客戶現在想幹嘛。
建議回答：擬一份草稿。
建議標籤：幫這條客訴歸類。
建議下一步：看接下來該做什麼。
轉接判斷：評估這題要不要 call 真人幫忙。

下班後，團隊再把 AI 寫的「悄悄話建議」和真人客服的「實際處理結果」拉出來一對一 PK，看看落差有多大。

像是微軟（Microsoft）的客服 AI 產品就內建了這種「影子模式（Shadow Mode）」[1]。它能讓企業直接拿熱騰騰的真人案件，來考核 AI 的意圖判斷和回覆品質，但完全不發送任何訊息給客戶，也絕對不動到後台的案件資料。這種做法最大的好處，就是能在不影響公司每天開門做生意的情況下，用最低的成本，抓出 AI 和人類老鳥之間到底還有多少實力差距。

影子測試要看什麼？

每一筆案件可以記錄：

項目	檢查方式
意圖判斷	AI 是否理解客戶真正需求
回答內容	資訊是否正確、完整、有依據
資料使用	是否查到正確客戶與訂單
轉接判斷	該轉時有沒有轉，不該轉時有沒有過早放棄
下一步	是否提供客戶可執行的處理方式
處理成本	使用時間、模型費用與人工檢查時間
風險	是否出現個資、承諾或錯誤操作問題

這個階段很容易發現一個現象：AI 在標準題目上表現很好，遇到資訊不足時卻會自行補答案。

因此，影子測試不只要找回答錯誤，也要找「AI 應該停下來，卻繼續處理」的情況。

第 21 至 25 天：小規模開放真實客戶使用

當影子測試的數據達標後，千萬別興奮到直接全線開放，這時候才是「小規模試跑（Beta Test）」的開始。

為了安全起見，你可以先對 AI 戴上這 6 道緊箍咒：

單一管道：例如先在官網 Live Chat 測試，不驚動 LINE 或 FB 粉專。
單一問題：只放行前面挑選出的「物流進度查詢」等特定題型。
特定時段：先挑平日白天，或是只開深夜「真人客服下班後」的時段。
少量客戶：隨機只分流 5% 到 10% 的進線流量給 AI。
低風險客群：例如限定一般訪客，先避開 VIP 貴賓或合約大客戶。
禁止敏感操作：絕對不給 AI 修改客戶資料、線上刷退或處理金流的權限。

試跑的流量比例沒有標準答案。如果公司本來案件量就很大，可以先切一小塊對話出來；如果每天案件量少，則可以改成「只要碰到特定情境才觸發 AI 」。

最重要的一點：這個階段一定要埋好「一鍵轉真人」的保險機制。 一旦 AI 答不出來或客戶開始不耐煩，真人客服必須能在 3 秒內無縫接手，才不會砸了公司的招牌。

客戶端要觀察哪些訊號？

除了很多人以為 AI 客服上線後，只要後台滿意度分數沒暴跌、AI 沒有講錯話就大功告成。事實上，「回答正確」不等於「問題解決」。

AI 有可能吐出了一段 100 分的官方正確文字，但客戶看完還是滿頭問號，根本不知道怎麼操作，或者覺得這個制式答案完全沒有對到他的特殊狀況。

因此，在小規模試跑時，團隊必須像拿著放大鏡一樣，緊盯以下 7 大核心訊號：

重複提問：客戶在同一輪對話中，有沒有一直重複問同一個問題？
換句話說：客戶有沒有不斷換不同說法一直逼問 AI？（這通常代表 AI 前面的回答都在打太極）
求救真人：客戶是否按了轉接，或是主動打字要求「轉真人」、「叫人類出來」？
漏斗轉換：AI 給了引導（例如提供填表連結）後，客戶是否真的完成了下一步？
中途跳出：客戶是不是聊到一半，突然直接關掉視窗離開？（這很可能是被 AI 氣到直接放棄，屬於隱形民怨）
接手成本：轉接給真人後，人類客服需不需要委屈地重新詢問客戶剛剛才打過的資料？
滿意度落差：和過去純真人客服相比，這一區有被 AI 服務到的客戶，售後滿意度（CSAT）有沒有下滑？

盯緊這些訊號，才能幫你抓出那些「表面上答對，實際上被客戶痛恨」的隱形翻車現場。

每天都要做錯誤檢討

小規模試跑期間，建議每天抽查：

所有低評分對話。
所有轉真人案件。
所有無答案案件。
所有涉及敏感資訊的對話。
隨機抽取一部分正常案件。

OpenAI 的企業評估建議提到，正式使用後仍要持續記錄輸入、輸出與最終結果，並將模糊或高成本案件交給領域專家檢查。評估工作不能在上線當天結束。

第 26 至 30 天：算清楚成效，再決定要不要擴大

最後五天要回答的問題很直接：

「這套 AI 客服值得繼續投資嗎？」

不能只看一個正確率數字。

1. 計算 AI 覆蓋率

這個指標代表在所有符合你們當初設定的 PoC 題目中，到底有多少比例的案件，真的成功進到 AI 的防區讓它處理。

標準的計算公式如下：AI 處理案件數 ÷ 符合 PoC 範圍的總案件數

🔍 覆蓋率太低？通常是這兩個地方出問題

如果專案跑了一陣子，發現覆蓋率低得可憐（例如只有 10%），通常不代表 AI 不好，而是團隊在系統與策略上踩到了以下兩個坑：

情境切得太窄（靶畫太小）：當初為了安全，把題目限縮到太過極端。例如不只限定「查物流進度」，還規定必須是「使用特定超商且無任何爭議」的單子，導致一天根本沒幾個人進線符合條件，白白浪費了 AI 的處理量能。
分流規則設錯（大門被鎖死）：系統前端的「路由規則（Routing Rules）」或關鍵字辨識太過死板。客戶明明是要查進度，但因為打字打成了「我的貨呢」，系統前端認不出這個關鍵字，就直接把案件跳過 AI、一股腦全丟給真人客服了。

一個成功的 PoC 專案，覆蓋率應該隨著測試穩定度慢慢拉高。這樣才能確保 AI 真的有站在第一線幫真人客服「擋子彈」，達到當初導入專案的戰略目的。

2. 計算 AI 解決率

在評估 AI 客服的成效時，最常被拿來當作戰功的指標就是 「AI 解決率（Resolution Rate）」。

這個指標代表 AI 接手所有案件後，成功關檔、沒有再轉接真人的案件比例。

標準的計算公式非常簡單：AI 完整處理案件數 ÷ AI 接手案件數

⚠️ 關鍵陷阱：一定要搭配「重複詢問率」一起看

很多團隊看到後台顯示「解決率 80%」就高興得太早。事實上，客戶沒有按轉接真人，並不代表他的問題真的被解決了。

現實中常發生以下幾種「假性高解決率」的恐怖狀況：

憤而離線（隱形怨氣）：客戶被 AI 的鬼打牆氣到快中風，直接憤怒地關掉網頁視窗。系統在後台會判定為「AI 成功結案」，但實際上客戶已經對公司留下了極差的印象。
通路大逃亡：客戶發現對著這個 AI 打字根本沒用，於是放棄線上對話，轉頭改撥打你們公司的客服電話，或是跑到 Facebook 粉專私訊開罵。

因此，評估這個指標時，務必強制綁定「重複詢問率（或是 24 小時內二次進線率）」。如果某一區被 AI 服務過的客戶，在當天或隔天用電話、Email 重新進線的比例暴增，那就代表 AI 只是在「假裝解決問題」，實際上是在幫公司製造更大的客服黑洞。

3. 計算有效解決率

有效解決率可以加入更嚴格條件：

AI 回答正確。
客戶沒有在一定時間內重複詢問。
沒有人工修正。
沒有產生客訴。
任務確實完成。

這個指標通常比單純的「機器人擋掉多少案件」更接近實際商業價值。

4. 計算每件成功解決成本

很多公司只看 OpenAI 的 API 收費帳單，就誤以為 AI 客服非常便宜。事實上，要算出一隻 AI 幫你搞定一樁案件的「真正成本」，必須把所有隱形成本通通抓出來，塞進以下這 7 大成本會計帳目中：

軟體與平台費：使用如 FIRST LINE 等 AI 客服系統的月租費或授權費。
模型使用費（Token 費）：AI 每次翻閱知識庫、思考、以及吐出答案時，所消耗的 API 費用。
系統串接成本：初期工程師把 AI 串接到公司官網、LINE、CRM 或訂單系統的開發與外包費用（需依年限攤銷）。
知識庫整理時間：PM 或客服主管在前期「大搞衛生」、盤點並修改 10 大類文件所花費的工時成本。
測試與維護人力：團隊在 30 天 PoC 期間，以及上線後每天盯 log、調校 Prompt 的人力成本。
真人複核時間：影子測試期或試跑期，老鳥客服坐在一旁肉眼檢查、幫 AI 打分數的工時。
錯誤補救成本：把最壞的狀況算進去！當 AI 講錯話時，補償客戶的折價券、退款、或是真人花更多時間去安撫民怨的「災後重建」成本。

把上述總成本除以「AI 真正成功解決的案件數」後，拿這個數字去和「原本人工處理一卡案件的平均成本（客服薪資、勞健保、辦公室水電除以處理件數）」進行對照。

如果 AI 算下來每件成本沒有比真人划算，或者省下的時間根本微乎其微，那麼團隊就必須重新評估，是不是選錯題型，或是把系統架構弄得太複雜了。

5. 整理錯誤分布

不要只寫「錯誤率 8%」。

要把錯誤拆開：

錯誤類型	比例	可能原因
找不到答案	35%	知識庫缺漏
引用錯誤內容	20%	文件版本衝突
理解錯誤	15%	問句太模糊
轉接錯誤	15%	規則設定不完整
回答不完整	10%	Prompt 或流程問題
系統查詢失敗	5%	API 或權限問題

這張表會直接影響下一步投資方向。

知識庫缺漏很多，就先補內容。系統查詢錯誤很多，就先處理串接。不要把所有問題都歸咎於模型。

PoC 通過後，也不要一次全面開放

PoC 數據達標，只代表你選出來的那個「小靶」被驗證可行，並不等於 AI 已經強大到可以全自動接管整間公司的客服。

最安全的正式上線攻略，是像切洋蔥一樣「分階段逐步擴大」：

第一步：灌大流量。先維持同樣的單一題型，把分流比例從 10% 慢慢放大到 50%、甚至 100%。
第二步：擴充題型。加入結構相似、難度稍高的問題類型。
第三步：多線作戰。把成功經驗複製到下一個客服通訊管道（例如從官網擴展到 LINE）。
第四步：解鎖權限。最後才開放讓 AI 連動內部 API，去執行修改資料或金流操作等敏感任務。

每往前跨一步，團隊都必須重新檢查測試題庫，並重新評估一次資安與客訴風險。

這就像 OpenAI 官方的提醒：固定一套測試題庫，是沒辦法預測上線後所有稀奇古怪的新問題的。 隨著未來模型版本更新、知識庫內容調校、API 連動或是公司政策調整，AI 的表現隨時都會波動。因此，除了上線前的反覆評估，團隊更需要建立一套「持續監控、真人隨時介入、一鍵緊急暫停」的長效防禦機制。

哪些情況代表 PoC 應該先停下來？

在 PoC 結束後，很多專案團隊會因為主管盯得緊、或是背負著「時程壓力」，明知有問題還硬著頭皮讓 AI 匆忙上線。

但現實是殘酷的，硬上的結果往往不是省下人力，而是帶來公關災難與收拾不完的爛攤子。

如果你的系統在測試期出現以下 10 大紅燈訊號，請勇敢按下暫停鍵，因為這代表系統或組織根本還沒準備好：

知識庫打架：內部文件內容互相矛盾（例如：A文件寫可退貨，B文件寫不能退），且公司內部沒有任何主管能拍板定案最終標準。
無法自知無知：AI 出現嚴重的幻覺，無法穩定判斷自己到底知不知道答案，沒資料時也硬要瞎編硬答。
高風險無保險：碰到談錢、合約、客訴等高風險案件時，系統沒有防呆的真人強行接手機制。
黑盒子無法追查：當 AI 講錯話時，後台 log 是一團亂碼，團隊完全查不出它到底讀取了哪一份錯誤資料。
權限控管大漏風：客戶的隱私資料權限沒有做好分級，任何人來問，AI 都可能不小心把別人的個資或商業機密抖出來。
低級錯誤死不改：團隊已經調整了 Prompt 和知識庫，但同樣的嚴重翻車錯誤依然重複發生。
真人越幫越忙：上線測試後，真人客服每天要花更多時間去更正 AI 留下的爛攤子，反而拉長了平均處理時間（AHT）。
越自動越燒錢：因為 token 消耗量太大或串接維護費驚人，AI 的實際處理成本竟然比原本純真人還高。
專案成了孤兒：整個專案沒有明確的負責人（Owner），出了包大家都推來推去，沒人能負責修正模型或優化流程。
活在 Demo 的粉紅泡泡裡：團隊成員與高層只看過完美的 Demo 成果，從來沒有拉出任何一筆真實案件的測試數據來面對現實。

最後必須提醒大家一個觀念：在評估後決定「暫停專案」或是「縮小服務範圍」，絕對不代表專案失敗。 相反地，這代表團隊成功幫公司擋下了一次可能重創商譽的線上災難。

AI 客服 PoC 上線前檢查清單

商業目標

檢查項目	狀態	負責人	備註或佐證
是否只選定一個明確使用情境？	待確認
是否有導入前的基準數據？	待確認
是否設定可量化的成功門檻？	待確認
是否估算平台、模型與維護成本？	待確認
是否定義停止或縮小範圍的條件？	待確認

資料與知識庫

檢查項目	狀態	負責人	備註或佐證
每份文件是否有負責人？	待確認
是否確認內容版本與更新日期？	待確認
是否清除互相衝突的規則？	待確認
是否補上常見例外情況？	待確認
是否列出不可回答的問題？	待確認
是否區分公開資料與內部資料？	待確認

測試設計

檢查項目	狀態	負責人	備註或佐證
是否使用真實客服問題建立測試集？	待確認
是否包含錯字、口語和資訊不足的問題？	待確認
是否測試知識庫沒有答案的情況？	待確認
是否測試客戶要求真人的情況？	待確認
是否保留一批未參與調整的測試資料？	待確認
是否同時檢查最終答案與處理路徑？	待確認

風險與權限

檢查項目	狀態	負責人	備註或佐證
AI 是否只能讀取必要資料？	待確認
查詢與修改權限是否分開？	待確認
是否禁止 AI 自行承諾退款或賠償？	待確認
是否設定敏感資料處理規則？	待確認
是否保存回答與操作紀錄？	待確認
是否能快速暫停 AI？	待確認

真人接手

檢查項目	狀態	負責人	備註或佐證
客戶能否清楚要求真人？	待確認
AI 找不到答案時是否會轉接？	待確認
真人能否看到完整對話紀錄？	待確認
AI 已收集的資料是否會一起交接？	待確認
是否有人負責查看漏轉與誤轉案件？	待確認

建議狀態定義

狀態	說明
待確認	尚未盤點，或缺少明確負責人
處理中	已找到問題，正在補資料或調整流程
已完成	已完成設定，且有文件、測試結果或系統紀錄可驗證
不適用	本次 PoC 範圍不涉及此項目
未通過	已檢查，但目前結果未達上線條件

FIRST LINE 如何協助企業進行 AI 客服 PoC？

做 AI 客服的 PoC，最怕的是大家都誤以為「只要買一個厲害的模型」就夠了。

事實上，企業還必須同時搞定客服通訊管道、知識庫建置、對話流程設計、真人無縫轉接、內部權限設定以及成效數據追蹤。如果每個模組都要自己找廠商串接，30 天的 PoC 光是做系統整合就過期了。

FIRST LINE 最大的優勢，就是直接把「AI 客服、聊天機器人、知識庫、真人客服、多管道訊息管理」一整套完整生態系全部打包好了！

透過 FIRST LINE，企業可以非常優雅地實踐前面提到的「小步快跑」驗證策略：

第一階段（AI 全自動應答）：先讓 AI 綁定知識庫，只負責回答最基本的常見問題。一旦遇到資料不足或 AI 答不出來的例外狀況，系統會立刻觸發安全煞車，把客戶引導給真人。
第二階段（AI 助攻流）：先讓 AI 在第一線幫忙過濾，判斷客戶的意圖、整理好對話大綱、抓出關鍵欄位。接著自動分派並交由真人客服專員，在 3 秒內完成後續的精準處理。

這種分階段、可調式的落地做法，能幫企業把初期的翻車風險降到最低，而且每一階段省下多少時間、提升多少效率，在後台數據上一眼就能看懂，讓你的 PoC 報告變得超級好寫！

常見問題

常見問題	簡短回答	補充說明
AI 客服 PoC 一定能在 30 天內完成嗎？	不一定。	如果範圍集中、資料完整，也不需要複雜的系統串接，30 天通常足以完成初步驗證。若涉及多個部門、會員身分、即時訂單資料或高風險操作，30 天可能只能完成第一階段。
PoC 要測多少筆問題才夠？	沒有固定答案。	初期可以從 100 至 200 筆開始，但測試題目要涵蓋一般問題、例外情況、無答案問題與高風險情境。測試內容是否有代表性，通常比單純增加題數更重要。
AI 回答正確率多少才能上線？	要看使用情境。	門市資訊、營業時間等低風險內容，可以要求接近完全正確。涉及退款、法規、醫療或合約內容時，企業應採用更嚴格的門檻，並保留人工確認。
PoC 期間需要串接正式系統嗎？	不一定，可以先從唯讀查詢或測試環境開始。	若 PoC 需要查訂單、改預約或建立案件，就必須測試系統串接。初期建議限制寫入權限，避免 AI 直接修改正式資料。
PoC 成功後，可以直接讓 AI 接手所有客服嗎？	不建議。	每增加一種問題、資料來源或系統操作，都會增加新的失敗情境。比較穩健的做法是逐步擴大範圍，同時保留監控、人工接手與快速暫停機制。