🎫 工單自動建立與派發流

🎯 這條流程解決什麼

當客服團隊還用人工分派工單時，幾乎一定會遇到「分配不均」和「重要案件被淹沒」這兩個老問題。資深專員手上堆滿案子、忙到喘不過氣，新人卻在旁邊閒著沒事接；高優先級的客訴和「請問你們幾點打烊」這種小問題擠在同一個佇列裡，先進先出的結果就是重要的被排在後面。更糟的是 SLA（服務水準承諾）沒人盯，往往是客戶第二次來催、甚至直接在社群開砲，團隊才發現這張工單早就逾時三天了，而且責任還說不清楚——到底是誰該接、誰漏了、卡在哪一關，事後完全追不回來。

純人工分派的隱性成本很高。派單這件事本身就要人花時間讀、判斷、決定給誰，一張工單從進來到被指派出去，平均空轉 15 到 40 分鐘很常見，尖峰時更久；這段空轉時間直接吃掉 SLA 額度。負載不均則讓資深專員疲於奔命、品質下滑，新人卻得不到歷練。而 SLA 失控帶來的客訴與退費，往往比工單本身的處理成本高出好幾倍。

這條流程把「開單、判優先、派人、盯時效、逾時升級」整串自動化，讓支援團隊的節奏從「憑感覺、靠催促」變成「可控、可追蹤」。

導入後的改變

導入前，工單靠人工分派，從進來到被指派平均空轉數十分鐘，負載全憑主管印象分配，SLA 逾時往往是事後才被發現，重要客訴容易沉底。

導入後，來訊一進來工單就自動開立並完成優先級判定與派單，指派的空轉時間幾乎壓到即時，等於把每張工單原本浪費的數十分鐘還回給 SLA。負載被系統攤平——指派時會比對每位專員目前手上的在辦量，避免再把案子堆到已經滿載的人身上，估計可讓團隊內部的工作量落差縮小一半以上。SLA 方面，因為有倒數與接近逾時的主動提醒，逾時率可望大幅下降；真的卡住的案件也會自動升級給主管，不再「卡死到客戶來罵才知道」。

對主管最有感的，是整個團隊變得透明可追蹤：每張工單什麼時候開、派給誰、現在離 SLA 還剩多久、有沒有升級，全部有跡可循，回顧檢討終於有資料可看。以上為合理估算，實際改善幅度會依你的進單量、SLA 設定與團隊規模而不同，建議用導入前後兩週的資料自行驗證。

流程怎麼運作

對應 frontmatter 的五個節點，逐步說明：

1. 開立工單（🆕）：客服來訊或客訴升級事件觸發流程，自動在 Zendesk 建立工單，帶入客戶資料、來源通路與問題摘要。問題摘要可由 AI 從原始內文生成，讓承辦一打開就抓得到重點，不必再回頭翻整串對話。

2. 優先級判定（🎯）：用 AI 分類 API 加上規則，依關鍵字（如「退費」「無法登入」「客訴」）與客戶等級（VIP、合約客戶、一般）判斷優先級，並對應標記 SLA 時限。例如高優先級可能是 2 小時內首次回應，一般則是 1 個工作天。

3. 技能派單（🧑‍💼）：維護一張專員技能與在辦量的對照（哪些人擅長技術、哪些人處理帳務），流程比對「工單主題所需技能」與「各專員目前負載」，把案子指派給最適合且還有餘裕的人，並在 Slack 通知對方接手。

4. SLA 倒數（⏱️）：每張工單依優先級設定到期時間。設一個排程節點定時檢查所有未結案工單，當某張接近 SLA 期限（如剩 30 分鐘）就在 Slack 提醒承辦盡快回應。

5. 逾時升級（⬆️）：一旦超過 SLA 時限仍未處理，工單自動升級優先級並通知主管，避免案件無聲無息卡死。升級只做「標記與通知」，後續處理仍由人決定。

需要的工具與串接重點

• Zendesk：作為工單系統核心，用 API 建單、更新狀態、設定 SLA 政策與優先級。建議在 Zendesk 端先把 SLA 政策設好，流程只負責觸發與監看。
• AI 分類 API：負責產生問題摘要與輔助優先級判定。Prompt 要求輸出結構化結果（主題、優先級、所需技能），方便後續節點解析。
• Slack：派單與提醒的落點。依技能或團隊分頻道，指派時 @ 對應專員，逾時升級則 @ 主管。
• Gmail：當來源是 Email 時的進單管道，也可用於對外的工單通知。
• Google Sheets：維護專員技能與負載對照，以及工單統計，方便輕量起步與日後分析。

串接重點是「負載資料要即時」：技能派單的好壞取決於「在辦量」這個數字準不準。每次開單、結案都要更新對應專員的負載，否則會把案子派給其實已經滿載的人，自動化反而幫倒忙。

常見錯誤與注意事項

• 自動承諾賠付：涉及退費、補償、合約爭議的工單，升級後務必由主管人工確認才執行，系統只做通知與標記，切勿自動承諾賠付或變更合約條件。
• 優先級全靠 AI：優先級會直接影響資源分配，AI 判斷應搭配明確規則（VIP、特定關鍵字一律高優先），別把判準完全交給模型，邊界案件寧可拉高。
• SLA 設太死：把所有工單設成同一個 SLA 會讓系統失真，務必依優先級與客戶等級分級設定，否則高優先案件得不到應有的時效保障。
• 升級變狼來了：升級門檻太敏感會讓主管被通知淹沒、最後乾脆忽略。門檻要設得合理，並區分「提醒」與「真升級」。
• 個資處理：工單含客戶聯絡與交易資訊，Slack 頻道與統計表的權限要收斂，避免無關人員看到。

台灣中小企業情境案例

新竹一家做 B2B SaaS 的軟體公司，技術支援只有四位工程師輪值，過去客戶的問題從 Email 與線上表單進來後，靠值班主管早上開會時口頭分派，常常 VIP 客戶的緊急問題跟一般詢問混在一起，重要案件被排到下午才有人看，幾次差點踩到合約 SLA。導入這條流程後，來訊自動開單、依客戶等級與關鍵字判優先級，VIP 與「系統無法使用」這類案件立刻被標高優先並派給當下負載最輕的工程師；SLA 進入倒數，接近期限會在 Slack 提醒，真逾時則自動升級給技術主管。三個月下來，逾時案件明顯減少，工程師之間的負載也比過去平均很多，不再有人累垮、有人空轉。主管說最大的改變是「終於不用每天早上花半小時分派工單，而且每張單卡在哪裡一查就知道」。

延伸應用

這條流程是客服營運自動化的中樞，前後都能接。往前，可承接 /workflows 裡的客服訊息全通路分流與 FAQ 自動回覆結果，讓只有真正需要人處理的訊息才進來開單，避免工單被瑣碎問題灌爆。往後，工單結案可自動觸發滿意度調查收尾，把回饋接回團隊改善。統計資料則可接到 /automation 的排程，自動產出每日／每週工單報表（進單量、各優先級分布、SLA 達成率、各專員負載）寄給主管，讓營運檢討有資料支撐。想看更多客服營運自動化的搭配方式，可參考 /recipes 裡的相關配方，依你的工單系統與團隊規模組出最合適的支援流程。

🗺 流程圖

🧰 用到的工具

🔗 更多「企業職能」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →