Service Cloud 零基礎（一）Case 淺談

本片參考：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 文檔。篇中有錯誤地方歡迎指出，有不懂歡迎留言。

原文出處：https://www.cnblogs.com/zero-zyq/p/11688659.html