Service Cloud 建置重點：案件管理、分派與客服自動化

客服自動化能否順利運作，取決於案件資料、分派規則與人員狀態是否一致。Salesforce Service Cloud 建置需要把這些條件一起設計。本文從 Case Management、Omni-Channel 與自動化規則切入，整理設定前的判斷、常見問題與驗收方法，協助企業建立穩定的客服流程。

摘要

Service Cloud 建置應把案件、分派與自動化視為連續流程。案件欄位要有共同定義，Omni-Channel 要核對工作類型、人員資格、可用狀態與容量，自動化則需要明確觸發及例外處理。本文沿用 Service Cloud 名稱，目前官方文件亦使用 Agentforce Service；設定與授權應以實際方案及現行文件確認，尤其不要直接套用已退役的 Standard Omni-Channel 操作方式。

1. Case Management 先建立一致的案件語言

定義案件、分類與優先序

一筆 Case 應代表可追蹤的服務需求。企業需要說明同一問題的後續回覆如何延續、不同問題何時分開，以及重複進件如何處理。若案件邊界不清楚，後續分派與報表都容易失真。

分類欄位應服務實際處理，例如產品、問題類型或支援團隊。選項太細可能增加判斷負擔，太粗又無法支持分派。可先以代表案件測試分類是否容易理解，再逐步完善。

優先序也需要明確標準。客戶影響、時間敏感度與服務安排可能共同影響排序，不能讓每個人自行解讀「緊急」。規則應包含誰能調整，以及變更後是否需要重新評估分派或通知。

狀態要能說明下一步

案件狀態不只是報表標籤，還應讓團隊知道目前由誰負責、在等什麼及何時需要跟進。等待客戶資料與等待內部支援的處理方式不同，應按營運需要設計。

每個狀態都要有進入與離開條件。若所有案件長期停留在處理中，主管便難以分辨真正的工作量與等待量。需要記錄的資訊應與任務結合，避免客服為了通過必填欄位而填入無意義內容。

結案與重新開啟也要納入流程。客戶再次回覆、補充新問題或表示尚未解決時，應有明確判斷及責任，並測試它們對服務時限、後續通知與統計口徑的影響。

2. Omni-Channel 分派需要四類條件

工作類型與分派入口

先確認要分派的是 Case、訊息工作或其他支援物件，再核對服務通路及路由設計。不同通路可能有不同授權、生命週期與設定，不能把一套案件分派方法直接套用到所有工作。

在使用佇列分派的情境中，案件需要進入正確的佇列，並有對應的路由設定。資料分類若在進入後才完成，還需確認何時重新評估，避免工作被送到不適合的團隊。

人員資格與可用狀態

能查看案件，不一定代表能接收該類分派。企業應核對人員的通路、相關權限、佇列或技能安排，以及可使用的狀態，讓業務規則與系統條件一致。

可用狀態需要反映實際工作。登入系統不等於正在接案，休息、處理其他任務或交班時，也應有清楚操作方式。培訓要說明狀態對接收工作的影響，而不只教人員如何切換按鈕。

容量與工作負荷

容量是分派的重要條件，應同時檢查人員可承擔的工作量與每類工作所需容量。若單一工作需求超過可用容量，即使有人在線，仍可能無法分派。

企業應依工作性質設定合理權重。簡單查詢與需要深入排查的案件，未必適合以相同負荷看待。先用實際樣本觀察，再調整規則，比單純提高容量數字更有依據。

不同容量模型對工作完成或狀態變更的處理可能不同，必須確認何時釋放容量。不能把關閉畫面一概視為完成案件，也不能假設案件仍指派給某人就一定使用同一種容量計算。

圖 1：分派需共同確認工作類型、人員資格、可用狀態及容量。

3. 優先序、轉交與無人接收要預先設計

分派優先序應反映服務目標，並處理同一團隊同時承接不同工作時的取捨。設定高優先序不會增加實際人力，若高優先工作持續累積，仍需檢視團隊安排與上游原因。

轉交時，接手人員應取得問題摘要、已做處理及下一步，而非只看到擁有人改變。企業要定義轉交是否需要接收確認，以及未接收時由誰繼續負責，避免案件落在責任空隙。

沒有符合技能或可用容量的人員時，應有替代程序，例如保留等待、通知主管或按核准條件改由另一團隊處理。具體做法需配合通路及路由方式測試，不宜假設平台自動處理所有例外。

高峰與非營業時間的情境也要演練。客戶應獲得符合實際安排的回覆，客服主管則需要看到待處理量與最久等待。避免自動回覆承諾了團隊無法提供的處理時間。

官方目前已以 Enhanced Omni-Channel 為主要方向，Standard Omni-Channel 於 Summer ’26 版本退役。既有企業應檢查當前組織設定、升級結果與適用文件，避免把舊教學中的預設視為現況。

4. 客服自動化從觸發、動作與例外開始

明確說明何時執行

自動化規格應回答哪個事件觸發、需要滿足哪些條件，以及同一案件是否可以再次執行。例如案件優先序改為高時通知負責人，與每次保存高優先案件都通知，是不同設計。

Salesforce Flow 的紀錄觸發流程可依紀錄建立或更新及條件執行。建置時要確認真正需要的觸發時點，並測試不相關欄位更新是否會重複產生動作，避免通知或任務被放大。

動作要有清楚責任與範圍

動作可能涉及更新資訊、通知人員或交接工作，應說明由誰使用結果、是否需要回覆及如何確認完成。系統成功執行一個動作，不代表業務上已完成服務。

若標準規則、Flow 與外部整合同時修改案件，應整理共同的執行邊界。哪些欄位由誰維護、哪些動作只能執行一次，都要有一致設計，避免互相覆寫或反覆觸發。

例外需要可追蹤

缺少客戶資料、找不到接收人或外部系統暫停時，自動化應有適當處理與通報。錯誤紀錄至少要讓維護人員知道影響哪個工作、何時發生及是否需要重試。

重試也要考慮先前是否已完成部分動作。若通知已發出而後續更新失敗，直接重跑可能造成重複。企業應在設計時說明如何辨認已處理狀態，並以測試驗證恢復方式。

圖 2：客服自動化應先定義觸發條件、執行動作與例外處理。

5. 服務時限與知識內容要支援實際處理

首次回覆、解決與等待是不同概念。企業可評估 Entitlement Processes 與 Milestones 如何支援服務時限，但先要定義適用客戶、案件、營業時間及完成條件，再核對設定。

不能只以自動回覆代表真正回應。若企業衡量的是客服已理解並處理問題，就需要相應紀錄與共同定義。否則指標可能看似良好，客戶卻仍長時間等不到有用資訊。

知識內容與常用回覆可以減少重複工作，但應有適用情境、審核與更新責任。客服需要容易找到相關內容，也要知道何時不能直接套用、何時需要進一步排查或升級。

若規劃 AI 輔助服務，先確認實際功能、授權與資料範圍，並設計人工接手與驗證方式。不要在基本案件流程尚未穩定時，把所有例外都交給尚未驗證的新能力處理。

6. 分派異常可以如何逐層檢查

當案件沒有送到預期人員時，先選一筆可重現的紀錄，確認問題發生的時間與當時條件。不要同時改動多個設定，否則即使暫時恢復，也難以知道真正原因。

• 確認案件類型、分類資料與實際分派入口。
• 核對案件是否進入預期佇列或路由流程。
• 檢查服務通路、路由設定與適用權限。
• 確認接收人員當時的資格及可用狀態。
• 比對工作所需容量與人員剩餘容量。
• 檢查例外路徑、轉交與外部整合紀錄。
• 修正後以相同情境驗證，並保留結果。

若只有部分案件出現問題，應比較它們與正常案件的差異，例如產品、語言、來源或建立時間。若所有工作都受影響，則優先檢查共同入口與人員狀態，再逐步縮小範圍。

跨環境部署後也要重新驗證相關參照與權限。測試環境能運作，不代表正式環境的佇列、使用者與整合設定完全一致。部署清單應包含這些差異及確認人。

7. 用代表情境完成上線驗收

假設一家企業有一般客服與產品技術團隊，首期可把一般問題送到客服，符合特定條件的技術案件再轉交。這是假設建置情境，目的在於檢查責任與資訊是否能完整接續。

驗收應包含有符合人員、所有人忙碌、缺少分類、轉交失敗與結案後再回覆等情況。每一筆都應能說明預期路徑、實際處理與最後責任人，而非只看案件最後停在哪個佇列。

自動化測試也要區分建立與更新情境。確認第一次滿足條件、仍維持相同條件及離開後再次進入時的結果，才能判斷是否符合原本設計，並減少重複執行。

正式上線後保留一段有明確支援安排的觀察期，收集客服與主管回饋。優先處理影響接案、回覆及資料正確性的問題，再安排便利性改善，讓變更有清楚次序。

讓設定與營運紀錄保持一致

為每個分派與自動化規則保留簡明說明，包括用途、擁有人、依賴欄位與最近驗證日期。當有人提出修改需求時，團隊便能先查找既有規則，減少為相同目的建立多套互相干擾的設定。

變更前應列出受影響的案件類型與相關動作。例如新增優先序選項，可能同時影響分派、通知、時間規則及報表。只改選單而未更新其他部分，容易造成部分案件走向未預期的路徑。

也要說明人工調整與自動化的關係。客服手動更換負責人或優先序後，哪些規則仍會執行、哪些應保留人工決定，必須事先定義。否則人員可能反覆修改，系統又持續改回原值。

監控時除了失敗數量，也應觀察工作是否停在不應停留的位置。例如通知已發出但長期未接手，可能是責任或人員安排問題；不能只因技術紀錄顯示成功，就把它排除在改善範圍之外。

主管回顧應結合案件品質與工作負荷。若某類問題經常轉交多次，可檢查分類及所需資訊；若容量經常用盡，則評估工作權重與實際人力。數據應幫助找出原因，而非只用來比較個別人員的結案速度。

最後，將解決過的異常轉成可重複使用的測試情境。每次修改路由或自動化後，重新驗證關鍵情境，能讓過去的經驗持續保護日常流程，並降低相同問題再次出現的機會。

測試紀錄亦應保留當時的設定版本，讓後續比較能建立在相同條件上，而不只是記得曾經測試成功。

8. 常見問題（FAQ）

9. 結語

Service Cloud 建置要讓案件語言、分派條件與自動化規則互相配合。把正常及例外路徑一起驗證，並建立逐層查找問題的方法，能讓客服流程更容易維護。

LeadsTech 可協助企業討論 Salesforce 客服系統、案件流程與整合需求，釐清建置重點及改善方向。

了解 Salesforce Service Cloud

如遇到案件分派或自動化維護問題，可整理代表情境與目前設定範圍，與團隊討論合適的處理方式。

聯繫我們，討論你的企業需求

10. 延伸閱讀

• 全球 CRM 系統：以 Salesforce 管理完整客戶生命週期

  從跨部門資料與流程角度理解完整的客戶關係管理。

• 全球 B2B 企業 CRM：Salesforce 導入指南

  延伸了解企業需求、系統整合與導入規劃。