「我們決定要導入 AI 客服了，那接下來呢？」
這通常是老闆點頭之後，專案負責人遇到的第一個問題。要花多久？客服同仁要撥出多少時間？什麼時候可以開始讓 AI 回客人？上線之後如果答錯了怎麼辦？
在〈AI 客服系統怎麼建置〉裡，我們整理了 AI 客服的架構與建置步驟。這篇換一個角度，從專案管理來看：用一個情境案例，把一個標準規模的 AI 客服導入專案，從第 0 週走到上線後 90 天。
先說結論：
一個標準規模的 AI 客服導入，大約需要 10 到 12 週。真正決定時程的通常不是技術，而是兩件事：客服同仁能不能撥出時間整理知識與驗收，以及每個階段的「放行條件」有沒有事先講好。
情境設定：A 品牌
為了讓流程具體一點，以下用一個虛構的情境來說明。這不是特定客戶的真實案例，而是把中小企業導入 AI 客服時常見的條件組合在一起：
| 項目 | A 品牌的狀況 |
|---|---|
| 產業 | 保養品牌，官網電商加上 3 間門市 |
| 客服入口 | LINE 官方帳號（主要）、官網對話視窗 |
| 客服人力 | 2 位客服，週一到週五 9:00–18:00 |
| 訊息量 | 每月約 2,500 則對話，下班後與週末的訊息約占三成 |
| 系統 | 電商平台（有訂單查詢 API）、門市庫存用 Excel 每天更新 |
| 痛點 | 重複問題太多、晚上的訊息隔天才回、促銷期間客服忙不過來 |
A 品牌的目標很明確：讓 AI 處理常見問題與訂單查詢，晚上與週末也能即時回覆，客服同仁把時間留給客訴與複雜問題。
1. 整體時程：12 週分成六個階段
| 階段 | 時間 | 主要交付物 |
|---|---|---|
| 0. 專案啟動 | 第 0 週 | 目標、範圍、分工、時程 |
| 1. 診斷盤點 | 第 1–2 週 | 問題分布表、紅黃綠燈分類、範圍說明 |
| 2. 知識整理與規則 | 第 3–4 週 | 知識庫初版、轉接規則表、回覆語氣規範 |
| 3. 建置與串接 | 第 4–7 週 | 可測試的 AI 客服、LINE 與訂單系統串接 |
| 4. 測試驗收 | 第 8 週 | 測試題庫、驗收報告 |
| 5. 分段上線 | 第 9–12 週 | 影子模式 → 夜間與假日 → 全時段 |
| 6. 持續優化 | 第 12 週之後 | 每週檢視、每月成效報告 |
知識整理與建置有一週是重疊的：知識庫初版完成一部分，系統就可以先接上去測試，不必等全部整理完。
2. 第 0 週：專案啟動，先把分工講清楚
AI 客服不是「交給廠商做就好」的專案。最了解客人會問什麼、標準答案是什麼的人，是公司自己的客服同仁。啟動會議最重要的事，就是把誰負責什麼、要投入多少時間講清楚。
| 角色 | A 品牌由誰擔任 | 主要工作 | 預估投入 |
|---|---|---|---|
| 專案負責人 | 營運主管 | 定目標、拍板範圍、決定是否放行上線 | 每週 30 分鐘例會 |
| 客服主管 | 資深客服 | 提供對話紀錄、標註問題分類、撰寫標準答案、驗收 | 前 8 週每週約 4–6 小時 |
| 資料擁有者 | 商品與行銷人員 | 確認商品資訊、促銷活動、退換貨政策正確 | 集中在第 3–4 週 |
| IT／系統窗口 | 電商平台的技術聯絡人 | 提供 API 權限與測試帳號 | 集中在第 4–7 週 |
| 導入夥伴 | 外部顧問或內部開發團隊 | 架構設計、建置串接、測試題庫、監控 | 全程 |
啟動會議還要決定三件事：
- 成功的定義：A 品牌定的是「上線三個月後，綠燈問題的自動解決率達七成，且答錯率低於 3%」。沒有這個目標，之後很難判斷專案到底成不成功。
- 不做什麼：第一期不處理退款、不做會員點數查詢、不接 Facebook 私訊。範圍越清楚，時程越不容易失控。
- 例會節奏：每週固定 30 分鐘，看進度、看卡關、做決定。
3. 第 1–2 週：診斷盤點，用資料決定先做什麼
這個階段的工作是把「感覺上很多人在問」變成數字。
A 品牌匯出 LINE 官方帳號近三個月、約 7,500 則對話，由導入夥伴先用 AI 做初步分類，再由客服主管逐類確認。結果大致如下：
| 問題類型 | 占比 | 分類 |
|---|---|---|
| 訂單出貨進度 | 22% | 綠燈（需查訂單系統） |
| 商品功效、成分、適用膚質 | 18% | 綠燈 |
| 促銷活動與優惠規則 | 12% | 綠燈 |
| 門市地址、營業時間、庫存 | 10% | 綠燈 |
| 退換貨流程 | 9% | 黃燈 |
| 皮膚過敏或使用後不適 | 4% | 紅燈 |
| 退款、賠償、客訴 | 6% | 紅燈 |
| 其他 | 19% | 逐題判斷 |
表格中的數字是情境示意，用來說明分析方式，不是實際統計。
紅黃綠燈的判斷方式，在〈AI 客服系統怎麼建置〉第 1 節有詳細說明。這裡要特別注意一點：像「皮膚過敏」這種涉及健康與安全的問題，即使出現頻率不高，也一定要列為紅燈。 分類看的不只是數量，還有答錯的代價。
這個階段的交付物是一份範圍說明：第一期 AI 要處理哪些問題、哪些一律轉真人、哪些暫時不做。之後所有的建置與驗收都以它為準。
4. 第 3–4 週：知識整理與規則設計
這是最容易被低估、也最常延誤的階段。
A 品牌在整理知識時發現了幾個典型問題：
- 同一件事有好幾個版本：官網寫「拆封後 7 天內可退換」，但門市實際做法是「未拆封才能退」，客服回覆時又依個人經驗判斷。
- 資訊散落各處：商品成分在電商後台，促銷規則在行銷的簡報裡，門市營業時間在 Google 商家。
- 很多答案只存在資深客服的腦中：例如哪些商品可以混搭使用、敏感肌建議先用哪一款。
所以這個階段除了「把資料交給 AI」，往往也是公司第一次把標準答案統一。A 品牌最後由營運主管拍板，統一了退換貨規定，再同步更新官網。
這個階段有三份交付物：
- 知識庫初版：FAQ、商品資料、活動規則、門市資訊，整理成 AI 讀得懂的格式。整理原則可以參考〈導入 RAG 知識庫前，先確認這 5 件事〉。
- 轉接規則表：什麼情況要轉真人、轉接時要附上什麼資訊、非營業時間怎麼回覆。
- 回覆語氣規範：用「您」還是「你」、能不能用表情符號、回覆長度上限、每則回覆是否要標示這是 AI。
另外要在這時候就決定誰負責日後更新知識。A 品牌指定行銷人員在每次活動上線前，同步更新活動規則到知識庫。
5. 第 4–7 週：建置與串接
技術細節在〈AI 客服技術實作：LINE Messaging API × LLM 的架構與程式範例〉有完整說明，這裡只談專案管理上要注意的事。
系統權限要提早申請。 A 品牌的電商平台需要由平台方開通 API 權限，前後花了一週半。這類等待通常不在導入夥伴能控制的範圍內，最好在第 0 週就開始申請。
沒有 API 也能先做。 門市庫存沒有 API，A 品牌改用每天匯出 Excel 自動同步的方式。精確度只到「昨天晚上的庫存」，所以 AI 回覆時會加上「實際庫存請以門市為準，需要的話可以幫您轉接門市確認」。先用簡單的方式上線，日後再升級，比等系統完美才開始更實際。
每週給客服同仁試用。 從第 5 週開始，每週把最新版本給客服主管試問，即時回饋「這題答得不像我們會說的話」、「這個優惠已經結束了」。越早發現問題，越不會在驗收時才大改。
6. 第 8 週：測試驗收，標準要在測試前訂好
驗收最常見的問題，是測完之後才開始討論「這樣算不算過」。所以驗收標準要在第 0 週到第 4 週之間就和專案負責人確認。
A 品牌的測試題庫約 200 題：
- 真實問題：從第 1–2 週盤點的對話中挑出，每一類綠燈與黃燈問題都要涵蓋。
- 刁鑽問題：知識庫裡沒有的問題、要求 AI 給折扣、要求保證效果、情緒性抱怨。
- 不同問法：口語、錯字、注音文、中英夾雜、一次問兩件事。
驗收標準：
| 項目 | 標準 |
|---|---|
| 綠燈問題答對率 | 95% 以上 |
| 紅燈問題 | 100% 轉接真人，不得自行回答 |
| 知識庫裡沒有的問題 | 回答不知道並提供轉接，不得編造答案 |
| 承諾類請求（折扣、退款、保證效果） | 一律不承諾，引導至真人或既有流程 |
| 回覆速度 | 九成以上的回覆在 5 秒內送出 |
紅燈問題的標準是 100%，不是 95%。 綠燈題答錯一題，影響的是一位客人的體驗；紅燈題答錯一題，可能就是一件客訴或法律糾紛。
題庫不是測完就丟。之後每次更新知識庫或調整提示詞，都要重跑一次，確認沒有把原本答對的題目改壞。
7. 第 9–12 週：分段上線，每一段都有放行條件
通過驗收不代表可以直接全面上線。測試題庫再完整，也比不上真實客人的千奇百怪。A 品牌分成三段上線，每一段都要符合放行條件，才能進到下一段：
第一段：影子模式（第 9–10 週）
AI 不直接回覆客人，而是在客服後台產生建議回覆，由客服同仁確認、修改後再送出。客服同仁每次修改，都會被記錄下來，作為調整知識庫的依據。
放行條件：客服直接採用或只做小幅修改的比例達到八成，而且紅燈問題沒有任何一次誤答。
第二段：夜間與假日上線（第 11 週）
下班後與週末，由 AI 直接回覆；白天仍維持影子模式。這段時間沒有真人可以即時補救，所以轉接規則要特別注意：遇到紅燈問題時，AI 要告訴客人「已記錄您的問題，客服人員將於下一個工作日上午回覆」，並把對話摘要排進隔天早上的待辦。
放行條件：每天抽檢對話，答錯率低於 3%；所有轉接的對話，隔天都有真人跟進。
第三段：全時段上線（第 12 週）
白天也由 AI 先回覆，客服同仁的角色轉為處理轉接、客訴與 AI 處理不了的問題，並每週檢視 AI 的對話紀錄。
放行不是單向的。 如果某一段出現嚴重問題，例如促銷活動規則更新沒同步、AI 連續答錯，就要能立刻退回上一段。這個「退回機制」要在上線前就準備好，而不是出事時才臨時討論。
8. 上線後 90 天：建立維運節奏
正式上線只是開始。前三個月是 AI 客服變好最快的時期，也是最容易因為沒人管而變差的時期。
| 頻率 | 做什麼 | 誰負責 |
|---|---|---|
| 每天（第一個月） | 抽檢 20–30 則對話，標記答錯與不自然的回覆 | 客服主管 |
| 每週 | 檢視答錯、轉接、客人給負評的對話，補充知識庫或調整規則 | 客服主管、導入夥伴 |
| 每次活動前 | 更新活動規則到知識庫，重跑相關測試題 | 行銷人員 |
| 每月 | 成效報告：自動解決率、轉接原因分布、答錯率、客戶滿意度 | 導入夥伴、專案負責人 |
上線後第一個月，最常見的狀況是：
- 出現大量盤點時沒看到的問題：例如客人開始問「你是真人嗎？」、「可以幫我推薦送禮組合嗎？」。這很正常，代表客人願意跟 AI 對話，把它們補進知識庫即可。
- 轉真人率比預期高：通常是轉接條件訂得太保守。先從轉接原因分布找出最大宗，逐步放寬。
- 客服同仁不放心：前幾週會想每一則都檢查。這時候抽檢報告的數字最有說服力，讓同仁看到 AI 實際答對的比例，信任會逐漸建立。
上線三個月後，再回頭看第 0 週訂的成功定義，決定第二期要擴充什麼，例如加入會員點數查詢、接上 Facebook 私訊，或是讓 AI 處理退換貨申請的資料收集。
9. 時程最常延誤的 5 個原因
- 客服同仁沒有被排出時間：知識整理與驗收都需要客服主管參與。如果他還要照常負責所有客服工作，專案一定會延誤。建議在專案期間減輕他的日常工作量。
- 系統權限太晚申請：API 開通、測試帳號、資安審查，都可能要等好幾週。第 0 週就開始申請。
- 範圍一直擴大：做到一半想加會員查詢、想接更多通路。新需求可以記下來，放進第二期。
- 驗收標準沒有事先講好：測完才討論「這樣算不算過」，很容易陷入反覆修改。
- 標準答案無法拍板：知識整理時發現各部門說法不一致，卻沒有人能做決定。這就是為什麼專案負責人要能拍板。
10. 不同規模的時程參考
A 品牌屬於標準規模。實際時程會依範圍與公司現況而不同：
| 規模 | 範圍 | 常見時程 |
|---|---|---|
| 輕量 | 只做常見問題問答，單一 LINE 入口，不串接系統 | 約 4–6 週 |
| 標準 | 常見問題加上訂單查詢、轉接真人，LINE 加官網兩個入口 | 約 10–12 週 |
| 進階 | 多通路、多系統串接（會員、預約、門市 POS）、多語言 | 約 3–6 個月 |
影響時程最大的變數是資料的完整度。如果公司已經有整理好的 FAQ 與商品資料，知識整理可能一週就完成；如果大部分答案只存在客服同仁的腦中，就要預留更多時間。
結語：先把專案跑起來，再讓 AI 變聰明
回頭看整個流程，技術建置只占 12 週裡的 4 週。其餘時間都在做「人」的事：決定範圍、統一答案、訂驗收標準、逐步建立信任。
這也是為什麼我們建議不要等一切都準備好才開始。從前 20 大常見問題做起，用分段上線控制風險，上線後每週改善，比花半年規劃一套完美的系統更有效。
如果你正在評估導入 AI 客服，可以從導入診斷開始：我們會分析你近期的客服對話，估算哪些問題最值得先自動化、需要串接哪些系統、專案大約需要多少時間與內部人力，讓你在啟動前就知道整個專案的樣子。
參考資料
- 諾秋工作室，〈AI 客服系統怎麼建置：從規劃、架構到上線的完整指南〉
- 諾秋工作室，〈AI 客服技術實作：LINE Messaging API × LLM 的架構與程式範例〉
- 諾秋工作室，〈導入 RAG 知識庫前，先確認這 5 件事〉
- LINE Developers，〈Messaging API overview〉