Service Cloud 導入指南：客服流程、系統建置與上線

客服系統導入牽涉的不只是案件畫面，還包括通路、責任、服務時限與跨部門資訊。Salesforce Service Cloud 建置應從實際客服流程開始。本文整理需求盤點、案件設計、資料整合、測試與上線步驟，協助企業建立可追蹤、可維護的服務作業方式。

摘要

Service Cloud 導入應先釐清案件如何進來、誰負責、如何處理及何時完成，再設定工作台、分派、服務時限與整合。本文沿用企業熟悉的 Service Cloud 名稱；目前 Salesforce 官方文件亦使用 Agentforce Service。實際功能與授權需依方案確認。首期宜完成一條可驗收的服務流程，並把資料移轉、操作培訓與上線後支援一起規劃。

1. Service Cloud 導入先從客服現況盤點

看清案件來源與處理路徑

先列出客戶使用的電子郵件、表單、電話或訊息通路，再追查每種查詢如何被記錄及交接。若同一問題散落在信箱、試算表與個人對話中，系統設計便需要處理紀錄關聯與責任歸屬。

盤點時可選擇常見、複雜及需要升級的代表案件，觀察從接收、補充資料、內部協作到結案的過程。不要只依管理者描述流程，也應讓第一線人員說明實際工作與例外。

每個痛點都應連到可觀察結果。例如查詢找不到負責人、轉交後沒有回覆，或客服必須重複查詢訂單。這些問題能幫助團隊判斷首期優先工作，而不是把所有功能同時納入。

定義服務目標與首期範圍

目標可以包含案件可追蹤、交接清楚、資訊容易取得及回覆一致。若要設定時間指標，先確認資料如何記錄、起訖點如何定義，才能比較導入前後的變化。

首期可聚焦一個客服團隊、主要通路及代表案件類型。把必要流程做完整，再逐步加入其他通路或自助服務，通常更容易安排測試、培訓與問題處理。

範圍文件應列出納入與暫緩項目、資料來源、主責人及驗收條件。服務部門、資訊團隊與其他協作部門都需要理解這份文件，避免各自以不同假設進行建置。

2. 設計 Case 生命週期與資料結構

Case 可作為追蹤客戶問題與服務工作的核心紀錄。企業應先定義一筆案件代表什麼，再決定如何連結客戶、聯絡人、產品、訂單或其他服務資料，避免把所有訊息都混成同一類工作。

狀態應反映實際處理情況，例如新建、處理中、等待資料與已完成。名稱可以依企業需要設計，但每個狀態都要說明進入條件、負責人及下一步，否則報表難以解讀。

等待客戶回覆與等待內部支援，是不同的營運問題。是否分開記錄，應取決於團隊要如何跟進與衡量。不要為了讓畫面簡單，而失去判斷案件停滯原因的重要資訊。

結案條件也需明確。問題已解決、客戶已獲告知、必要紀錄已補齊，可能是不同檢查項目。若客戶再次回覆，應決定重新開啟原案件或建立相關新案件，並測試對追蹤及指標的影響。

欄位設計以處理與分析需要為準。分類、優先序及原因應有共同定義，減少重複輸入；只有在真正需要時才加入必填限制，避免第一線人員為了保存案件而填入不準確資料。

圖 1：案件生命週期從接收、分派、處理到結案，各階段都需有責任與條件。

3. 建立客服通路與 Service Console

Salesforce 提供 Email-to-Case 與 Web-to-Case 等方式，協助把電子郵件或網站表單查詢建立為案件。企業仍需規劃郵件轉送、表單欄位、回覆內容及相關限制，並以實際情境驗證。

同一客戶從多個通路聯絡時，應能辨識相關紀錄並避免重複處理。自動關聯與人工判斷的分工需要說清楚，不能只因姓名或郵件相似，就假設所有查詢都屬於同一問題。

Service Console 的工作區應圍繞客服任務安排，讓人員容易查看案件、客戶背景與必要資訊。先確認處理時最常切換哪些系統，再決定顯示或整合哪些內容，避免把所有資料都塞進畫面。

常用回覆與知識內容可協助維持一致，但需要審核及維護。針對不同問題準備適當範本，並清楚標示哪些內容只供內部參考、哪些可以對客戶使用，避免過期資訊繼續被引用。

電話、訊息或其他通路可能涉及不同授權及連接安排。導入前應確認具體方案、現有供應商與資料流向，不能將「全通路」理解為所有通路均已包含並可立即使用。

4. 案件分派與服務時限要一起規劃

讓案件找到可處理的人

分派規則可依案件類型、語言、產品或團隊責任設計。先確認每種工作由誰接收、哪些需要特定能力，以及沒有符合人員時怎麼辦，再決定使用哪些設定完成。

Omni-Channel 可協助把不同服務通路的工作分派給合適且可用的人員。建置時需要一併核對服務通路、分派方式、人員狀態與容量，不能只建立佇列就假設所有工作都會被正確接收。

目前官方文件已轉向 Enhanced Omni-Channel，Standard Omni-Channel 已於 Summer ’26 版本退役。企業應以現有組織與當前文件確認設定及遷移情況，避免直接沿用舊版操作步驟。

把服務承諾轉成可驗證規則

首次回覆與解決問題是不同時間點。企業應說明承諾適用的客戶、案件及服務時段，再評估 Entitlement Processes 與 Milestones 等功能如何支援追蹤，而不是先設定一個通用倒數時間。

時間規則需要處理營業時間、假期、時區與等待狀態。哪些情況計時、暫停或完成，應由業務規則決定，再逐一測試。不能因畫面顯示計時器，就認定它已正確反映企業承諾。

升級程序則要說明通知誰、誰接手以及如何確認處理。只寄出提醒並不代表問題被解決；應讓主管能看見仍未有人跟進的案件，並有可操作的後續安排。

5. 資料整合與移轉如何安排

客服可能需要訂單、合約、設備或歷史互動資料。先區分哪些需要在平台保存，哪些只需在處理時查詢，再確認來源、更新頻率、權限與失敗處理，避免不必要地複製所有資料。

整合規格要定義識別方式與主責來源。例如訂單狀態由交易系統維護，客服只能查看或提交申請，便需要清楚的操作邊界。若平台顯示舊資料，也應讓人員知道更新時間與處理方法。

移轉前先整理客戶與聯絡人對應、案件分類及狀態。歷史資料未必符合新規則，可保留必要原始資訊並建立映射，避免為了套用新欄位而改變過去紀錄的含義。

先以樣本演練匯入，核對筆數、關聯、日期、擁有人及附件等需要移轉的內容。未完成案件尤其重要，因為它們會直接影響切換後的服務工作，應安排主責人確認。

切換計畫需要說明舊系統何時停止新增、最後一批變更如何補入，以及切換後去哪裡查找歷史資訊。若新舊流程短期並行，要定義唯一的工作主責位置，避免兩邊重複處理。

6. 測試與培訓要重現真實客服工作

測試不能只確認案件建立成功，還要從客戶進件一路追到分派、回覆、協作及結案。讓第一線客服、主管與系統管理者分別完成自己的任務，才能看出流程是否真正連貫。

例外測試可包括非營業時間進件、無可用人員、轉交、缺漏資料、整合中斷及結案後再回覆。每種情況都要有預期結果，並記錄實際行為及尚待處理的問題。

權限測試需使用不同角色帳戶。客服能否取得必要資料、主管能否查看團隊工作、其他部門能否只處理被授權部分，都應透過實際操作確認，不能只查看設定名稱。

培訓以情境任務為主，例如如何接手案件、查找知識、更新狀態及升級問題。讓人員實際完成操作，再提供簡明工作指引，比只展示功能畫面更容易發現理解落差。

• 客戶查詢能從指定通路正確建立紀錄。
• 案件分類、分派與無人接收情境已驗證。
• 回覆、知識內容及跨部門交接能正常使用。
• 服務時限及例外計時符合核准規則。
• 整合資料、權限及移轉關聯已核對。
• 操作人員知道異常通報與暫停處理方式。

圖 2：正式上線前，同時確認人員準備、流程驗證與資料品質。

建立指標基線與共同定義

在正式切換前，先整理目前可取得的服務量、待處理案件與回覆時間，並記錄資料限制。若舊流程沒有完整時間戳記，可以先從新流程開始建立基線，不宜拿不同口徑的數字直接比較。

指標需要說明分母、期間與排除條件。例如重新開啟的案件是否計入新進件、等待客戶期間如何呈現，以及轉交是否重新計算處理時間，都會影響結果。這些定義應由服務管理者共同確認。

報表也要配合使用者的決策。第一線需要知道下一件工作及待補資訊，主管需要看積壓與分派情況，管理層則關心問題趨勢與改善進度。避免用同一張總覽取代所有角色的需求。

7. 正式上線與持續改善

上線前由服務、資訊與資料負責人共同確認準備度，包含人員、流程與資料。正式切換時間應配合服務量與支援安排，並定義發現重大問題時的替代處理及恢復條件。

初期可集中觀察未分派案件、長時間等待、重複進件與整合失敗。這些訊號有助於發現流程缺口；不要只追求結案數量，忽略客戶是否真的獲得適當回應。

假設一家 B2B 設備企業先導入電子郵件客服與技術支援流程，可先讓一般查詢進入客服團隊，需要產品專長的問題再交由技術人員。這是假設導入情境，並非實際客戶成效案例。

在此情境中，重點是轉交後仍有人負責、訂單或設備資料可查，以及客戶回覆能接續原本脈絡。先把這條服務鏈驗證完整，再擴展其他通路或更多自動化，會更容易管理。

持續改善應結合案件原因、處理瓶頸與人員回饋。若同一問題反覆出現，可改善知識內容或上游流程；若交接常延誤，先檢查責任與資訊，再決定是否調整系統設定。

讓服務知識與流程一起更新

每次解決新問題後，可評估是否值得整理為知識內容。內容應說明適用情境、操作前提、處理步驟及何時需要升級，並指定審核人與檢視日期，讓團隊有一致的使用依據。

知識更新與流程改版需要互相通知。如果回覆範本仍引用舊步驟，即使系統設定已調整，客服仍可能提供過期說明。將相關資產列入變更清單，能減少資訊不同步。

上線後也應保留固定的問題整理節奏，讓第一線人員提出難以分類、缺少資料或操作繁複的情境。先確認問題是否普遍及原因，再安排調整，避免每個例外都新增一個欄位或自動化規則。

8. 常見問題（FAQ）

9. 結語

Service Cloud 導入要把案件流程、資料與人員安排一起建好。從明確的首期範圍開始，以真實情境完成驗收與培訓，才能讓系統設定轉成穩定的服務作業。

LeadsTech 可協助企業討論 Salesforce 客服流程、資料整合與系統建置需求，釐清導入範圍及上線安排。

了解 Salesforce Service Cloud

如需規劃客服系統導入，可先整理主要通路、案件類型與目前交接問題，與團隊討論適合的實施路徑。

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

10. 延伸閱讀

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

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

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

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