案例是 Salesforce 中管理事件的标准对象。将案例分配给具有适当技能和能力的用户可以直接缩短查询解决时间,进而提高客户满意度。 Salesforce 提供了各种开箱即用的功能来分配案例的所有权(= 根据某些规则更新所有者)。本文组织了这些标准功能的基本用法和注意事项。

概括

您可以主要使用以下标准函数来分配案例:这些可以单独使用或组合使用。

用于分配的函数 手动自动 主题 主要使用场景
① 列表视图 手动的 新病例和现有病例 需要人工判断,我想手动决定谁负责
② 分配规则 自动的 主要是新病例 我想根据字段值分配给正确的队列或用户,主要是在 Web-to-Case 或 Email-to-Case
③ 升级规则 自动的 现有案例 我想根据经过时间等标准更新现有案例的分配
④ 全渠道 自动的 主要是新病例 ・我想根据用户的负荷自动确定负责人,例如当前负责的案件数量和正在处理的其他渠道的工作,以及案件的项目价值
⑤自动化流程(Flow/Apex触发) 自动的 新病例和现有病例 分配案例有复杂的业务逻辑

一般来说,定义一个生命周期,首先将案例分配给队列,然后分配给适当的用户或由用户自己获取,然后完成关闭案例的工作(例如回复电子邮件)。有很多事情。

Service Cloud ケース割り当ての基礎と実践

以上只是主要使用场景中的功能使用说明,并不代表每个功能只能在图中所示的时机使用。此外,本文不涉及使用流或 Apex 触发器直接设置案例所有者等用例。

分配函数比较

1.列表视图

您可以使用默认的更改所有者操作或使用您创建的快速操作从列表视图中批量更改所有者。此外,如果列表视图的过滤器将所有者过滤到特定队列,并且列表视图的搜索布局有一个接受按钮,则列表视图将显示接受按钮。单击此按钮会将所有者更改为该用户。

Service Cloud ケース割り当ての基礎と実践

对于小批量,此功能可以让SV定期分配新创建的案例,运营商可以专注于自己拥有的案例的列表视图,从而有效地管理案例。我们可以回应

注意事项

  • 我们建议使用视图、仪表板等,以便 SV 和管理员定期查看分配和案例的状态。例如,操作员可能要到下一个工作日才能结束他或她的案件,并且操作员不在下一个工作日轮班。此时,最好准备一个操作流程,例如将当天无法结案的案件退回到队列中。
    • 同样,如果案例的所有者仍然是特定用户并且移动或离开公司,并且用户被停用或离开队列中的公共组,则案例的可见性将受到影响。它可能会出来,所以你需要考虑一下。 (特别是如果案例共享设置是私人的)

2.分配规则

分配规则通常应用于自动创建的案例,例如网络转个案和电子邮件转个案。
,根据案例或案例引用的对象上的字段值自动将所有者设置为队列或用户。有使用方法,比如根据客户属性自动分配负责人,或者根据案件类型分配负责人。

Service Cloud ケース割り当ての基礎と実践

要触发手动创建/编辑案例的分配规则,请在页面布局属性中选中 [ケース割り当て] チェックボックス 編集ページを表示有効な割り当てルールを使用して割り当てる 复选框现在将出现在任何新操作或编辑操作的页脚中。选中此项并保存以激活分配规则。

Service Cloud ケース割り当ての基礎と実践

注意事项

  • 内联编辑无法触发分配规则。 (参考:IdeaExchange - 分配规则不适用于内联编辑)
  • 默认情况下,在 Apex 中创建/更新的案例不会触发分配规则。在 DML 之前设置 DMLOptions.AssignmentRuleHeader。 (参考:Apex 参考指南)
  • 如果需要考虑负载平衡,请考虑使用下面描述的全渠道路由。

3. 升级规则

升级规则是一项功能,可根据自创建或上次更新案例以来的时间以及字段值自动将所有者设置为队列或用户。分配规则加上经过的时间最好理解这一点权利里程碑功能也可用于自动处理与已用时间相关的案例,但需要管理许多对象和设置,这有点麻烦。如果您不需要严格的 SLA 管理并且只想按时间重新分配所有者,则升级规则很好。

升级规则特有的功能是您可以使用标准营业时间设置,例如“如果在开放后 2 个工作日内未关闭,则将所有者更改为 SV 的队列”。

注意事项

  • 关于升级给客户如果需要通知,升级规则无法处理。考虑使用基于时间的记录触发自动化(例如 Flow and Process Builder)和里程碑操作。
  • 如果升级目标是用户,最好考虑用户不可用时的操作流程。
  • 虽然与此功能没有直接关系,但最好考虑升级案例的整体 KPI 和跟踪方法。这超出了本文的范围,但如果您想单独跟踪升级案例的指标或拥有独立的可见性设置,而不是更改同一案例的所有者,您可以使用单独的记录(例如子案例)也可用.

4. 全渠道

全渠道功能不仅可以自动分发案例,还可以根据优先级和操作员工作量等规则自动分发从聊天和自定义对象等各种渠道生成的记录。在这里,我们将介绍以案例分配为重点的必要设置。

Service Cloud ケース割り当ての基礎と実践

如上图所示,案例被转移到实用工具栏中的全渠道组件,如果您接受(=按下复选按钮)所有者将更改为您自己。在案例到达操作员之前,有三种主要的转移方法(路由)。基于队列的路由、基于技能的路由和全渠道流量路由。

工作量的概念

让我们在设置路由之前检查重要的工作负载设置。路由设置在 中,设定平均分配给操作员的规则,但这里的标准是称为“工作项大小”的设定值,它决定了工作量和工作比例。例如,如果一个队列有 A 先生正在处理 4 个案件,而 B 先生正在处理任何案件,那么分配到该队列的下一个新案件将转移给更忙的 B 先生。这是很自然的成为对于像聊天这样的实时对象,工作量是打开标签的数量(≒同时进行的聊天数量),但对于像案例这样的非实时对象,打开标签的数量往往,数字与您当前工作的实际数量不对应。此时,在全渠道设置中,点击启用基于情境的工作负载模型] 例如,您可以将未结案件的数量视为您的业务量。

基于队列的路由

这是最简单的路由。如果支持案例的队列引用路由设置,当案例所有者更改为该队列时,是否会根据路由设置打开最少的案例(=打开计数)?,将案例转发给可以处理的操作员大多数情况(=最大容量)。

基于技能的路由

通过映射代理所拥有的案例和技能的项目值,可以实现比基于队列更精细的案例转移。此映射在基于技能的路由规则中完成。以下示例将案例原因为“计费”的记录路由到“退货和退款流程”中技能级别为 5 或更高的操作员。

Service Cloud ケース割り当ての基礎と実践

请注意,即使使用此设置,创建案例时也不会将案例直接发送给操作员。基于技能的路由仍然需要队列和路由设置。基于技能的路由最好理解为基于队列的路由,对分配操作员有更多限制。如果您想将案例直接分配给特定的操作员,请实施后续的全渠道流程。

使用全渠道流程进行路由

借助全方位流程,您可以使用任何逻辑路由案例。例如,如下所示,您可以实现一个流程,将案例优先分配给之前为同一客户处理过案例的操作员。有关设置的详细信息,《调用全渠道流传输非实时对象》请参阅。

Service Cloud ケース割り当ての基礎と実践

案例等非实时对象不会自动调用全方位流程,因此不要忘记调用您已实施的全方位流程,例如案例上的记录触发流程。

额外版

循环分配

帮助提供了使用引导对象上的公式字段进行循环分配的示例实现它一直。对于这种情况,类似的实现是可能的。

综上所述

实际设置没有绝对正确的答案。所需设置因组织规模、业务流程和 KPI 的不同而有很大差异。重要的是使用报告、全渠道监管等,可视化分配的成本和结果,并进行持续改进。


原创声明:本文系作者授权爱码网发表,未经许可,不得转载;

原文地址:https://www.likecs.com/show-308623267.html

相关文章: