「電商客服」很常出現「新客服最常問的問題，老客服早就回答過幾百次」的狀況。
- 「這個客人這樣要求可以嗎？」
- 「這種情況退貨要怎麼處理？」
- 「這個商品之前有人反映過嗎？」
- 「這種尺寸問題以前你們都怎麼回？」
對資深客服來說，這些問題可能早就熟到不用思考，但對剛進公司的新人來說，每一個都是第一次遇到，於是店裡很容易形成一個循環：「新人不知道，就去問資深客服」，「資深客服不確定，就去翻以前的聊天紀錄」，「聊天紀錄找不到，就再去問店長」，最後，真正有價值的客服經驗，往往沒有留在公司的資料裡，而是留在某幾個人的腦袋裡。
這其實是很多電商客服「很難標準化」的原因。
商品規格可以整理成文件，退換貨規則可以寫成 SOP，常見問題也可以做成 FAQ，但還有一種資訊更難整理，就是「以前遇到這種狀況，我們是怎麼判斷的？」
因為客服每天累積的不只是問答，而是大量的情境判斷：「什麼情況可以彈性處理？」、「什麼情況一定要照規則？」、「客人反映某個商品問題時，過去曾經怎麼處理？」、「遇到特殊要求時，店裡通常會採取什麼做法？」，這些經驗如果沒有被留下來，資深客服離職、新人接手，甚至只是原本負責的人休假，都可能讓同一個問題重新問一次。
而 NotebookLM 可以成為處理這類問題的一個工具，可以把過去整理好的客服紀錄、商品資料、退換貨規則、FAQ、內部說明等資料集中起來，讓 AI 協助整理與查找，它的價值不只是「幫客服回答問題」，而是把原本分散在不同文件、聊天紀錄與人員經驗裡的資訊，逐漸整理成一套可以查詢、可以交接，也能持續補充的客服工作知識庫。
這樣一來，新人遇到問題時，不一定每次都要先問資深客服，而資深客服最有價值的經驗，也不會隨著一句「我記得以前好像是這樣」就消失。
⚿ 文章目錄 ⚿
▍二、把客服資料分成「規則、案例、回答」，NotebookLM 才真正派得上用場
▍三、NotebookLM 最適合做的，不是「自動回客人」，而是幫客服快速找到依據
▍五、一個簡單測試，就能知道你的客服知識庫有沒有真的建立起來
一、真正難交接的不是客服話術，而是「判斷過程」
很多店家在做客服 SOP 的時候，第一個想到的通常是要把「標準答案整理出來」。
例如：
客人問：「可以退貨嗎？」
標準回答：「您好，本商品提供七日鑑賞期……」
這種整理方式當然是有用的，對於配送方式、付款方式、商品規格這類有明確答案的問題，直接提供標準回覆，可以讓新人少花很多時間摸索。
但客服真正難處理的，往往不是「答案是什麼」，而是：這個案例到底適不適用這個答案？
1. 同一句問題，情境不同，答案可能完全不同
例如客人說：
「我收到商品後發現不喜歡，可以退嗎？」
如果只給新人一段「退貨話術」，事情其實還沒解決，因為客服還需要進一步確認：
- 商品是否符合退貨條件？
- 是否已經使用？
- 包裝是否完整？
- 是否屬於特殊商品？
- 是否已經超過退貨期限？
- 是否有其他例外規定？
會因為這些條件的不同，影響最後的處理方式，所以客服真正需要掌握的，不只是「這句話要怎麼回？」而是「遇到這種情況，我要先確認什麼？」這兩件事情看起來很接近，但實際上差很多，前者是在背答案、發罐頭訊息的感覺，後者才是在學習如何判斷，而客服工作之所以難交接，往往就是因為後者沒有被留下來。
資深客服可能早就知道，看到某種描述就要先檢查哪個條件；知道哪些情況可以直接處理，哪些情況需要詢問主管；也知道某些商品雖然看起來符合一般規則，實際上還有額外限制，但這些經驗如果沒有被整理，新人就只能透過一次次「問前輩」慢慢學，久了之後，公司不是沒有 SOP，而是真正重要的 SOP 藏在資深客服的經驗裡。
2. 把「案例」留下，比要求員工背答案更實際
客服知識整理可以換一個方向：不要只整理標準答案，也把過去怎麼判斷的案例留下來。
例如過去曾經遇到：
客人拆封後發現尺寸不合，但商品沒有使用痕跡。
與其只留下最後回覆給客人的那段話，不如把整個處理脈絡一起記錄：案例背景 → 判斷條件 → 處理方式 → 最終回覆，這樣下一次新人遇到類似的問題，看到的就不會只是「上次客服怎麼回」，而是還能理解：
- 當時遇到了什麼情況
- 客服確認了哪些條件
- 為什麼最後採取這個處理方式
- 對客人最後是怎麼說明的
這會比單純複製一段舊話術更有價值，因為客服面對的問題，很少會每次都長得一模一樣，所以真正能幫助新人的，不是告訴他「這題的答案」，而是讓他看懂「以前遇到類似問題時，店裡怎麼判斷」，當這些案例累積起來，客服知識就不再只是一本 FAQ，而會逐漸變成一套可以參考的決策脈絡。
而這也是 NotebookLM 比較適合切入的地方，它不只是拿來整理「常見問答」，而是可以把原本分散的文件與案例放在一起，讓客服在遇到新問題時，先找到過去有哪些相似情況，以及當時是怎麼處理的。
二、把客服資料分成「規則、案例、回答」，NotebookLM 才真正派得上用場
如果把所有客服聊天紀錄、商品資料、內部規定全部丟進 NotebookLM，表面上看起來資料很完整，實際要使用的時候，不一定會好找，因為客服真正需要的，通常不是「更多資料」，而是：我現在遇到這個問題，應該先看什麼？
比起把資料全部混在一起，更實際的做法，是先把客服知識拆成三個層次：規則 → 案例 → 回覆，三者各自負責不同的事情。
第一層：規則「店裡到底怎麼處理」
第一層是最基礎的規則資料。
例如：
- 退換貨規則
- 出貨規則
- 運費規則
- 優惠券使用規則
- 會員規則
- 訂單修改規則
- 特殊商品注意事項
這些內容通常是客服最不能自行猜測的。例如「這筆訂單能不能修改」、「這個商品能不能退」、「滿額優惠是否可以併用」，如果公司已經有明確規定，就應該以正式規則為準，而不是參考某位客服「以前好像有這樣處理過」。
所以，「規則文件」應該是客服知識庫裡的最高優先級依據，案例可以拿來參考，但不能因為「上次這樣處理」，就直接取代現在的正式規則。
第二層：案例「以前真的遇過什麼」
第二層是實際案例。
規則可以告訴客服「原則上怎麼處理」，但現實中的客人往往不會乖乖照規則題目出現。
例如：「客人已收到商品，但表示尺寸不合，商品有試穿痕跡，之前是怎麼處理？」
這時候光看「退換貨規則」可能還不夠，如果公司過去曾經遇過相似情況，就可以把當時的處理方式拿來參考，像是：當時客服確認了哪些條件、最後怎麼判斷、是否需要主管確認，以及最後如何處理。
案例的價值就在魚「它提供的是規則之外的情境脈絡」，而且案例不一定要把整段聊天紀錄原封不動留下來，更實用的方式，是整理成：案例情境 → 關鍵條件 → 判斷結果 → 處理方式，這樣未來遇到相似問題時，比直接翻幾百則聊天紀錄有效率得多。
第三層：回覆「最後怎麼跟客人說」
第三層才是實際對客人的回覆。
這一層很重要，因為「知道怎麼處理」和「知道怎麼說明」其實是兩回事。
例如公司內部可能需要確認：
- 商品是否符合退貨條件
- 是否有使用痕跡
- 是否需要人工審核
- 是否需要主管確認
但這些內部判斷，不代表全部都要原封不動告訴客人。
所以，可以把「內部判斷」和「對外說法」分開保存，這樣客服在使用 AI 協助整理回覆時，就能先根據規則與案例確認「應該怎麼處理」，再把結果轉換成適合客人閱讀的說法。
例如內部可能是：
「商品已有試穿痕跡，需依退貨規範確認是否符合退貨條件。」
對客人的說法則可以是：
「您好，因商品已有試穿痕跡，退貨是否符合相關條件還需要進一步確認，麻煩您提供商品目前的狀況，我們再協助您確認。」
兩者處理的是同一件事情，但用途完全不同。
所以這三層資料可以簡單理解成：
- 規則，決定能不能這樣處理。
- 案例，幫助理解以前遇到類似情況怎麼處理。
- 回覆，負責把判斷結果轉換成客人聽得懂的話。
當這三種資訊被整理好，NotebookLM 的角色就不只是「幫你找文件」，而是協助客服更快找到與眼前問題有關的依據與案例，這才是客服知識庫真正有用的地方。
三、NotebookLM 最適合做的，不是「自動回客人」，而是幫客服快速找到依據
這也是這套方法和一般 AI 客服最大的差別。
以 QDM 現有的 LINE Bot 來說，主要是讓顧客可以自行查詢訂單、會員資訊、常見服務等，核心目的在於「縮短等待，提升服務效率」，這跟 NotebookLM 的使用情境則不太一樣。
NotebookLM 不是直接站在顧客面前回答問題，而是站在客服身邊，比較像是：客服坐在電腦前遇到問題時，旁邊多了一個可以查資料、找案例的「店舖知識助理」。
這個差異很重要，因為客服真正需要的，很多時候不是 AI 幫他「決定答案」，而是幫他在大量資料裡，快速找到可以支持判斷的依據。
｜先讓它找依據，再要求它整理答案
例如客服收到客人的訊息：「客人說商品有瑕疵，但已經使用過了，這種可以怎麼處理？」
與其直接問 AI：「幫我回覆客人。」
更適合先問 AI：「請根據目前提供的退換貨規則與過往案例，找出與這個情境最接近的資料。先列出判斷依據，不要直接產生客服回覆。」
這一步其實很重要，因為客服可以先確認「AI 找到的資料是不是對的」，例如它找到的案例是否真的相似？引用的規則是不是目前有效的版本？有沒有漏掉某個限制條件？
確認依據沒有問題之後，再進入下一步：「根據上述判斷，整理成一段可以提供給客人的客服回覆，語氣親切、清楚，不要自行增加資料中沒有的承諾」，這時候 AI 做的事情就比較單純，會把已經確認過的資訊，整理成比較好讀的文字，整個流程就會變成：找資料 → 找案例 → 確認依據 → 輔助判斷 → 產生回覆草稿 → 人工確認，而不是：客人一問 → AI 自己決定答案 → 直接送出去。
兩種方式看起來都用了 AI，但風險其實差很多，尤其是退換貨、退款、客訴、補償等涉及公司規則或例外處理的問題，AI 能不能找到資料是一回事，最後能不能這樣處理又是另一回事。
所以 NotebookLM 在客服流程裡比較適合扮演的角色，不是「自動客服」，而是：幫客服縮短找資料的時間，把原本需要翻聊天紀錄、找 SOP、問資深同事的工作，變成可以先查詢知識庫，再由人做最後判斷。
這樣 AI 才是在幫客服累積經驗，而不是讓客服把判斷權直接交出去。
四、最值得建立的，其實是「客服查詢習慣」
知識庫最怕的不是資料不夠，而是：大家根本沒有查的習慣。
就算整理了再完整的規則、案例與客服紀錄，如果新人遇到問題還是直接問旁邊的資深客服，久了之後，知識仍然只會停留在少數人的腦袋裡，所以導入 NotebookLM 後，不用要求客服「什麼問題都問 AI」，更實際的做法，是先建立幾個簡單的查詢習慣：
- 不確定 → 先查。
- 查不到 → 再問人。
- 問完 → 把新案例留下來。
這三個動作持續做下去，知識庫才會越來越有價值。
1. 新人遇到「不確定」的問題，先查再問
例如新人遇到：「我不確定這個退貨案例以前怎麼處理。」
以前的做法可能是直接問資深客服，但有建立知識庫之後，就可以先查詢，如果找得到相似案例，就先依照規則與案例理解處理方式，如果資料裡找不到，再詢問資深客服或主管。
這個順序看起來只差了一個步驟，長期下來卻會產生很大的差別，因為資深客服不需要一直回答：「這個以前有沒有遇過？」、「上次同樣事件是怎麼處理？」、「這個商品到底能不能退貨？」等相關問題，而新人也不會永遠停留在「有問題就問某個人」的階段。
要留意的是：每一次「查不到」，其實都是知識庫的一個缺口：
- 如果同一類問題一直被問，就代表這個情境值得補進資料庫中。
- 如果新人經常找不到某項規則，也可能代表原本的文件不夠清楚。
- 如果同一個案例被反覆詢問，則可以考慮把它整理成正式案例。
客服平常的查詢行為，本身就能反過來告訴店家：哪些知識最值得補。
2. 遇到特殊案例，就把答案留下來
假設今天客服遇到一個過去從沒發生過的特殊狀況，客服確認規則、詢問主管並完成處理後，不要讓這次經驗就這樣結束，就可以順手整理成一筆案例：
案例名稱：已使用商品的瑕疵反映
情況： 客人收到商品後表示有瑕疵，但商品已有使用痕跡。
判斷依據： 依照目前退換貨規則，確認商品狀況及相關條件。
最後處理： ……
對外回覆： ……
不需要寫成一篇很長的報告，重點是把當時為什麼這樣判斷，以及最後怎麼處理留下來，下一次遇到相似問題時，客服就不必再從零開始討論，而且這筆資料未來不只服務新人，它也可能成為資深客服、主管，甚至未來新進員工的參考依據。
3. 讓知識庫形成「越用越完整」的循環
真正好用的客服知識庫，不是一次整理完就結束，它比較像是一個持續累積的循環：遇到問題 → 查詢資料 → 找不到就詢問 → 完成判斷 → 留下案例 → 下一次再查。
一開始，知識庫可能只有基本規則與幾個常見案例，但使用一段時間後，會慢慢累積出更多真實情境，新人遇到問題，可以先查，資深客服不用一直重複回答，主管也能看到哪些問題經常出現，甚至當某個規則需要修改時，也可以回頭檢查過去的相關案例，避免新舊處理方式混在一起。
這才是建立客服知識庫真正的目的。
不是讓公司多了一個 AI 工具，而是讓「問過一次的問題」，有機會變成「下一次查得到的答案」。
當客服團隊開始有了查詢的習慣，NotebookLM 才不會只是放資料的地方，而是會逐漸變成團隊日常工作的一部分。
五、一個簡單測試，就能知道你的客服知識庫有沒有真的建立起來
不用一開始就整理幾千則客服紀錄，因為如果一開始就想把所有資料全部整理完，很容易做到最後，只剩：整理資料本身。
更實際的方法是先挑一個範圍做小型測試，先確認這套方法真的能解決問題，再慢慢擴大。
1. 先挑「新人最常問資深客服」的問題
可以從一個新人經常需要請教資深客服的「主題開始」。例如：退換貨判斷，它通常會比「商品尺寸怎麼選」更適合拿來當第一個測試範圍，因為尺寸問題可能只需要查商品規格，但退換貨判斷通常同時涉及：規則、案例、判斷條件與客服回覆。
準備三種資料：
- 目前正式的退換貨規則
- 過去幾個實際處理案例
- 對應的客服回覆
接著，不要拿已經看過的舊問題來測試，可以另外準備 5～10 個新的情境，模擬新人實際可能遇到的問題，再看看 NotebookLM 能不能：
- 找到正確的規則
- 找到與情境相近的案例
- 分辨不同條件下的處理方式
- 不自行補充資料裡不存在的規定
- 整理出客服可以理解的判斷依據
如果這些基本測試都能穩定完成，再逐步增加其他範圍，例如訂單修改、物流問題、優惠活動、會員問題或特殊商品。
這比一次把所有客服資料全部整理進去，更容易知道到底是哪一部分真的有效。
2. 最後看的是「新人能不能少問一次」
這套方法最實際的驗證方式，其實不是要看 AI 寫得漂不漂亮，也不是要看它回答得有多像真人，而是在看一個實際的改變：新人以前一天要問資深客服 10 次，現在能不能自己解決其中 3～5 次？
如果可以，就代表知識庫真的開始發揮作用，因為它降低的不是單純的打字時間，而是降低了「每遇到一個問題，就重新找人教一次」的成本。
而且這個成果還會持續累積，今天新人因為知識庫少問了一次，明天這個問題又被整理成新的案例，下一個新人就可能連問都不用問，最後真正被留下來的，就不只是幾份文件，而是一套團隊可以反覆使用的工作經驗。
讓已經發生過的事情，不需要每次重新教一次，這才是客服知識庫真正值得建立的原因。
結語｜別讓客服經驗只存在某一個人的腦袋裡
電商做久了，店裡一定會累積大量只有資深客服才知道的「眉角」，像是哪種情況要特別注意、哪個問題以前發生過、哪條規則有例外、遇到敏感問題時怎麼說比較合適，這些經驗很有價值，卻也很容易隨著人員異動一起消失。
所以客服知識管理真正要解決的，並不是：「我要怎麼讓 AI 幫我回覆更多客人？」而是：「一個資深客服累積三年的經驗，能不能留下來，讓下一個人繼續使用？」
NotebookLM 可以是其中一個工具。
但真正重要的，從來不是用了哪一個 AI，而是有沒有把原本分散在聊天紀錄、文件與員工記憶裡的經驗，整理成公司可以持續使用的知識，當新人遇到問題，可以先查，當資深客服處理完特殊案例，可以留下，當店長發現規則需要調整，可以更新，後續當同樣的問題再次出現，就不必從頭開始問，久而久之，店裡累積的就不只是「會回答問題的人」，而是一套可以查詢、交接、更新，也能持續累積的客服工作知識。
這才是把零碎客服問答變成「客服救星」真正有價值的地方。
因為好的客服知識庫，不是讓 AI 取代客服，而是讓一個人累積的經驗，不必只服務他自己。
好商品，值得被更多人看見。
從開店開始，把商品、顧客與生意真正連結起來。👉 [立即免費開店]