本片參考：https://resources.docs.salesforce.com/222/latest/en-us/sfdc/pdf/salesforce_case_implementation_guide.pdf

練習可用：https://trailhead.salesforce.com/content/learn/projects/set-up-case-escalation-entitlements

我們在工作和生活中會經歷很多銷售流程，買過很多產品。比如作為公司的採購部採購一批電腦，作為個人買手機或者車等等。產品買回來以後銷售流程便已結束，接下來我們會針對產品使用，針對產品質量問題或者針對疑問會和產品所在的公司有各種交流和反饋。好的公司往往會重視客戶的使用者體驗並且給更好的服務，特別是TO B的流程中，service 部分作為和客戶保持好的溝通好的形象很重要的一環，針對客戶買的本公司產品的各種使用中的疑問或者問題，我們使用Case進行追蹤以及處理。Case的概念以及Case的流程不止在salesforce中，在其他的CRM產品中流程都有共通之處，接下來簡單的介紹Case在Salesforce中的使用。

場景：

A 公司需要採購一批電腦，B公司是一個電腦生產商。A 公司採購部的人員通過官網的聯絡電話對B公司進行了某個型號的電腦進行了效能以及問價描述。B公司的售前的服務部門進行了詳細的描述並且給了郵件和電話回訪同時將A公司設定成了潛在客戶併為之維護了聯絡人建立了一個潛在的機會。在A公司有強烈意願以及B公司的不斷的報價中，A公司最終下單簽訂了合同並且B公司下了order交付了電腦。銷售流程就此結束。

因為A 公司屬於B公司的一個大客戶，可能還會有其他潛在的商機。 所以B公司為了維護和A 公司的客戶關係，對A公司的售後以及其他的售前服務特別關注。 A 公司員工在使用電腦時偶爾會有宕機或者硬碟損壞或者其他使用的問題，在服務協議有效期內情況下通過郵件或者電話聯絡了B公司的售後部門，售後部門根據不同型別的疑問和問題轉交給不同的team進行處理。

上面描述的是一個特別簡單的TO B的 sales cloud 以及 service cloud 基本流程。 今天主要淺談一下 service cloud中的Case。 Case在我們的工作以及生活中相當常見， TO B 和 TO C的場景經常會涉及到，比如我們淘寶買東西詢問以及下單後質量問題或者使用問題的售後就是屬於TO C的流程。 下面的內容講述的是 TO B 的場景 關於 Case 的概念和功能相關描述。

一. Case 概念簡單描述

首先第一點，什麼是 Case ? Case 是客戶的 疑問，反饋或者問題。 在 Salesforce中有標準的表Case用來跟蹤，針對主要欄位定義我們可以有以下的概念分析。

Case型別： Case分成不同的型別，針對不同的Case型別，不同的case場景我們可能有不同的Case的處理方式。 比如詢問價格配置等其他的問題，可以維護一批售前服務的人員進行跟蹤處理case，這種也可以有機會轉成 Lead / Opportunity。針對產品問題相關的問題，需要找一批專業售後服務的人員進行跟蹤處理case。當然分類方式不唯一，我們也可以根據產品進行分類，這個不同的公司不同的業務可以設定不同的分類方式。 Case 型別在Salesforce中使用標準欄位 Type進行維護，型別為Picklist.

Case狀態： 在跟蹤狀態時也會有不同的值，這個根據不同公司會有不同的值。 比如可以設定 New / In Process / Defect Loged / Defect Solved / Escalated / Reopen / Closed 等等。 Case 狀態在Salesforce中使用標準欄位 Status進行維護，型別為 Picklist.

Case Priority : 不同的Case處理的緊急程度當然也不同，售前售後的詢問的優先順序相對較低，某些場景下的defect等相對中級，出現宕機或者影響了錢的問題則比較高階。Case Priority 在salesforce中使用Priority進行維護，型別為Picklist。

Case Origin: 客戶可以通過網站/ 電話/ email 或者其他途徑提case，在salesforce中使用 Origin進行維護，型別為 Picklist.

Case Reason: 針對不同的原因，可能需要找不同的team進行處理或者公司現有的knowledge庫已經有解決方案，正確的維護 Case Reason可以更高效的解決case。比如宕機，密碼忘記，軟體問題等等。 Case Reason在salesforce中使用 Reason 進行維護，型別為Picklist。

Case Product: 當前的Case 針對哪個產品進行建立，Case Product在saleforce中使用 ProductId進行維護，型別為 LookUp。

上面的幾點在Salesforce的Case表中都有標準的欄位與其對應，當然除了上述的主要欄位，還有其他特別多重要的欄位，可以自行檢視。如果有公司定製化的值，只需要相關的增加/刪除即可。

像建立 Opportunity以前我們需要新建 Sales Process 一樣，在建立 Case 以前我們需要建立 Support Process。 Support Process可以根據公司的業務要求進行自定義建立,這裡我們根據Case型別進行 Support Process的建立，比如我們可以根據詢問還是產品支援來建立兩個 Support Process，分別為 Inquiry / Product Support。當我們建立好 Support Process以後，我們可以設定每個 Support Process對應的 Case 狀態的值，Case 緊急程度等等上面 Picklist欄位以及對應的page layout。

正常 Contact 在業務上屬於和Case一對多的關係，一個聯絡人會提出一個或者多個case。當然，有些情況下，一個 Case可能需要聯絡多個聯絡人，在Salesforce中便有了 Case Contact Role的概念。這個概念和 Salescloud 中 Account 和 Contact 關係類似，正常 一個Account對應多個 Contact，但是有些場景一個Contact可能對應多個Account，比如一個聯絡人可能是一個子公司的領導，也可能在總公司任職其他崗位，保證業務關係變成了多對多的關係。 針對某個大客戶，很有可能Case需要聯絡多個聯絡人，比如某個IT系統出現了問題，可能需要聯絡 business user ， IT user 等等，這個時候我們就用到了 Case Contact Role，我們可以將 Case 或者 Contact 詳情頁中將 Case Contact Role 關聯列表拖拽出來。

二. Case Assignment Rule

當建立完Case以後，我們便需要考慮Case Owner是誰，即誰來解決這個case。 不同的Case型別可能需要找不同的team去解決，針對問價，效能，詳情我們可以直接分配給售前部門，針對產品問題，產品售後等可以直接分配給售後部門，這樣會大大的增快Case的關單時間以及可以人盡其用。在Salesforce中我們可以很快的解決此種分發的需求,Salesforce提供了 Case Assignment Rule，只需要針對不同的team建立不同的queue，然後建立 Case Assignment Rule，在規則裡面設定相關的 Rule Entry，根據 Rule Entry 進行規則分發即可實現不同型別的Case 分發給不同的團隊了。

當然，當assignment rule 沒有mapping的情況下，我們可以設定預設的case owner給某個人或者某個queue，這個在Support Setting中設定，除了設定default case owner以外，還可以設定是否通知default owner當case建立，case的record type的選擇方式（如果case存在多個record type）等等設定，詳情可以自行檢視。

 三. Case Auto-Response Rule

當聯絡人給我們提了 Case，我們可能需要根據不同型別，不同的緊急程度以及是否大客戶等等的條件去設定不同的郵件模板去傳送給聯絡人 Case的狀態詳情等。
在 Salesforce中我們可以使用 Case Auto-Response Rule 去輕易的搞定，只需要建立不同的Email Template， 建立 Auto Response Rule 以後根據不同的入口條件設定不同的 Rule Entry配置不同的email template即可。

四. Business Hours & Holiday

有些Support 可能是 7 * 24小時的，但是有些 Support並不需要。如果support 針對WW,還涉及到不同區域不同時差的不同服務時間。我們可以設定 Business Hours去更好的告訴客戶支援團隊可用的服務時間。Set Up中搜索 Business Hours,便可以設定新建 Business Hours. Business Hours儘管建立好，但是可能總有特殊的日子不能提供Support，比如中國春節法定假日，歐美的聖誕節等等，我們有可能針對春節或者聖誕節不支援 通用Business Hours的設定，或者有其他的設定時間，這個時候我們就需要配置 Holiday資訊了。 Set Up中搜索 Holidays，建立特殊的Business Hours 需要中斷的日期即可。

Business Hours 當建立設定好可以適用於：

• Escalation rules： 當 case 的詳情滿足了 escalation rule的條件， case將會被更新並且通過 business hours 進行升級。escalation rule後面會講。

• Holidays： 用於當 business hours 以及關聯了 business hours 關聯的escalation rule 將會被暫停當指定的日期在 holiday配置中的情況下。

• Milestones： 在entitlement processes 中以便 business hours 可以隨著case的緊急程度而改變。 Milestones以及 Entitlement process將會在後期內容涉及。

• Entitlement processes： 以便你可以針對case在同一個entitlement process中使用不同的 business hours.

五. Case Team

我們在Sales Cloud 中針對 Account 以及 Opportunity 會有 Account Team 以及 Opportunity team用來小組協作去贏單，同樣在 Service 中針對 Case 有 Case Team 的概念用來小組寫作去處理Case。那什麼是 Case Team?

Case Team 是一組人，這組人用來一起合作去解決Case。一個 case team 可以擁有很多的角色的人，比如一個case team包括 支援人員，支援經理，產品經理等。這種角色維護在 Case Team Role中，如果我們需要自定製不同的角色， Set Up 中搜索 Case Team Role 新建或者維護以及設定訪問許可權即可。

通過 case team 我們可以做到以下：

• 我們可以在系統中提前定義 case teams 一邊使用者在case操作是可以快速新增人員來協助處理case；
• 當我們在建立assignment rule時，可以新增 提前定義的case team，這樣當case建立滿足了某個assignment rule時，case team 便會自動的新增進去。
• 使用者可以將 case team related list展示在case詳情頁。
• 可以filter case list當他們是團隊成員時，只需要選擇 My Case Teams即可。
• 當執行報表時，我們可以選擇 My team's cases from 用來展示case team的case內容。

六. Case Escalation Rule

很多型別的 Case 可能都具有時效性，即通常要求解決Case。 Support Team 每天可能要處理龐大的Case，針對很多 Case 如果沒有按照指定時間或者內部評級的自定義規定時間，應該有一套針對 Case 升級的機制去做一些相關的處理，比如某個Case要求3天必須關閉，等到2天狀態還是未處理狀態，應該將 Case升級，提醒當前代辦的Support 的人去緊急處理或者 Assign 給其他的緊急處理小組去處理。這個時候我們需要定義 Case Escalation Rule 去更好的把控 Case處理的風險。

搜尋 Escalation Rule 新建後根據業務規則去建立不同的 Rule Entry 執行不同的action即可。下圖中的demo為針對 Case Record Type為Product Support 並且Priority 為High以及沒有關單的Case，如果1個小時不處理會assign給其他的queue。

 七. Web-To-Case & Email-To-Case

除了在系統中手動錄入 Case以外，Salesforce還提供了其他的方式去生成 Case. 比如我們可以在官網上有頁面給客戶用來提問問題等。啟用 Web-to-case後通過 Web-To-Case功能便可以錄入系統生成 Case ，傳送以後按照規則直接生成 Case，或者讓客戶傳送給某個固定郵箱，通過Email-To-Case功能生成Case. Web-To-Case可以自行檢視文件， Email-To-Case可以檢視以前寫過的部落格：salesforce零基礎學習（九十三）Email To Case的簡單實現

總結：篇中只是簡單的介紹了Case的概念以及基礎知識，深入掌握還請自行檢視上方的文件或者 service cloud 文件。篇中有錯誤地方歡迎指出，有不懂歡迎留