客服工單系統開發指南：工單生命週期、多管道進件、SLA 指派與套裝客製取捨

客服主管最怕的一句話，是客人打電話來說「我上禮拜就問過了，到現在都沒人理我」。翻遍 LINE 官方帳號、公司信箱、表單後台和同事的私人群組，才發現那則訊息被看過、被轉傳過，卻沒有人覺得是自己的事。這種狀況正是客服工單系統要解決的核心問題：讓每一個客人的問題都有編號、有負責人、有狀態，而且不會因為換人、休假或訊息被洗掉而消失。

工單系統聽起來像是大公司才需要的東西，但實務上許多十幾人的團隊就已經被客服訊息淹沒。問題往往不是客服不夠努力，而是資訊分散在太多地方，沒有一個地方能回答「現在還有哪些問題沒處理完」。

以下從工單的生命週期講起，接著說明多管道進件怎麼收斂、指派規則與 SLA 怎麼設計、知識庫怎麼跟工單接在一起，最後談套裝工具與客製開發怎麼選，以及開發前要準備哪些東西。

工單系統到底在管什麼

先把概念講清楚：工單（ticket）是「一個需要被處理的問題」的紀錄，而不是一則訊息。同一個問題可能來回十幾則訊息，但它只是一張工單；反過來，客人在一則訊息裡同時問了退貨和發票，那可能應該拆成兩張工單，交給不同的人處理。

一張工單至少要回答這幾件事：

• 誰提出的：客人身分、聯絡方式、過去的往來紀錄。
• 問的是什麼：問題類別、相關的訂單或產品、附件。
• 現在誰負責：指派給哪位客服或哪個部門。
• 處理到哪裡：目前狀態，以及下一步在等誰。
• 多急：優先級，以及依約定應該在什麼時間前回覆或解決。
• 怎麼結束的：最後的解法是什麼，客人是否確認解決。

只要這幾個欄位都有，客服主管就能從清單一眼看出哪些件快逾時、誰手上壓了太多件、哪類問題最近突然變多。這是聊天紀錄與信箱做不到的事，因為它們只記錄「說了什麼」，不記錄「事情處理到哪」。

工單生命週期：狀態怎麼設計

工單系統最重要的設計，是狀態要怎麼流轉。狀態設計得好，客服不用多想就知道下一步；設計得差，工單會卡在某個沒人看的狀態裡。

一套常見的基本狀態如下：

1. 新建：剛進件，還沒有人看過或分派。
2. 已指派：已經有負責人，但還沒開始處理。
3. 處理中：負責人正在查資料、聯絡其他部門或撰寫回覆。
4. 等待客戶回覆：已經回覆客人並提出問題，球在客人手上。
5. 等待內部處理：需要倉庫、工程、財務等其他部門協助，球在內部。
6. 已解決：客服認為問題已處理完畢，等待客人確認或一段觀察期。
7. 已結案：確認結束，不再計入待處理清單。

設計狀態時有幾個容易踩的坑：

「等待中」一定要分清楚在等誰。等客人和等內部是兩回事：等客人時，SLA 計時通常應該暫停，否則客服會因為客人不回覆而被記逾時；等內部時，計時則應該繼續跑，因為延誤責任在公司。把兩者混成一個「等待中」，報表就會失真。

已解決與已結案要分開。客服按下「已解決」後，如果客人又回信說問題還在，工單應該自動回到處理中，而不是開一張新單。保留一段觀察期，過了期限沒有新訊息才自動結案，可以避免同一個問題被拆成好幾張單、讓統計看起來比實際更好。

狀態不要太多。每多一個狀態，就多一個工單可能被遺忘的角落。如果某個狀態一個月只用到幾次，通常可以改用標籤處理，而不是新增狀態。

重新開啟要留痕跡。工單被重開的次數，是判斷結案品質最直接的線索，系統應該記錄每次重開的時間與原因。

多管道進件：把 LINE、Email、表單收進同一個地方

台灣企業的客服訊息來源通常很雜：LINE 官方帳號、公司 Email、官網聯絡表單、電商平台的訊息、電話、社群私訊，甚至業務的個人 LINE。工單系統的第一個價值，就是讓所有管道的訊息進到同一個收件匣，客服不必開五個視窗輪流檢查。

各管道的串接方式與注意事項不太一樣：

Email：最容易接，系統收信後依寄件人與信件主旨的工單編號判斷是新問題還是既有工單的回覆。要注意的是轉寄信件、同一封信副本給多人、以及自動回覆信造成的無限迴圈，這些都需要過濾規則。

LINE 官方帳號：透過官方提供的訊息介面串接，客人傳來的訊息會進入工單，客服在工單系統裡回覆、再由系統送回 LINE。要特別設計的是「同一位客人連續傳的訊息要不要併入同一張工單」：通常以一段時間內的訊息視為同一個問題，超過時間或前一張已結案就開新單。LINE 端的對話設計與自動回覆，可以參考 LINE 聊天機器人開發指南。

官網表單：表單的好處是可以要求客人一開始就選問題類別、填訂單編號、上傳照片，進件資料最完整。表單欄位設計得好，可以省掉大量來回追問。

電話：電話本身無法自動成單，但可以讓客服在通話時快速建立工單，或串接電話系統的來電紀錄，至少確保「有人打來過」這件事被記下來。

跨管道辨識同一位客人

多管道最難的不是接進來，而是認出這是同一個人。同一位客人可能先用 LINE 問、再寫 Email 補資料、最後打電話催。如果系統認不出來，客服就看不到完整脈絡。

常見做法是建立一份客戶主檔，用 Email、手機號碼、會員編號、LINE 綁定帳號等識別資訊互相對應。已經有會員系統的公司，最好直接跟會員資料串接，而不是在工單系統裡另建一份會互相打架的客戶清單。會員資料怎麼規劃，可參考會員系統與 CRM 開發指南。

指派規則與 SLA：讓每件事都有人負責、有期限

工單進來之後，下一個問題是交給誰。指派方式大致有幾種：

• 手動指派：由主管或值班人員分派，適合件數不多、需要判斷的團隊。
• 輪流指派：依序平均分給線上客服，簡單公平，但不考慮專長。
• 依類別指派：退貨進退貨組、帳務進財務窗口、技術問題進技術支援。
• 依負載指派：優先分給手上待處理件數最少的人。
• 認領制：工單放在共同佇列，由客服自行認領，適合專業度高、需要挑件的團隊。

實務上常見的是混合：先依類別分到小組，小組內再依負載或輪流分派，並保留主管手動調整的權限。另外要設計沒人在線時怎麼辦：下班時間進來的工單是否先發自動確認訊息、隔天早上由誰接手。

SLA 要怎麼訂才實際

SLA（服務水準約定）在客服系統裡通常指兩個時間：首次回覆時間與解決時間。前者是客人多久能收到真人回應，後者是問題多久能真正處理完。

訂 SLA 時有幾個原則：

• 依優先級分層：付款失敗、無法登入這類影響使用的問題，應該比一般詢問更快處理，不要所有工單同一個期限。
• 算營業時間還是日曆時間要講清楚：週五晚上進來的工單，期限是從週一早上開始算，還是週末也算？這會直接影響逾時判斷，也牽涉到國定假日的設定。
• SLA 是內部管理工具，不一定要對外承諾。先內部跑一段時間，確定做得到再考慮公開。
• 快逾時要提醒，不是逾時才提醒。在期限前預留一段時間通知負責人，逾時後再通知主管，才有機會補救。

最常見的錯誤，是把 SLA 設得太漂亮、做不到，結果客服為了不逾時而草率回覆一句「我們幫您確認」就把工單轉成等待中。SLA 的目的是讓問題被重視，不是讓數字好看。

知識庫：讓答案不再只存在資深客服的腦袋裡

客服團隊裡通常有一兩位資深同仁，什麼問題都能答，他一休假，整個團隊就卡住。知識庫的用途，就是把這些答案寫下來，讓新人也能查得到。

知識庫跟工單系統接在一起時，可以發揮三種作用：

1. 對內查詢：客服處理工單時，系統依問題類別或關鍵字推薦相關文章，直接引用或貼上連結。
2. 對外自助：把適合公開的文章放到官網的說明中心，讓客人自己找答案，部分問題根本不會進件。
3. 從工單回流：同一類問題反覆出現時，提醒主管把解法整理成文章；文章被引用的次數也能看出哪些內容最常用。

知識庫最常見的失敗，是建好之後沒人維護，內容一年後全部過期，客服乾脆不查。避免的方式是讓每篇文章有負責人與最後檢查日期，產品或流程改版時列入檢查清單，並在工單結案時讓客服可以一鍵回報「這篇文章已經不正確」。

另外，對外文章與對內文章要分開權限。內部文章可能包含退款例外的判斷原則、系統後台操作步驟，這些不適合公開。

套裝客服系統還是客製開發

市面上已經有不少成熟的套裝客服工具，內建多管道收件、指派、SLA 與知識庫。對多數團隊來說，先用套裝跑起來是合理的起點，因為套裝已經包含了許多團隊累積下來的作法，能幫你快速建立基本秩序。

以下是一張簡易判斷表，可以依自己的狀況逐項勾選：

狀況	傾向套裝	傾向客製或混合
進件管道	Email、LINE、表單等常見管道	有自家 App、特殊設備回報、內部系統自動開單
工單需要的資料	客人基本資料與訊息內容即可	處理時必須即時查訂單、庫存、合約、維修紀錄
處理流程	客服自己就能結案	需要跨部門簽核、派工到現場、退款審核
資料保存	可接受資料放在廠商雲端	有特殊保存位置或稽核要求
團隊規模變化	穩定，依帳號數擴充可接受	需要開放給大量外部人員（經銷商、維修夥伴）

如果大部分落在左欄，先用套裝；如果右欄打勾的項目都是核心作業，客製或混合才值得考慮。常見的混合做法是：收件與回覆用套裝，再透過介接把訂單、會員、維修紀錄帶進工單畫面，或是把需要簽核的退款、換貨流程另外做成內部系統。簽核流程的設計方式，可以參考電子表單與簽核流程系統。

更完整的評估框架，可參考買現成 SaaS 還是客製開發。

開發前要準備什麼：一份可以直接用的盤點清單

不論最後選套裝還是客製，下面這份清單都值得先花時間填完。填得越清楚，評估與報價就越準：

進件盤點

• 目前有哪些管道會收到客服問題？每個管道大概由誰在看？
• 是否有不該存在的管道（例如同仁的私人帳號）需要收回？

問題分類

• 列出最近一段時間最常見的問題類型，每類寫一個代表性例子。
• 哪些類型需要其他部門協助？協助的部門是誰？

處理流程

• 一個問題從進來到結束，目前經過哪些人、哪些步驟？
• 哪些步驟需要主管核准（退款、補償、例外處理）？

時效期待

• 哪些問題必須優先處理？目前大概多久能回覆？
• 客服的上班時間、假日與夜間怎麼處理？

需要串接的資料

• 處理工單時，客服最常需要切換去查哪些系統？
• 這些系統是否有可以介接的方式，或只能人工查詢？

報表需求

• 主管每週或每月想看哪些數字？誰會看？看完要做什麼決定？

個資與權限

• 哪些人能看到客人的完整資料？離職或調職時怎麼收回權限？

整理好這份清單後，再寫成正式需求文件會順利很多，可以照軟體需求怎麼寫的結構展開。

上線後要注意的幾件事

個資保護：工單裡會累積大量客人的姓名、電話、地址甚至照片，權限要依角色區分，匯出要留紀錄，保存期限與刪除方式也要事先決定。相關原則可參考隱私權政策與個資法，具體做法建議依個案諮詢法務或專業人士。

舊訊息怎麼辦：上線當天，舊信箱與 LINE 裡還有一堆處理到一半的對話。建議訂一個切換日，切換前的未結案件由專人逐筆建單，之後的進件一律走系統，避免新舊兩條路長期並存。

不要一次把規則設滿。自動指派、自動標籤、自動回覆的規則一開始越少越好，跑一陣子看清楚實際的進件樣貌，再一條一條加。規則太多又互相衝突時，沒有人知道工單為什麼被分到某個人手上。

工單系統的本質是把「誰該處理什麼」變成看得見、追得到的事。它無法取代客服的判斷與溫度，但能確保不再有人說出「上禮拜就問過了」。

客服工單牽涉到收件管道、指派規則與其他系統的串接，適合的做法因團隊而異。如果你正在評估要用套裝、客製，或是把既有客服工具跟訂單、會員資料接起來，可以和 NETVANA 聊聊你的客服流程。我們的軟體服務一律採詢問報價制，會先陪你盤點進件管道與處理流程，再建議導入範圍；服務項目與交付內容可參考軟體服務介紹。

延伸閱讀：LINE 端的自動回覆與對話設計，先看 LINE 聊天機器人開發指南；想把客戶資料與往來紀錄整合起來，可讀會員系統與 CRM 開發指南；退款、補償這類需要簽核的流程，看電子表單與簽核流程系統；工單畫面要帶出訂單與庫存資料，參考系統整合與 API 串接開發指南；還在猶豫要用現成工具還是自己做，看買現成 SaaS 還是客製開發；工單之後還要有人到現場處理，可以看外勤派工與維修回報 App 開發指南。