客戶問：
「忘記密碼要怎麼處理？」
客服回答一次。
隔天，另一位客戶又問：
「密碼忘記了，要去哪裡重設？」
另一位客服再重新回答一次。
過幾天，新進客服遇到相同問題，卻因為不知道公司原本的標準處理方式，只能在群組裡詢問同事。
這種情況看似只是「重複回答問題」，但當客服量逐漸增加之後，真正造成成本的往往不是問題本身，而是：
同一份知識，不斷被不同的人重新尋找、重新整理、重新回答。
這也是企業建立 客服知識庫（Knowledge Base） 的主要原因。
而到了 AI 客服逐漸普及的現在，知識庫又多了一個新的角色：
它不只讓「人」找到答案，也開始成為 AI 回答客戶問題的重要資訊來源。
因此，企業真正需要思考的已經不只是：
「FAQ 要寫哪些問題？」
而是：
如何把分散在客服人員、文件、工單與公司內部的知識，整理成一套人與 AI 都能使用的客服知識庫？
什麼是客服知識庫？
客服知識庫可以理解為：
集中保存客服回答問題所需要資訊的地方。
內容可能包含：
- 常見問題 FAQ
- 產品使用方式
- 帳號與登入說明
- 付款與退款規則
- 配送與退換貨流程
- BUG 排除方式
- 活動規則
- 客服處理 SOP
- 內部操作流程
- 異常狀況處理方式
- 不同案件的標準回覆內容
以前這些資訊可能分散在 Word、Google Docs、Excel、公司 Wiki、Email、LINE 群組，甚至存在資深客服人員的記憶裡。
問題是，只要資訊散落在不同地方，每一次客服要回答客戶，都必須重新尋找答案。
知識庫的作用，就是把這些資訊整理成：
可以搜尋、可以更新、可以管理，也可以重複使用的企業知識。
FAQ 跟知識庫有什麼不同？
FAQ 是 Frequently Asked Questions，也就是「常見問題」。
例如：
Q：忘記密碼怎麼辦？
A：請至登入頁面點選「忘記密碼」，系統會寄送重設密碼信件至註冊信箱。
這就是一則典型 FAQ。
FAQ 最大特色是：
一個問題，對應一個相對明確的答案。
但 Knowledge Base 的範圍比 FAQ 更大。
例如一家電商的知識庫可能包含：
FAQ：
商品多久會出貨？
操作教學：
如何查詢訂單配送進度？
政策文件：
退換貨與退款規則
客服 SOP：
客戶表示未收到商品時的處理流程
異常處理：
超商物流狀態超過三天未更新該如何處理？
所以可以把兩者理解成：
FAQ 是知識庫的一部分。
而客服知識庫則是整套客服資訊的集合。
那什麼又是 AI 客服知識庫？
很多人聽到 AI 客服，會以為：
「把 ChatGPT 類型的 AI 接進客服系統，它應該就什麼都知道了。」
實際上並不是這樣。
AI 可能具備一般性的語言理解能力，但它不會天然知道：
你公司的退款規則是什麼、VIP 的處理標準是什麼、最新活動幾點開始、某個遊戲道具的補發條件，或者昨天才修改的公司政策。
這些資訊必須來自企業自己的資料來源。
因此所謂 AI 客服知識庫，可以理解成：
提供 AI 查找企業正確資訊的知識來源。
當客戶詢問：
「會員升級後原本的點數會消失嗎？」
AI 不應該自己猜答案。
比較合理的流程應該是：
客戶提出問題
→ AI 判斷問題內容
→ 從企業知識庫尋找相關資訊
→ 根據找到的內容整理答案
→ 回覆客戶
如果找不到可靠資訊，則應該：
轉交真人客服處理。
這也是 AI 客服與一般聊天機器人非常重要的差異。
AI 的語言能力負責「理解與回答」。
企業知識庫則負責提供答案依據。
AI 客服好不好用，關鍵往往不是 AI，而是知識庫
企業第一次導入 AI 客服時，很容易把注意力全部放在：
「這個 AI 用的是哪一個模型？」
但對實際客服場景而言，另一個更重要的問題是：
AI 到底能查到什麼資料？
如果知識庫裡的退款規則是兩年前的版本，AI 就可能提供過期資訊。
如果文件寫得模糊：
特殊情況可以另外處理。
AI 就很難知道什麼叫做「特殊情況」。
如果同一件事情存在兩份互相矛盾的文件：
文件 A：
退款申請期限為購買後 7 天內。
文件 B：
退款申請期限為購買後 14 天內。
那麼即使 AI 本身能力再強，也很難判斷哪一個才是目前有效的政策。
因此 AI 客服有一個很重要的原則：
回答品質的上限，很大程度取決於企業知識品質的上限。
現在的主流客服平台也愈來愈重視知識內容本身的品質、完整性與持續維護，而不是單純把 AI 接上既有 Help Center 就結束。
客服知識庫應該從哪裡開始建立？
很多企業第一次建立知識庫時，會犯一個錯誤：
先開一份文件，然後開始想：
「我們應該寫哪些 FAQ？」
其實更好的起點不是「想問題」。
而是：
直接看客戶已經問過什麼。
第一步：從既有客服工單找高頻問題
如果企業已經累積一段時間的客服紀錄，最有價值的知識來源往往就是既有 Ticket。
例如整理最近三個月客服案件後發現：
付款問題：326 件
帳號登入：218 件
修改會員資料：173 件
退款問題：125 件
活動資格：98 件
BUG 回報：74 件
這時候其實已經知道知識庫第一批應該建立什麼。
優先處理：
出現頻率高，而且答案相對固定的問題。
例如：
「如何修改密碼？」
「付款成功但沒有收到商品怎麼辦？」
「如何申請退款？」
「會員資料可以修改嗎？」
「發票在哪裡下載？」
這些都是非常適合作為第一批知識內容的題目。
Zendesk 目前的知識庫建置建議，也把分析既有 Ticket 資料與找出常見客戶問題列為建立 AI Help Center 內容的重要起點。
第二步：不要只按照公司部門分類
很多企業建立知識庫時，第一個想到的是按照組織架構分類：
客服部
財務部
技術部
營運部
行銷部
但問題是：
客戶不知道你的公司怎麼分部門。
客戶思考的是：
「我登入不了。」
「我沒有收到商品。」
「我要退款。」
「我的帳號被鎖住。」
所以客服知識庫更適合按照 使用者問題與產品情境 分類。
例如：
帳號與會員
- 註冊帳號
- 忘記密碼
- 修改 Email
- 帳號被鎖定
- 刪除帳號
付款與訂單
- 付款方式
- 付款失敗
- 重複扣款
- 訂單查詢
- 發票問題
退款與取消
- 退款資格
- 申請方式
- 處理時間
- 特殊退款情況
產品使用
- 功能教學
- 常見錯誤
- 裝置需求
- 操作問題
這樣不論是真人客服、客戶自己搜尋，還是 AI 尋找相關資訊，都更容易找到正確答案。
第三步：把「客服常用回覆」變成正式知識
客服團隊通常已經累積大量現成答案。
例如：
客服快捷回覆
Email 範本
客服群組置頂訊息
新人訓練文件
內部 Google Docs
FAQ 頁面
資深客服整理的筆記
這些其實都是建立知識庫非常好的原始素材。
但不建議直接全部丟進 AI。
因為其中很可能存在：
重複內容、過期資訊、不同版本、臨時處理方式，甚至彼此矛盾的答案。
正確方式應該是先整理：
哪一個才是公司的標準答案？
例如原本有三個客服版本：
A：
退款大約需要 3～5 天。
B：
通常一週內會退款。
C：
退款時間依銀行而定。
知識庫不應該同時留下三個模糊版本。
應該整理成正式規則，例如：
退款申請審核通過後，本公司會於 3 個工作天內完成退款程序；實際入帳時間依付款方式及金融機構作業時間而異。
這才是一份可以被長期使用的企業知識。
第四步：一篇知識只解決一個明確問題
在傳統內部文件裡，很常看到這種內容：
客服完整操作手冊 V7 最終版
裡面可能有 80 頁。
從登入後台、付款、退款、帳號、物流、VIP、活動、BUG 一路寫到底。
人類勉強可以 Ctrl+F。
但對客服人員快速搜尋與 AI 找答案而言，都不一定是最理想的結構。
更好的做法，是把內容拆成較明確的知識單位。
例如不要只有：
《付款相關問題》
而是拆成：
付款失敗怎麼處理？
客戶被重複扣款怎麼處理？
付款成功但商品未入帳怎麼處理？
信用卡授權失敗有哪些常見原因？
退款後多久會入帳？
每篇處理一個主要問題。
這樣搜尋結果更準確，AI 也比較容易取得真正需要的段落。
第五步：使用客戶真的會說的語言
公司內部可能把一個問題稱為：
Payment Transaction Exception
但客戶真正會問的是：
「刷卡成功但是沒收到東西。」
或者：
「錢扣了，商品沒進來。」
如果知識庫所有文章都只使用企業內部術語，搜尋與 AI 問答效果都可能受到影響。
因此標題與內容最好同時包含：
正式名稱＋客戶常用說法。
例如：
付款成功但商品未入帳怎麼辦？（付款異常處理）
比單純寫：
Payment Transaction Exception SOP
更適合作為客服知識。
Intercom 目前針對 AI Help Center 的內容建議，也特別強調文章名稱應使用客戶實際使用的詞彙，讓系統能更準確地將問題與知識內容匹配。
第六步：公開 FAQ 與內部知識要分開
不是所有客服知識都適合直接提供給客戶。
例如：
可以公開
如何修改密碼
配送需要多久
如何查詢訂單
退款申請方式
系統需求
功能操作方式
但另外一些內容可能只適合客服內部：
僅限內部
VIP 補償標準
特殊退款授權額度
風險帳號判斷方式
客訴升級流程
主管聯絡方式
內部系統操作
資安事件處理程序
因此一套完整的客服知識庫最好能區分：
公開知識
給客戶自行搜尋，也可以提供 AI 客服使用。
以及：
內部知識
讓真人客服或內部 AI 助理使用。
這個差異非常重要。
因為「AI 可以看到」不代表「客戶應該看到」。
現代客服知識管理平台也開始將公開 Help Center、內部文章與 AI 可使用的知識來源分開管理，讓不同角色使用不同範圍的資訊。
第七步：替重要知識設定負責人
知識庫最大的敵人通常不是「內容太少」。
而是：
內容過期。
例如：
去年退款期限是 14 天。
今年修改成 7 天。
產品團隊已經改規則了，但客服知識庫沒有人更新。
結果可能變成：
網站寫 7 天。
客服回答 14 天。
AI 又引用另一份舊文件說 30 天。
這時候知識庫反而成為問題來源。
所以重要內容最好至少具備：
負責人
誰負責確認這份資訊？
最後更新時間
這份資料多久沒有檢查？
版本
目前是哪個版本？
適用範圍
適用哪個產品、地區或客群？
有效狀態
使用中、草稿、即將失效或已停用？
Zendesk 對知識庫管理的建議，也明確提出應指定 Knowledge Base Owner，並建立內容審核與更新流程。
第八步：讓 AI 知道「不知道時不要亂回答」
AI 客服最危險的狀況，不是回答速度慢。
而是：
很有自信地回答錯誤資訊。
因此 AI 客服流程中一定要設計「不知道怎麼辦」。
例如：
找到可信知識：
→ 根據知識內容回答。
只有部分資訊：
→ 說明目前可以確認的部分，必要時請客戶補充資訊。
找不到答案：
→ 不自行猜測，轉交真人客服。
涉及高風險案件：
→ 直接交由人工判斷。
例如：
退款爭議
帳號盜用
付款異常
個人資料
法律問題
重大客訴
VIP 特殊案件
這些情況通常不應該單純追求 AI 自動結案率。
AI 的角色應該是：
能確定的事情快速回答，不能確定的事情快速交給正確的人。
第九步：知識庫不是建立一次就結束
真正有效的客服知識庫應該是一個持續循環。
流程可以是：
客戶提出問題
↓
產生客服工單
↓
發現新的高頻問題
↓
整理成知識
↓
FAQ／客服／AI 使用
↓
觀察哪些問題仍然無法解決
↓
再次更新知識庫
久而久之，客服工單不只是需要處理掉的工作。
它反而會變成：
企業建立知識庫最重要的資料來源。
這也是為什麼 Ticket System 與 Knowledge Base 放在一起時，會產生很大的價值。
怎麼知道知識庫有沒有做好？
不要只看：
「我們現在有 300 篇 FAQ。」
文章數量本身沒有太大意義。
更值得觀察的是：
客服最常遇到的問題，有多少已經有標準答案？
客服搜尋答案需要多久？
不同客服回答是否一致？
哪些問題 AI 經常找不到答案？
哪些文章經常被客服使用？
哪些內容很久沒有更新？
哪些問題明明已經有文章，客戶卻還是不斷詢問？
最後一種情況尤其值得注意。
因為它可能代表：
文章不好找。
標題不是客戶使用的詞。
內容太複雜。
操作流程本身有問題。
甚至根本不是客服問題，而是產品設計需要改善。
因此知識庫不只是客服工具。
它也可以反過來告訴企業：
客戶到底在哪些地方最容易卡住。
一個簡單的客服知識庫，可以長什麼樣？
假設今天建立一則：
付款成功但商品未入帳
適用範圍
商城付款成功，但商品超過 10 分鐘仍未出現在帳號內。
客戶可能會怎麼問
「錢扣了但東西沒有收到。」
「我刷卡成功了，商品在哪？」
「付款完成，但是道具沒進來。」
標準處理方式
- 確認客戶帳號。
- 確認訂單編號。
- 查詢付款狀態。
- 確認商品是否已發送。
- 如付款成功但發放失敗，依補發流程處理。
需要客戶提供
帳號 ID
訂單編號
付款時間
付款方式
無法解決時
轉交付款／營運相關人員處理。
最後更新
2026/08/20
負責人
客服營運團隊
這樣的內容不只能讓新人客服快速了解怎麼處理。
AI 也能從裡面知道：
客戶說「錢扣了但沒拿到東西」時，很可能是在詢問「付款成功但商品未入帳」。
這就開始從傳統 FAQ，進一步變成真正可用的 AI 客服知識。
FAQ、客服知識庫與 AI 知識庫，其實是一條成長路徑
企業不一定需要第一天就建立非常複雜的 AI 知識管理平台。
可以先從最簡單的開始。
第一階段：FAQ
把最常出現的 20～50 個問題整理成標準答案。
↓
第二階段：客服知識庫
加入操作教學、處理流程、內部 SOP、分類、權限與版本管理。
↓
第三階段：AI 客服知識庫
讓 AI 可以根據這些經過整理與確認的知識，協助搜尋、分類、產生回覆，並在必要時交由真人接手。
這種方式通常比：
「先導入 AI，之後再想 AI 要回答什麼。」
來得更合理。
K-CRM 如何把工單與客服知識串在一起？
K-CRM 本身將客服工單管理、AI 助理、FAQ 知識庫與案件追蹤整合在同一個客服流程中。
這樣做的一個重要原因，就是：
工單與知識本來就不應該是兩套彼此無關的資料。
當客戶問題進入客服系統後，案件可以被分類與追蹤。
如果問題屬於已知情況，客服可以從既有 FAQ 與知識庫找到標準資訊，降低每次重新整理回答的時間。
而當相同問題持續出現在客服工單裡，也代表：
知識庫可能需要新增或調整內容。
因此會形成：
工單產生問題資料
→ 問題整理成知識
→ 知識協助客服與 AI 回答
→ 新工單再反映知識缺口
的循環。
對企業而言，真正有價值的並不是單純累積「很多 FAQ」。
而是建立一套：
會隨著客戶問題持續成長的客服知識系統。
建立 AI 客服之前，先整理公司的知識
AI 可以讓客服回答得更快。
但 AI 不會自動替企業建立正確的退款規則、付款流程、產品政策或客服 SOP。
這些仍然是企業自己的知識。
因此導入 AI 客服之前，非常值得先問幾個問題：
公司最常被問的問題是什麼？
這些問題有沒有正式答案？
不同客服回答是否一致？
哪些資訊可以公開？
哪些內容只能給內部人員使用？
規則修改後，有沒有人負責更新知識？
AI 找不到答案時，應該交給誰？
當這些問題開始有明確答案之後，AI 才真正有機會成為客服團隊的助手。
因為一套好的 AI 客服系統，核心並不是：
讓 AI 什麼都回答。
而是：
讓正確的知識，在客戶需要的時候，被快速找到並正確使用。