Service Cloud 零基础(一)Case 浅谈

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

练习可用:https://trailhead.salesforce.com/content/learn/projects/set-up-case-escalation-entitlementsapp

咱们在工做和生活中会经历不少销售流程,买过不少产品。好比做为公司的采购部采购一批电脑,做为我的买手机或者车等等。产品买回来之后销售流程便已结束,接下来咱们会针对产品使用,针对产品质量问题或者针对疑问会和产品所在的公司有各类交流和反馈。好的公司每每会重视客户的用户体验而且给更好的服务,特别是TO B的流程中,service 部分做为和客户保持好的沟通好的形象很重要的一环,针对客户买的本公司产品的各类使用中的疑问或者问题,咱们使用Case进行追踪以及处理。Case的概念以及Case的流程不止在salesforce中,在其余的CRM产品中流程都有共通之处,接下来简单的介绍Case在Salesforce中的使用。ide

场景:性能

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 的概念和功能相关描述。ui

一. Case 概念简单描述scala

首先第一点,什么是 Case ? Case 是客户的 疑问,反馈或者问题。 在 Salesforce中有标准的表Case用来跟踪,针对主要字段定义咱们能够有如下的概念分析。htm

Case类型: Case分红不一样的类型,针对不一样的Case类型,不一样的case场景咱们可能有不一样的Case的处理方式。 好比询问价格配置等其余的问题,能够维护一批售前服务的人员进行跟踪处理case,这种也能够有机会转成 Lead / Opportunity。针对产品问题相关的问题,须要找一批专业售后服务的人员进行跟踪处理case。固然分类方式不惟一,咱们也能够根据产品进行分类,这个不一样的公司不一样的业务能够设置不一样的分类方式。 Case 类型在Salesforce中使用标准字段 Type进行维护,类型为Picklist.blog

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

相关文章
相关标签/搜索