先挑出能回答、必須確認、應交人工的問題
以虛構的商品客服為例，營業時間可以依現行公告回答；查詢個人訂單需要驗證身分及系統權限；退款、折扣和客訴則涉及承諾與判斷。這些問題不能放進同一個「全部自動回答」的需求裡。
| 問題類型 | 試點做法 | 先確認的條件 |
|---|---|---|
| 營業時間、配送說明 | 依核准文件整理草稿 | 資料現行版本與更新人 |
| 個人訂單狀態 | 另行評估查詢功能 | 身分核對、權限與訂單系統介面 |
| 退款、優惠、交期承諾 | 交由有權限的人確認 | 業務授權與例外處理責任 |
| 沒有來源或內容矛盾 | 停止推測，標記待處理 | 接手窗口與對客戶的說明 |
第一個試點，可以只做客服草稿
先用去識別化的歷史問題測試，請客服核對 AI 找到的依據與答案。只要一開始還沒接對外發送，錯誤較容易攔下，也能看出目前文件缺哪些內容。這不是正式上線，也不能把離線測試的正確率直接當作未來服務表現。
客服草稿試點
- 整理問題去識別化並分出常見與例外
- 依來源起草保留文件版本與支持段落
- 客服確認修改、核准，或改交專責窗口
先驗證草稿是否可用，再討論哪些問題可以開放自動發送。
真人接手，要定義開始與結束
不能只在畫面上放一顆「轉人工」。需要確認誰收到通知、待處理案件在哪裡、Bot 何時停止回答，以及真人處理完後由誰恢復。若非服務時段，也要清楚說明後續處理方式，不能讓 AI 聲稱真人正在接聽或案件已完成。
正式串接還要處理重複事件、發送失敗與重試。例如同一個事件被重送，不應再建立一筆相同案件或多次發送承諾。技術排查可看 LINE AI 客服重複回覆與真人接手；選型時先請供應商說明會如何驗收這些情境。
接手責任示意
- 觸發接手無來源、客訴或需要業務授權
- 標記與通知指定處理人，暫停該案件自動回答
- 結案或恢復留下處理紀錄，由約定角色確認
讓接手狀態可查，不能只靠客服自己記得目前輪到誰。
詢價時，把這六項費用攤開
- 資料整理：FAQ、規則、版本、對話樣本與更新責任。
- 開發串接：通訊平台、客服介面、必要內部系統與權限。
- 模型用量：依實際輸入輸出、模型和使用頻率估算，不只看對話人數。
- 平台與主機：訊息方案、執行環境、資料儲存及紀錄保存。
- 測試與教學：問題測試、人工接手演練、操作和排錯交接。
- 維護：文件改版、服務異常、介面變更和新增需求如何處理。
LINE 的訊息方案與計數依平台規則而定，可參考 LINE 官方 Messaging API 費用說明。通訊平台費用與模型 API 是不同項目，不能假設開通其中一個就包含另一個。本文不提供未經需求確認的固定系統報價。
驗收別只問「回答得像不像真人」
測試至少涵蓋正常問題、找不到依據、過期規則、需要人工核准、無權限資料、服務失敗及重複事件。每題記下預期處理方式，再核對來源、答案、發送對象與接手狀態；另外看客服修正草稿所花時間，不能只量生成速度。
上線條件可使用 AI 試點驗收表。如果錯誤仍需要客服逐句重寫，就先修文件或縮小範圍；不要為了達成「自動化」而取消檢查。
先提供流程概況，再安排資料
我想討論企業 AI 客服試點。
使用平台／客服人員與服務時段：
每天大約問題量、最常見的問題：
目前 FAQ／規則文件與維護窗口：
希望做到草稿、指定問題自動回答，或系統查詢：
一定要由真人確認的內容：
需要串接的系統與帳號條件：
預計時程與預算範圍（未定可註明）：資料提供方式確認前，先不要傳客戶個資、內部網址或帳號金鑰。團隊如果主要需要學會整理 FAQ、查證與修正草稿，可先討論 企業 AI 實作內訓；正式對外串接則另行評估 導入與開發範圍。
常見問題
企業 AI 客服導入可以先不自動回覆嗎？
可以。先讓 AI 整理問題、找依據和產生草稿，由客服確認後發送，是一種可評估的試點範圍；後續再依測試結果與風險決定是否開放特定自動回覆。
AI 客服可以承諾退款、折扣或交期嗎？
第一階段宜保留人工核准。若要自動處理，需另外確認授權規則、系統串接、測試與例外責任；不能只因模型能生成文字就當成獲得業務授權。
AI 客服費用只要算模型 API 嗎？
還要確認客服資料整理、通訊平台方案、主機與紀錄、帳號權限、串接開發、測試訓練和維護。各項是否包含及用量前提應分開列明。
資料查核：2026 年 11 月 5 日。分類、流程與測試為教學示例，非客戶成效或固定方案。