Recent searches


No recent searches

Routing automatically triaged tickets using omnichannel routing



image avatar

Erin O'Callaghan

Zendesk Documentation Team

Edited Jun 21, 2024


0

4

4 comments

image avatar

Neil

Zendesk Customer Care

Hi Thomas,
 
For updating triggers in large volume, your best course of action is to do this via Update Many Triggers API.
 
Hope this helps!

0


Hello, can I get some clarification on the omnichannel routing please?

If I was to use the Omnichannel routing with skills to route messaging tickets.

I understand that in the first phase the skill routing takes place, and if no agent is available to take the ticket after the specified threshold time has passed, then the second phase starts - and the ticket goes back to the Omnichannel queue.

My question is about the the first stage (skills routing).
Let's assume I have the following 2 skills:
- skill 1
- skill 2

and 3 groups:
Group A
Group B
Group C
------
The incoming messaging ticket was assigned "skill 1" and "Group B" by my triggers.... 

So, in the first phase or routing (skill based), would this be assigned to only agents with "skill 1" that are included in Group B, or to all agents in all groups providing they have "skill 1" ????

And then, if no one was available after the threshold time, I understand that 2nd phase would take place - so that this ticket would be routed to any agent from "Group B" - regardless of their skills, but who are online and at free capacity?
----------
Please may I have some more clarification here? 
Many thanks
Regards

0


image avatar

David

Zendesk Customer Care

Hi Jakub, 

With Omnichannel Routing (with skills-based routing in conjunction with groups) the process aims to connect customers with the most appropriate agents based on the skills required to handle the query and the organizational structure defined by groups.

Here's how it works

  1. Skills-Based Routing: This is the initial step where tickets are routed to agents based on the Skills assigned to those tickets. Skills are attributes that you define and assign to both tickets and agents to indicate what types of issues the agents are capable of handling. When a ticket comes in, the system looks for agents with matching skills.

  2. Group Consideration: Alongside Skills, Groups organize agents into teams. Groups can reflect different departments, product areas, or any other division within the company that delineates the responsibilities of agents. When setting up skills-based routing, you can also specify group assignments. This means that if a ticket is assigned a certain skill and a group, the system ideally looks for an agent within the specified group who has the required skill.

    • To your specific question: If an incoming messaging ticket is assigned "skill 1" and is also assigned to "Group B", the system first tries to find an agent who has "skill 1" within "Group B". The intent of this approach is to combine the specificity of skills with the organizational structure provided by groups to ensure that the ticket is handled by someone who is not only capable of resolving the issue but is also part of the relevant team or department.
  3. Fallback Mechanism: If no agents with the required skill within the specified group are available within the threshold time, the ticket can then be routed more broadly. Depending on the settings, this could mean routing to:

    • Any agent within the specified group, regardless of their skills, who is available.
    • Expanding the search beyond the group to find any available agent with the required skill across the organization.
    • Eventually, if still unassigned due to unavailability, the ticket might go back into a general queue to await the next available agent, potentially ignoring both skill and group preferences to ensure the ticket is addressed.

Hope that helps out!

2


Hi,

 

We have enabled omni-channel routing and testing it in conjunction with skills based routing and Advanced AI (using intent in the conditions, as example above). In this trigger, we have also added the action to email the Requester and CCs to confirm we have received their request, which is bespoke to the specific intent. 


We also have a standard “Notify requester of received request” trigger, which we don't want to send at the same time, as the requester would then receive 2 notifications. 

 

To avoid that, we added the tag ‘autotriaged’ that is added on the omni/intent trigger, and also added to the standard trigger to NOT fire if this tag is present.

 

However, during testing we discovered that intent is not added to the ticket until the first round of triggers have fired, therefore we can't avoid both triggers firing. 

 

Is there a way to avoid this? 

 

Thanks

0


Please sign in to leave a comment.