如何打造客服工單系統：工單、狀態、指派與 Email

客服工單系統把零散的請求（Email、訊息、走廊上的「快問一下」）轉換成工單：每個問題一筆紀錄，附上負責人、狀態、優先順序與完整的對話。要打造一套，你需要建立工單的方式、附篩選器的共用佇列、指派機制、一個能區分公開回覆與內部備註的對話串，以及通知功能，確保沒有人被晾在一旁。AI 應用程式建構工具可以在一個下午就打造出堅實的第一版，適用於內部 IT、人資或總務服務台。面向客戶的客服若要做 Email 串接、回應時限與報表，就需要更多的用心，而這正是成熟的客服產品值得收費的地方。

系統需要什麼

資料

從一開始就要儲存首次回覆時間與解決時間的時間戳記。所有報表都建立在它們之上，而且事後無法回推重建。

頁面

• 提出人端： 附分類與附件的「提交請求」表單、「我的請求」列表，以及每張工單的對話串。
• 客服端： 佇列（我的工單、未指派、所有未結案）、篩選與搜尋、工單頁面（含回覆、備註、狀態、優先順序與負責人的控制項）。
• 管理員： 分類、團隊、客服人員、預存回覆，以及一份簡單的報表。

權限

提出人只能看到自己的工單與公開回覆。客服人員能看到所屬團隊的工單與內部備註。主管與管理員可以看到全部，並管理設定。內部備註外洩給客戶是服務台最典型的災難，因此權限必須在伺服器端強制執行，而不是只靠隱藏分頁。參見角色型存取控制。

決策與取捨

表單、Email，還是兩者都用

網頁表單最簡單，也能得到乾淨的資料：分類、優先順序與必填欄位。Email 收件（人們寫信到 support@，工單就出現）是客戶習慣的方式，但需要能接收郵件、並把郵件送到你的應用程式的 Email 服務商，還需要串接機制，讓回覆能附加到正確的工單（通常是在主旨中加入工單編號，或使用獨一無二的回覆地址）。先從表單開始，等流程驗證成功後再加入 Email。從應用程式寄送 Email說明了寄出的部分。

指派

選項包括：客服人員從未指派佇列中自行挑選、在團隊內輪流指派（round-robin），或依分類指派。小團隊適合自行挑選。當工單常常無人認領時，自動指派會有幫助。

優先順序與回應時限

定義兩到三個優先順序，並為首次回覆設定目標（「緊急：1 小時，一般：1 個工作天」）。在每張工單上顯示剩餘時間，比沒人會看的月報更有用。若以營業時間計算，計算會更複雜，因此要及早決定時限是否包含夜間與週末。

合併與重複工單

同一個問題被回報三次是很常見的。加入「合併到工單 #」的動作，可以讓客服人員不必重複回答同樣的問題，這個功能值得及早建置。

一句好用的第一個提示

為一家 60 人的公司打造內部 IT 服務台。員工用表單提交請求：主旨、分類（硬體、軟體、權限、網路、其他）、優先順序（低、一般、緊急）、描述與附件。每張工單都有編號，狀態為新建、處理中、等待提出人、已解決、已關閉。IT 客服人員看到的佇列有「未指派」「我的」「所有未結案」分頁，可依分類、優先順序與狀態篩選，並可搜尋。工單頁面會清楚區分公開回覆與內部備註，員工永遠看不到內部備註。客服可以指派、更改狀態與優先順序、使用預存回覆，並合併重複工單。追蹤首次回覆與解決時間，並在每張工單上顯示距離最後更新過了多久。員工有「我的請求」頁面。角色：員工、客服、管理員。所有資料存入資料庫。介面簡潔、資訊密度高、速度快，不需要多餘的裝飾。

建置步驟

1. 工單模型與表單。 提交、列表、開啟工單、回覆。
2. 佇列與篩選。 未指派、我的、所有未結案；篩選與搜尋；依優先順序與等待時間排序。
3. 角色與登入。 提出人、客服、管理員，並在伺服器端確保備註對提出人隱藏。
4. 指派、狀態與優先順序控制，並為每次變動留下活動紀錄。
5. 通知。 透過你自己的 Email 服務商，在收到公開回覆時通知提出人，在被指派時通知客服人員。
6. 預存回覆與合併。
7. 回應時限與基本報表：依等待時間列出未結案工單、首次回覆時間、各分類的工單數。
8. Email 收件，待其他功能運作後再加入，並徹底測試串接。
9. 先由一個團隊試用兩週，再推廣給全公司。

常見錯誤

• 內部備註對提出人可見，因為只在介面上隱藏而已。
• 狀態與分類太多。 客服人員會選第一個看起來接近的選項。每類最多先放五個。
• 沒有首次回覆與解決時間的時間戳記。 有人問「我們是不是變快了？」的那天，你會需要這些數字。
• Email 回覆變成新工單，而不是串接到原工單。請測試從手機郵件 App 回覆，因為它常會改動主旨。
• 每張工單指派多人，卻沒有人負責。 每張工單只指定一位負責人；其他人則作為關注者。
• 附件使用公開網址。 錯誤訊息的截圖常含有私人資料。檔案要保持私人，只提供給能看到該工單的人。

什麼時候現成產品是較好的選擇

對於跨 Email、即時聊天與社群管道的面向客戶服務，若需要回應時限追蹤、滿意度調查、巨集、報表與整合功能，專門的服務台產品幾乎總是較好的投資。這些產品花了多年解決 Email 串接、垃圾郵件、派單與報表的問題，而這些並不是你的業務特色所在。我們的Zendesk 替代方案指南比較了各種選項。

自建適合內部服務台（IT、人資、總務、財務申請）、工單其實是一連串特定步驟的任務的利基工作流程，以及希望把請求與既有資料相連的團隊。當許多人偶爾才需要處理工單時，自建也能避免按客服人員數量計費。內部工具指南更廣泛地涵蓋了這個類別。

用 Mythex 打造

在 Mythex 中，你用對話描述服務台，在即時預覽中檢視，然後發布給你的團隊。當資料需要儲存時，工單會存在代理程式加入的 Postgres 資料庫中；附件則放在專案的檔案儲存。提出人與客服的登入，以及所有收發的 Email，都使用你自己的服務商——Mythex 沒有內建的終端使用者登入或 Email 產品；發送 Email 食譜說明了做法。團隊成員可以透過共用工作區一起協助建置，Mythex 本身不收取每位席次的費用。

若需要起始提示，可以試試內部請求佇列或錯誤追蹤範本，並搭配知識庫，讓常見問題能自行解答。

常見問題