當客戶查詢分散於電郵、網站表單、電話與即時通訊，服務團隊往往不是缺少努力，而是缺少一致的 Case 管理規則。Service Cloud Case Management 的價值，在於把每宗查詢轉換為可追蹤、可分派、可升級及可量度的服務流程，讓前線、主管與跨部門專家使用同一套資訊工作。LeadsTech 在規劃服務營運時，會先把進件渠道、分類準則與升級責任對齊，避免把 Case 系統只當成收件箱，而是讓它成為可追蹤的服務協作流程。
1. 本文重點精華
- 成功的 Case Management 應先統一進件資料與分類口徑，再用 Assignment Rules、Queues 或 Omni-Channel 把工作交給合適人員。
- SLA 不應只是一個截止時間；應配合優先級、Entitlement、Milestone、提醒與升級路徑，令承諾可以被監察及執行。
- Knowledge 應嵌入解決流程，並把高頻問題與新解法回饋到知識庫，減少重複搜尋與回覆差異。
- 上線後要同時觀察速度、品質與工作量，包括首次回應時間、平均解決時間、SLA 達標率、重開率、轉派率及積壓案件年齡。
2. Service Cloud Case Management 為甚麼不只是記錄工單？
Case 是客戶問題的營運紀錄，除了主旨與描述，還應連結客戶、聯絡人、產品、服務級別、來源、優先級、負責人、互動歷史與解決結果。若企業只把 Case 當作收件箱，資料會停留在「誰回覆了甚麼」；若把它視為端到端流程，便能回答「問題從哪裏來、為何被延誤、誰最適合處理、哪些問題可以預防」。
建立流程前，先定義 Case 的開始與結束。開始可能是 Email-to-Case、Web-to-Case、電話紀錄或整合渠道；結束不應只是把狀態改為 Closed，而要確認客戶已獲得答案、必要的後續工作已完成、原因與解決分類已填妥。對需要第三方或內部工程團隊參與的案件，也要清楚區分等待客戶、等待內部及實際處理時間，避免 SLA 報表失真。
3. 如何設計 Case 進件、分類與分派流程？
第一步是把必要欄位控制在足以判斷路由的程度。一般可包括來源、產品或服務、問題類型、影響範圍、緊急程度及客戶服務級別。欄位太少會令團隊反覆追問；欄位太多則令客戶與前線跳過填寫。較實際的做法，是在進件時收集最少資料，再由 Flow 或服務人員於處理期間補充根因與解決分類。
Salesforce 的 Case Assignment Rules 可按條件把新 Case 指派給使用者或 Queue；Queue 適合共享工作池，讓成員取得案件。當企業需要考慮人員在線狀態、容量、技能與優先級時，可評估 Omni-Channel。無論使用哪種方法，都應設置預設負責人及兜底規則，避免未符合任何條件的 Case 成為無人負責的孤兒案件。
例如，一家提供工業設備的 B2B 企業，同時收到一般操作查詢、零件訂購及生產線停機報告。系統可把「生產停機＋白金服務客戶」列為最高優先，交由具備指定產品技能的當值人員；零件問題進入供應鏈 Queue；一般操作查詢則先推薦 Knowledge 文章。這個假設情境的重點不是複製欄位，而是把業務風險、客戶承諾與處理能力轉換成可測試的路由條件。
4. 如何用 SLA、升級與 Knowledge 提升解決效率？
SLA 設計應由客戶承諾倒推系統規則。不同服務計劃可對應不同的首次回應及解決目標，並以 Entitlement 與 Milestone 追蹤。Escalation Rules 可在案件於指定時間內未解決時觸發升級行動；團隊也要列明升級後由誰接手、主管何時介入、客戶如何收到更新，以及甚麼情況需要跨部門協作。
Knowledge 則把個人經驗變成組織能力。服務人員應能在 Case 工作空間中搜尋或獲得相關文章建議，回覆時引用一致內容；結案後，若答案不存在、內容過時或同類問題持續增加，便建立更新任務。文章需有擁有人、審核週期、適用產品版本及退役機制，否則知識庫規模愈大，搜尋結果反而愈難使用。
5. Service Cloud Case Management 上線檢查清單
- 列出所有進件渠道，確認每一渠道都能建立或關聯正確的 Case。
- 定義必要欄位、選項值、優先級矩陣及結案條件。
- 為每條 Assignment Rule 準備測試案例，並加入預設負責人或兜底 Queue。
- 把服務承諾轉換為 SLA、Milestone、提醒及 Escalation 路徑。
- 設定角色、分享權限與敏感資料存取，避免過度開放。
- 把常見解法連接到 Knowledge，建立內容擁有人及更新週期。
- 先以小組試行，檢查通知、轉派、重開、等待及結案等例外情況。
- 建立主管儀表板，並安排每月檢討分類、路由與積壓案件。
6. 如何衡量 Case Management 成效？
單看「結案數量」容易鼓勵快速關閉，卻未必代表問題真正解決。建議同時追蹤首次回應時間、平均解決時間、SLA 達標率、首次接觸解決率、重開率、轉派率、各年齡層積壓量與客戶滿意度。這些指標要按渠道、產品、問題類型、優先級與服務隊伍切分，才能辨識瓶頸來自需求增加、分類錯誤、技能不足或跨部門等待。
管理者應固定抽查高優先級、超時、重開及多次轉派的 Case，將原因轉換為改善項目。若某類案件持續被錯派，先調整欄位或規則；若大量查詢有相同答案，可改善自助服務或 Knowledge；若個別產品的解決時間升高，則與產品團隊檢視根因。Case Management 因此不是一次性設定，而是一個持續營運的閉環。
7. 常見問題（FAQ）
Service Cloud Case Management 適合哪些企業？
適合需要跨渠道處理客戶查詢、管理服務承諾、分派工作及分析服務表現的企業。流程規模可以由單一支援團隊開始，再逐步擴展。
Assignment Rules、Queues 與 Omni-Channel 有何分別？
Assignment Rules 按條件決定負責人或 Queue；Queue 是共享案件池；Omni-Channel 可進一步按可用性、容量、優先級或技能分配工作。選擇取決於服務模式與路由複雜度。
每一宗 Case 都需要 SLA 嗎？
不一定。企業可按客戶合約、服務計劃、問題影響及渠道設定不同目標；關鍵是讓適用條件、計時方式、暫停規則及升級責任清楚一致。
Case 關閉後仍可重新開啟嗎？
可以按企業流程設計，但應保留重開原因並監察重開率。若新問題與原 Case 不同，建立新 Case 並保留關聯，通常更有利於分析。
如何避免自動化規則愈來愈複雜？
為規則設立擁有人、命名標準、優先順序與測試案例；每次修改先在測試環境驗證，並定期移除過時條件。流程例外太多時，應先簡化業務政策，而非只增加規則。
8. 結語
優秀的 Service Cloud Case Management 不是把現有收件箱搬到 CRM，而是把客戶承諾、服務責任及改善數據連成一套可執行流程。企業可先從高頻渠道和一個服務小組開始，建立清晰分類、分派、SLA、Knowledge 與指標，再按實際結果擴展。若你希望評估現況、設計流程或規劃 Salesforce Service Cloud 導入，歡迎聯絡 LeadsTech，亦可了解 LeadsTech 的 Salesforce Service Cloud 解決方案。
9. 延伸閱讀
- Salesforce CRM 系統選型與導入指南
延伸了解 B2B 企業規劃 Salesforce CRM 時的選型與實施重點。 - 如何選擇 CRM 系統與顧問公司？
評估 CRM 平台與合作夥伴時，可從需求、流程、數據與落地能力切入。 - 如何選擇全球數位合作夥伴？Adobe 與 Salesforce 能力評估
比較全球數位化項目中 Adobe 與 Salesforce 生態的導入能力。
