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 文档。篇中有错误地方欢迎指出，有不懂欢迎留言。