客服工單系統怎麼做？分派規則、SLA 計時、知識庫與客戶自助的完整規劃（含五種方案成本對照與 90 天路線圖）

去年底接了一個工業設備代理商的案子，公司 28 人、專職客服 2 位。他們的 service@ 信箱每月進 640 封信，其中約 70 封（11%）超過 72 小時沒有任何回覆。原因是兩人共用一個信箱：A 以為 B 回了，B 以為 A 回了。真正付出代價的是保固爭議——客戶說「我三月就報修過」，公司翻不出紀錄，吞下一台 NT$48,000 的更換成本。這不是態度問題，是沒有系統記得誰該回、什麼時候該回、上次講到哪裡。

適用情境 × 不適用情境

適合導入工單系統的情境

• 每月詢問量超過 150 件，來源不只一個（信箱、LINE、電話、官網表單）。
• 客服超過 2 人，或會輪班、會離職、會請假。
• 問題需要跨部門轉手（業務接單、技術判斷、倉庫出貨）。
• 服務有承諾時效——保固、SLA 合約、政府標案、B2B 年約。
• 同一個問題重複出現，值得寫成文章讓客戶自己查。

不適合的情境

• 每月不到 50 件詢問、只有一位負責人——共用信箱加標籤就夠，導入只增加操作成本。
• 幾乎全靠電話成交、客戶不使用文字管道（部分傳統批發、工地類）。
• 沒有人願意負責「規則怎麼訂」——工單系統會放大流程問題，不會修好它。
• 只想找「AI 自動回覆全部問題」的方案——沒有整理過的知識庫，AI 只會更快地講錯話。
• 三個月內要換 ERP／CRM 主系統——先等主系統定案，客戶資料來源會整個變。

替代方案矩陣

判斷法則：工單流程跟同業長得一樣就買 SaaS；流程本身是競爭力（保固判定、料件庫存、經銷層級）才值得客製。設備商選客製，是因為每張單都要即時查序號、保固到期日與庫存，SaaS 要做到得再串三支 API，維護成本反而更高。

完整流程拆解（10–12 週）

• 第 1 週｜盤點與分類。調三個月信件做分類統計，找出前 10 大問題類型。交付：工單類型表、優先級矩陣（影響範圍 × 急迫性）、SLA 級距表（Notion）。
• 第 2 週｜分派與升級規則。定義誰接什麼、多久沒動作要升級給誰、營業日曆怎麼算。交付：路由規則表、escalation 樹、工作行事曆。
• 第 3–4 週｜介面設計。Figma 產出客服工作台與自助查詢頁高保真稿，跑一輪真人試操作。交付：可點擊原型、欄位規格書。
• 第 5–8 週｜系統建置。Laravel 建工單核心、權限與稽核紀錄；Laravel Queue 搭 Redis 處理收信解析、SLA 到期掃描與通知排程；郵件走 Amazon SES 或 Postmark；入口串官網表單與 LINE 官方帳號。交付：測試環境、API 文件。
• 第 9 週｜知識庫與自助。寫 20 篇最高頻問題文章，嵌進建單流程——客戶打字時就先跳建議文章。交付：知識庫 20 篇、自助查詢頁。
• 第 10–12 週｜雙軌試營運與上線。舊信箱與新系統並行 2 週，客服訓練 8–12 小時，UptimeRobot 監控收信管線，Metabase 建報表。交付：驗收清單、維運手冊、儀表板。

真實成本完整拆解

• 規劃與設計：NT$45,000–70,000（約 60–90 工時，含分類盤點與 Figma）。
• 系統開發：NT$180,000–320,000（工單核心、路由、SLA 計時、知識庫、報表）。
• 歷史資料匯入：NT$20,000–50,000（三年信件轉工單、客戶對應）。最常被漏估。
• 知識庫內容：20 篇 × 1.5 小時 = 30 工時，外包約 NT$30,000。

隱藏費用清單：

• 交易型郵件（Amazon SES／Postmark）：月 NT$300–2,500，依寄送量。
• 簡訊通知：每則約 NT$0.8–1.2，逾時升級提醒最容易失控。
• 主機與 Redis：月 NT$1,500–4,500。
• 網域與憑證：Cloudflare 免費方案可覆蓋，自購憑證年 NT$0–3,000。
• 維運與規則微調：月 NT$8,000 起，第一年幾乎必花。
• 客服學習曲線：頭兩個月每人每週約多 2 小時。

ScriptWalker 的客服工單與 SLA 管理系統建置方案起價 NT$260,000，含工單核心、分派規則、SLA 計時與逾時升級、知識庫與客戶自助查詢，標準交付 10–12 週。

實施真相 vs 客戶想像

• 想像：上線就能少請一個客服。實際：前 6 週客服工時反而增加 15–20%，因為要補分類、補歷史；人力效益通常第 3 個月才轉正。
• 想像：自動分派規則越聰明越好。實際：規則超過 8 條，沒有人說得出「為什麼這張單在我這裡」，現場開始手動改派，規則等於失效。
• 想像：知識庫寫完客戶就會自己查。實際：不嵌在建單流程裡，自助率卡在 3% 上下；嵌進去之後我們看過的區間是 12–18%。
• 想像：SLA 設「24 小時內回覆」就好。實際：沒定義營業日曆，週五下午 5 點進來的單，週一開機就已逾時，報表整片紅。

常見陷阱 × 怎麼避開

• 陷阱：用個人信箱轉寄當入口，寄件者變成同事、回信收不到。解法：設專屬收信網域 support@ 走 IMAP／SES 直收，並解析 Message-ID 串同一討論串。
• 陷阱：優先級讓客戶自填，全部都是「非常緊急」。解法：改由「影響範圍 × 急迫性」矩陣自動判定，客戶只描述現象。
• 陷阱：沒有「等待客戶回覆」狀態，等客戶的時間全算在自己頭上。解法：做 SLA 計時器暫停機制，並設 7 天無回應自動結案。
• 陷阱：第一版就上 20 個必填欄位，每張單多花 3 分鐘。解法：MVP 只留 6 個必填，其餘選填或自動帶入。
• 陷阱：同一個客戶重複來信開出五張單，統計全歪。解法：依 Email + 主旨相似度自動關聯，提供一鍵合併與拆分。
• 陷阱：資料出不來，要什麼數字都得請工程師寫 SQL。解法：第一天就接 Metabase，並保留全欄位 CSV 匯出。

成功指標 + 上線後 90 天路線圖

• 第 30 天：入口收斂率 ≥ 90%（九成詢問從系統進來，不走私人信箱）；量出首次回應中位數與逾時率的基準線。這 30 天只量測，不優化。
• 第 60 天：首次回應中位數 < 4 個工作小時、SLA 逾時率 < 5%；知識庫 20 篇上線並開自助查詢；每週看轉派次數，超過 2 次的類型代表規則要改。
• 第 90 天：一次解決率 ≥ 65%、重開率 < 8%、自助解決率 12–18%、單張平均處理時間較基準下降 20%、CSAT ≥ 4.3／5。此時再談 AI 建議回覆——有乾淨的歷史工單，AI 才有東西可學。

決策清單

• ☐ 每月客服件數是否超過 150 件？
• ☐ 詢問來源是否超過兩個管道？
• ☐ 是否曾因找不到紀錄而吃過賠償或客訴？
• ☐ 客服是否超過 2 人或需要輪班？
• ☐ 是否有對外承諾的回覆或處理時效？
• ☐ 前 10 大問題類型你現在說得出來嗎？
• ☐ 公司內部是否有人能拍板「規則怎麼訂」？
• ☐ 工單是否需要跨部門轉手？
• ☐ 是否需要即時查詢保固、序號或庫存等自家資料？
• ☐ 是否願意在上線前投入 30 工時寫知識庫？
• ☐ 三個月內是否會更換 ERP／CRM 主系統？（若是，先緩）
• ☐ 首年是否編得出 NT$60,000 以上的維運預算？
• ☐ 是否能接受前 6 週工時不減反增？

勾到 8 項以上值得做；勾不到 5 項，先把共用信箱的分工規則寫清楚就好。

常見問題 FAQ

可以先用 SaaS，之後再轉客製嗎？

可以，而且常是最省的路。先用 Zendesk 或 Freshdesk 跑 3–6 個月，把工單分類、SLA 級距與分派規則跑穩，這些資產轉客製時全部沿用得到。轉移要注意歷史工單的匯出格式與附件，多數 SaaS 提供 API 匯出，預留 NT$20,000–50,000 搬遷工時。

可以把 LINE 官方帳號的訊息也收進工單嗎？

可以，用 Messaging API 的 webhook 把訊息轉成工單即可。但要先處理兩件事：LINE 使用者期待的回覆速度比 Email 快得多，SLA 要另設一條；同一個人可能同時用 Email 和 LINE 問同一件事，客戶識別要靠手機或會員 ID，不能只靠管道帳號。

AI 自動回覆值得做嗎？

值得，但順序不能顛倒。先累積 3 個月乾淨工單與 20 篇知識庫，再上 AI 建議回覆（由客服按送出，不直接對外），命中率才有意義。第一天就開全自動回覆，最常見的結果是客戶被錯誤答案激怒後轉打電話，總成本反而上升。

兩個人的小團隊也需要工單系統嗎？

如果月件數不到 50 件，不需要。共用信箱加上「誰處理就標自己的標籤」＋每天早上 5 分鐘對帳，就能解決九成問題。工單系統真正開始划算的門檻，通常在月 150 件或客服第 3 人到職的時候。

下一步

我們提供 60 分鐘免費客服流程健檢：帶近三個月的客服信件量、目前的分工方式與最常吵的三種客訴類型，現場幫你畫出工單分類表與 SLA 級距草案，並算出「SaaS vs 客製」三年總持有成本對照。結果就算不合作也可以直接拿去用。

• Email：[email protected]
• 電話：0916-224-047
• LINE：@ufv9089p