全方位渠道路由可以根据团队成员的空闲状态和工作量,将来自电邮(包括网络表格、协作快捷对话和 API)、通话和消息传送的新建和已开启工单定向给专员。在 Growth 及更高服务模式中,可根据违反 Service Level Agreement (SLA)(服务级别协议)时间转接工单。在 Professional 及更高版本的服务模式中,也可以根据优先级和技能转接工单。
使用全方位渠道路由意味着专员也可以面向所有渠道设置单一的统一状态,确保将重要工单分配给最有空处理工单的专员。这种方式具有以下优势:
- 专员可以更快回复工单
- 可以优先处理来自高价值客户的工作,包括通话
- 自动分配工单给专员,无需查找专员
- 专员无法按喜好挑选要处理的工单
- 专员可以一并处理多个工单渠道
- 可以根据来电人的国家/地区代码或其他属性将通话转接给特定专员组
您可以使用工作量规则限制一次分配给专员的工作量。但是,无论这些规则如何设置,专员都可以根据需要为自己分配超出这些限制的工作(请参阅创建工作量规则以平衡专员工作量)。
通过全方位渠道路由,专员可以为 Support、Talk 和消息传送设置单一的统一状态,而不必按渠道单独设置状态。在 Professional 及更高版本的服务模式中,管理员还可以自定义一些状态,例如“外出吃午饭”或“正在开会”。这有助于您根据专员状态和工作量决定如何转接工作项目(通话、工单和消息)。请参阅添加统一专员状态。
本文章包含以下部分:
全方位渠道路由的要求和限制
要求
- 必须激活专员工作区。
- 如果您的帐户订阅了 Chat,还必须激活原生消息传送或 Sunshine Conversations。
- 必须激活消息传送才能在使用实时在线交谈时启用全方位渠道路由。迁移到消息传送和全方位渠道路由的帐户可获得有限的 Chat 支持。
限制
具有统一专员状态的全方位渠道路由当前有以下限制:
- 如果您在使用部门空间(也称为按品牌限制专员的工单访问权限),不建议启用全方位渠道路由。这样做可能导致路由问题。请参阅通过全方位渠道路由使用部门空间(不推荐)。
- 要激活全方位渠道路由,仅使用实时在线交谈是不够的,还必须激活消息传送。
- 激活全方位渠道路由时,专员状态一开始自动设置为离线,之后系统会提示专员设置自己的状态。
- 全方位渠道路由只会路由状态为新建或已开启的工单。
- 不支持消息传送的广播和混合模式。
- 使用统一专员状态时,营业时间不会自动设置专员状态。
- 低权限专员不能被分配工单,也不能设置状态。
- 不支持通过 Talk 面板、移动应用或 Talk API 更改 Talk 专员状态。利用 Talk API 更改专员状态的整合也可能受到影响。
- 使用自定义队列时,通过自定义队列转接的工作将优先于通过标准队列转接的所有工作,无论工单优先级如何。
- 营业时间内接到的所有电话一进入队列,系统就会创建工单。仅当通话处于活跃状态时,工单才会路由给专员。已放弃的通话和超过最大队列等待时间的通话将被视为非活跃的,因此不会由全方位渠道路由转接。营业时间内接到的电话的工单渠道为呼入电话,无论是其已接听还是转到语音信箱。
营业时间外接到的电话将直接转到语音信箱,其工单渠道为语音信箱。由语音信箱生成的工单无法通过全方位渠道路由进行路由。对于转到语音信箱的通话工单,无论何时收到,都有一个以“语音信箱来自”开头的标题。
- “为已放弃通话创建工单”设置不再可用。提示:您可以创建工作流程来自动关闭为已放弃通话创建的工单。
- 如果已启用通话转接,且专员状态由于专员断开连接而自动设置为离线,则拨打给专员的电话将不再转接到专员的设备。
- 在 Talk 中使用优先电话号码时,引用优先线路的来电将首先分配给专员。然后,系统会根据关联工单的优先级和时间戳将通话分配给专员。与优先级线路上的通话关联的工单的优先级为高。
- 不支持 Talk Partner Edition。在 Talk Partner Edition 中转接通话的方式取决于所用整合的类型。
- 当向专员提供消息传送对话(有时是实时在线交谈)时,每张工单仅记录 20 次提供给活动日志的对话。全方位渠道路由将根据需要继续提供超过 20 次的工单,直到专员接受工单,但前 20 次之后提供的任何对话都不会记录在工单活动日志中。
- 全方位渠道路由不会重新分配已分配给专员的 Talk 工单,即使该工单变为未分配或被分配回组也是如此。对于电邮和消息传送渠道,工单重新分配取决于服务模式和路由配置。在 Team 和 Growth 服务模式中,电邮和消息传送工单可通过标准全方位渠道路由队列进行重新分配,但无法重新进入自定义队列。在 Professional 及更高服务模式中,您可以选择通过自定义队列重新分配电邮和消息传送工单,或依靠标准队列进行重新分配。
- 如果您使用工单触发器将通话工单分配到组,当专员使用 Talk 中的组转接功能时,会导致工单触发器触发,并将专员的组分配恢复为触发器的组分配。要避免这种情况,您可以配置分配组通话工单的工单触发器,在其中添加工单 | 是 |创建条件(表示仅对新建工单触发,而不会对组转接等更新触发)或工单 > 评论文本 | 不含以下字符串 | 通话已转接(表示仅对未转接的工单触发)。
全方位渠道路由的工作方式
使用全方位渠道路由时,系统收到所有工作渠道(包括来电)时会立即生成工单,使您可以对其运行触发器。简而言之,工作渠道被标记为电邮(包括从电邮、网络表格、协作快捷对话和 API 生成的工单)、消息传送(有时包括来自 Chat 的工单)和 Talk。全方位渠道路由会根据工单收到的原始渠道对工单进行分类,即使在解决工单的过程中使用了其他渠道也是如此。
当工单可以路由时,全方位渠道路由会尝试将其分配给首个符合条件的空闲专员。如果当时没有符合条件的专员有空,工单将插入队列,并根据以下条件进行路由:
- 队列:这是由工单插入到的全方位渠道路由队列定义的。全方位渠道路由使用一个或多个队列对工单进行排序并分配给专员:单个标准全方位渠道路由队列(默认)或自定义全方位渠道路由队列。队列分配决定了哪些专员组有资格被分配哪张工单。如果您没有使用自定义队列,所有工单都将插入标准全方位渠道路由队列。
- 空闲状态:这取决于专员跨渠道设置的统一状态。
- 每个工作渠道的工作量:您可以设定每个渠道的最大工作量,以及工单路由条件。
- 分配方式:这是由路由配置中的分配方式定义的,适用于所有渠道和队列。
- 技能:这取决于分配给专员的技能和工单,适用于所有渠道。
然后,系统通过触发器将工单分配给组,分配工单优先级,并为工单添加标签。对工单运行触发器后,系统会评估自定义全方位渠道路由队列,并将工单插入到其满足条件的第一个队列中。使用标准全方位渠道路由队列时,消息传送对话和通话一收到就会加入队列,但电邮工单必须添加路由标签才能进入队列。标准队列中的工单根据工单被分配的组来识别符合条件的专员。如果您创建了自定义全方位渠道路由队列,则电邮工单的处理方式与消息传送对话和电话相同,收到后立即进行评估并匹配到队列,无论是否有路由标签。如果工单不满足任何自定义队列的条件,将插入标准全方位渠道路由队列,并转接到工单所分配组中的专员。
系统将工单分配给专员后,会将其从全方位渠道路由队列中移除。
下表显示了将工单转接给专员的顺序:
服务模式 | 转接工单的顺序 |
---|---|
Suite Team |
队列中最早符合转接条件的工单将最先转接。 |
Suite Growth 及更高服务模式 | 管理员可以配置是先转接队列中可转接时间戳最早的工单,还是先转接最先违反 Service Level Agreement (SLA)(服务级别协议)的工单。 |
Suite Professional 及更高服务模式 |
管理员可以配置是先转接优先级最高且可转接时间戳最早的工单,还是先转接最先违反 Service Level Agreement (SLA)(服务级别协议)的工单。 尽管技能不影响工单在队列中的顺序,但可能导致工单留在队列中,等待具有相应技能的专员处理,而优先级较低和时间戳较新的工单先被分配。 |
当工单在队列中比较靠前时,系统将根据以下情况将其分配给专员:
- 工单的组或队列的组:
- 如果您不使用自定义队列,则必须将工单分配给组,才能使用全方位渠道路由进行路由。
- 使用自定义队列可以通过全方位渠道路由将工作路由到多个专员组。队列中的工单将路由到队列的组,而忽略工单的已分配组。
- 使用自定义队列时,工作将首先分配给主要组中的专员。如果当工单到达队列的最前面时这些组中没有空闲专员,全方位渠道路由将在辅助或“后备”组中查找空闲专员。
- 如果专员可以接收来自多个队列的工作,全方位渠道路由会先分配优先级最高的队列中的工作。
- 如果工单与自定义队列不匹配,将插入标准全方位渠道路由队列,并根据分配给工单的组转接给专员。对于来自所有渠道不满足自定义队列条件的工单,必须将其分配到一个组,以便通过标准全方位渠道路由队列转接。此外,不满足任何自定义队列条件的电邮工单也必须带有自动路由标签。
请参阅了解全方位渠道路由队列。
- 渠道中的专员状态:
- 电邮工单:专员必须具有在线或离开状态才能接收电邮工单。
- 消息传送对话:专员必须具有在线状态才能接收消息传送工单。
- 通话:专员必须处于在线状态才能接收来电工单。
当专员的空闲时间超过空闲状态阈值时,其状态将自动设置为离线或离开(由管理员定义)。此外,如果专员忘记将其状态设置为离线,当系统检测到以下事件时,专员状态将自动设置为离线:
- 专员未退出即关闭专员工作区(通过关闭其计算机或浏览器窗口,或使其计算机进入睡眠状态)
- 由于网络中断,专员的连接丢失
- 分配方式:
-
最大空闲工作量:标准的全方位渠道路由配置会将工作分配给渠道中空闲工作量最多的专员。
- 专员必须有空闲工作量才有资格通过全渠道路由接收工作。空闲工作量是指被分配的已开启工单数量少于该渠道的最大工作量。请参阅创建工作量规则以平衡专员工作量。
- 如果相关渠道中有多个专员具有合格状态和空闲工作量,则工单将分配给空闲工作量最高的专员。
- 如果相关渠道中有多个专员具有合格状态和相同空闲工作量,则工单将分配给在相关渠道未被分配工单时间最长的专员。全方位渠道路由将重新开启的工单视为分配活动。
- 专员必须有空闲工作量才能被分配非活跃的消息传送工单(超过 10 分钟没有回复)。非活跃的消息传送工单是否计入专员的工作量取决于路由配置。
- 循环:将工作分配给该渠道未分配工作时间最长的空闲专员。专员还必须有空闲工作量才能分配工作。
-
最大空闲工作量:标准的全方位渠道路由配置会将工作分配给渠道中空闲工作量最多的专员。
- 专员的技能:
- 专员不仅要具有合格的状态和空闲工作量,还必须具有与工单匹配的技能。
- 如果您配置了技能超时,如果在工单到达队列的最前端后,具有所有相应技能的专员在指定的时间段内没空,则分配工单时将不考虑可选技能。如果未配置技能超时,则所有技能都将被视为必要,且工单将留在队列中,直至具有相应技能的专员有空为止,或来电将留在队列中并在达到最长等待时间后转到语音信箱。请参阅在全方位渠道路由中使用技能。
全方位渠道路由场景示例如下:
- 重要 VIP 终端用户有一个紧急问题需要解决。
- 他们使用电邮渠道提交工单。
- 帐户管理员已为帐户设置了一个触发器,以便为工单添加自动路由标签,然后分配组、优先级和技能。
- 触发器被触发后,系统会将终端用户的工单与全方位渠道路由队列进行匹配,并根据工单的紧急优先级及其符合路由条件的时间戳插入工单。
- 全方位渠道路由现在可以根据专员的技能、状态和工作量评估工单。
- 路由系统首先了解到有三名专员有空。
- 其次,它识别出有两个专员具有工单所需的技能(德语)。
- 最后,它会确定哪个专员有更多空闲时间处理电邮,然后将工单分配给此专员。
在全方位渠道路由中重新分配消息和通话
消息传送对话和通话需要及时回复。因此,全方位渠道路由对二者都有特殊的重新分配逻辑。有关工单如何进入和离开队列以通过全方位渠道路由进行路由的更多信息,请参阅了解全方位渠道路由如何在队列中对工单进行排序。
重新分配消息传送对话和在线交谈
使用重新分配计时功能,如果原始专员未在特定时间阈值内接受工作,系统可以将消息或在线交谈重新分配给组内其他专员。默认阈值是 30 秒。在 Enterprise 及以上版本中,该阈值可以自定义。
在设置过程中必须打开重新分配计时设置,以便在专员未在指定时间内接收消息时自动重新分配消息。如果该设置未启用,路由引擎将一直尝试向同一专员分配消息。
重新分配来电
专员可以选择接听或拒接提供给其的来电。如果专员拒接或未在 30 秒内接听来电,该来电将返回队列,并分配给其他空闲专员。该来电将继续以循环方式提供给空闲专员,直至超过最大队列等待时间。在对通话使用根据技能转发时,您可以利用技能超时设置,根据需要将电话“转移”给没有匹配技能的专员;您也可以使用带有主要组和次要组的自定义队列来完成这种“呼叫转移”行为。
- 自创建后的小时数 > (日历)小于 > 1
- 状态 > 小于 > 已解决
- 渠道 > 是 > 通话(呼入)
通话结束后,通话生成的工单将从全方位渠道路由队列中移除。如果专员需要在通话结束后向工单添加更多信息,则必须通过搜索或使用视图手动查找工单。
功能概要
全方位渠道路由范围很广。以下简要介绍了其特性和功能。
全方位渠道路由支持的渠道
概括地说,全方位渠道路由可用于转接来自电邮、消息传送或呼叫的工单。但在业务规则中,这些工单类别又被划分为不同via
类型。下表列出了显示在管理中心业务规则条件中的受支持类型(称为渠道)。
- 电邮
- 网络表格
- Web 服务 (API)
- 已关闭的工单
- 工单共用
- Facebook 帖子
- X(以前称为 Twitter)
- Web Widget
- 移动 SDK
- 协作快捷对话
- 合并
- 旧版渠道框架 (any_channel)
- 短信(通过 Talk)
- 原生消息传送
- LINE
- 短信(仅通过 Sunshine Conversations)
- Facebook Messenger
- Telegram
- X(以前称为 Twitter)私信
- 微信
- Google RCS
- Apple Messages for Business
- Google Business Messages
- KakaoTalk
- Instagram Direct Messenger
- Sunshine Conversations API
- 在线交谈(仅在某些情况下受支持)
- (来)电
- (去)电
按服务模式查看功能概要
全方位渠道路由功能的可用性因服务模式级别而异。下表适用于 Zendesk Suite 服务模式级别,或任何单独产品的服务模式级别:
Team | Growth | Professional | Enterprise |
---|---|---|---|
转接电邮、消息传送和来电工单 | 转接电邮、消息传送和来电工单 | 转接电邮、消息传送和来电工单 | 转接电邮、消息传送和来电工单 |
根据工作量和专员状态转接 | 根据工作量和专员状态转接 | 根据工作量、专员状态、技能和队列转接 | 根据工作量、专员状态、技能和队列转接 |
默认统一专员状态 | 默认统一专员状态 | 默认和自定义统一专员状态 | 默认和自定义统一专员状态 |
供专员处理消息传送和通话的专注模式 | 供专员处理消息传送和通话的专注模式 | 供专员处理消息传送和通话的专注模式 | 供专员处理消息传送和通话的专注模式 |
计算专员工作量时包括或排除非活跃的消息传送工单 | 计算专员工作量时包括或排除非活跃的消息传送工单 | 计算专员工作量时包括或排除非活跃的消息传送工单 | 计算专员工作量时包括或排除非活跃的消息传送工单 |
消息传送工单的自动分配 | 消息传送工单的自动分配 | 消息传送工单的自动分配 | 消息传送工单的自动分配 |
根据空闲工作量或循环进行分配 | 根据空闲工作量或循环进行分配 | 根据空闲工作量或循环进行分配 | 根据空闲工作量或循环进行分配 |
消息重新分配 | 消息重新分配 | 消息重新分配 | 可自定义的重新分配时间 |
按最早违反 SLA 或最高优先级的顺序转接 | 按最早违反 SLA 或最高优先级的顺序转接 | 按最早违反 SLA 或最高优先级的顺序转接 | |
当被分配的专员没空时,重新分配重新开启的工单 | 当被分配的专员没空时,重新分配重新开启的工单 | ||
自定义全方位渠道路由队列 | 自定义全方位渠道路由队列 | ||
最多 5 个自定义状态 | 最多 100 个自定义状态 |
相关文章
请参阅以下文章了解更多信息,以便设置和运行全方位渠道路由和专员状态:
267 条评论
Barry Neary
Hi 1265426639690
When it comes to support tickets (inc email and webform), you choose to only have some of them routed by using the auto routing tag
For messages, all of them will be assigned via omnichannel routing if you switch it on.
0
Elżbieta Petryka
Hi Can we use omnichanell routing only for specific group of tickets (one product or one brand) or do we have to turn it on for the whole Zendesk instance at once?
0
Barry Neary
HI 1265343108529
The only way currently to do this is to leveage the Zendesk Agent Status API to make changes to an agent status and write some type of script to call these APIs. We are currently developing a bulk edit status capabilty that you can change several agents status with one call. (cc: 1263082181109 )
0
Nico V
Hi,
not sure if this is the appropriate area but cannot find reference.
The agent status can be online, away, offline (for chats and for calls).
Is there a way to change the status from “online” to “offline”, etc. time-based? i.e. officer A is online from 09:00 to 13:00, the system automatically turns him “online” at 09:00 and o"offline" at 13:00?
Most likely someone has already replied and the answer yes, just, I cannot find how to do it.
Thank you!
Nico
0
Lara McCaleb
Hoping for some help. We have just implemented omni-channel routing of email/web/api tickets. I have some support agents who work other specialized tickets that are created via API and are assigned with a separate group. We have an automation that reopens those tickets based on the due date for followup, and those tickets are then counting toward their overall capacity to take email/web tickets.
Separately, we have an agent that manages feature requests and will have a backlog of tickets in the feature request group that are open, waiting to work, but are low priority. Those now count toward this agent's capacity when they are low priority.
It seems that need a way to customize capacity based on ticket group or omit tickets from certain groups from applying to capacity. Anyone have ideas?
1
Zach Gilbert
Thanks, 1263082080589 - We've turned off auto reassignment of chat until that feature is implemented.
0
Barry Neary
Hi 1263213544769
This is on the roadmap for early 2025
0
James Molina
Many clients need the ability to change a messaging ticket from a messaging channel to an email channel since inactive messages are treated like emails after an initial messaging conversation. This fixes many of the OCR issues related to routing inactive messages. Currently, if you count inactive messages, they are prioritized over live messages. If you don't don't count inactive messages, no channel capacity is accounted for then the first agent can get dumped all the messages. Separate queues then prevents emails from taking priority over inactive messages.
0
Barry Neary
Hi 4532417749018
Once a messaging session has been ended by an agent, the message is no longer routable - i.e. if you remove the assignee it wont be automatically be assigned to another agent in the group
We do have plans to allow these messaging tickets to be transformed into email tickets and they would be routable
Barry
0
Zach Gilbert
1263082080589 this is the same comment that was left in the other group that you replied to this morning where the agent ends the messaging conversation, then emails the customer on the same ticket, the agent goes offline, and then the customer emails back on that ticket. SInce we have the setting to re-assign chats when an agent is offline, the agent is stripped from the ticket, but the ticket is not being offered to any other agents like a messaging ticket would. It sits in the cue as an unassigned messaging conversation.
0
登录再写评论。