Omnichannel routing assigns new and open tickets from email (including web form, side conversations, and API), calls, and messaging directly to agents based on agent availability and capacity and, on some plans, can be configured to also factor in service level agreement (SLA) targets, ticket priority, and skills.
The standard omnichannel routing configuration directs all eligible tickets into a single queue, assigning work to agents based on the ticket's assigned group. If a single queue is insufficient for your use case, you can create additional custom omnichannel routing queues. You must have the Agent Workspace to use omnichannel routing.
Essential facts about omnichannel routing queues
- The omnichannel routing configuration settings apply to all of your queues.
- When a new ticket is created, ticket triggers fire first. Then omnichannel routing immediately attempts to assign it to an agent. If no agent is available to take it, the ticket is added to the appropriate queue.
- There are two types of queues in omnichannel routing:
- Standard omnichannel routing queue: This is the default queue used by omnichannel routing when you turn on omnichannel routing and haven't created custom queues or when tickets don't meet the conditions of your custom queues but are otherwise eligible to be routed by omnichannel routing. Sometimes this is referred to as group-based omnichannel routing because tickets routed through the standard queue go to agents in the group specified in the ticket's group field. The standard queue isn't listed on the Queues page in Admin Center.
- Custom omnichannel routing queues: These are custom queues defined by admins. When using custom queues, tickets are inserted into the first queue they match the conditions for. Custom queues can route tickets to multiple primary and secondary groups. If a ticket is routed through a custom queue, omnichannel routing ignores the ticket's group field and uses the queue's primary and secondary groups.
- The auto-routing tag isn't used by custom queues. Regardless of the presence of the auto-routing tag, all email tickets, messaging conversations, and calls are automatically evaluated for matches to custom queues. However, email tickets that don't match any custom queues must have the auto-routing tag if you want them to be routed through the standard omnichannel routing queue.
- Omnichannel routing matches tickets to queues in the order the queues appear on the Queues page. Tickets are added to the first queue they meet the conditions for.
- Tickets that don't match the conditions for any of your custom queues are inserted into the standard omnichannel routing queue. However, omnichannel routing prioritizes all tickets routed through custom queues over those routed through the standard omnichannel routing queue, regardless of the ticket's priority.
- The way your order tickets, whether by priority and timestamp or time to SLA breach, applies to both the standard omnichannel routing queue and custom queues.
- When an agent is eligible to receive work from multiple queues, tickets from the queue with the higher priority are assigned before tickets from a queue with a lower priority. See Creating custom omnichannel routing queues.
- After a ticket has been assigned to an agent, it leaves the queue.
- Talk tickets can’t be reassigned by omnichannel routing. Email and messaging
tickets can be reassigned, but your routing configuration determines whether
reassignments occur through custom queues or the standard queue.
- On Team and Growth plans, tickets can't re-enter a custom queue after being assigned to an agent. However, if a ticket becomes eligible for re-routing, it's inserted into the standard omnichannel routing queue based on its routing-eligibility timestamp and routed based on the ticket's assigned group.
- On Professional plans and above, you can configure omnichannel routing to reassign tickets through custom queues. When configured, tickets that are reassigned back to a group after being assigned to an agent are inserted into the first matching queue. If the ticket doesn't meet the conditions for any custom queues, it's inserted into the standard omnichannel routing queue and routed based on the ticket's assigned group.
- You can report on the performance of your custom queues in Explore. See Explore recipe: Reporting on custom omnichannel queue performance.
Using custom queues with omnichannel routing
Omnichannel routing is Zendesk's most sophisticated and complete routing solution. It provides consistent routing logic across channels and considers many factors when assigning work to agents. For many use cases, the single, standard omnichannel routing queue that's activated when you turn on omnichannel routing is sufficient. When relying on the standard omnichannel routing queue, tickets must be assigned to a group to be routed to an agent with omnichannel routing, and email tickets must have the auto-routing tag. Think of this as group-based omnichannel routing.
In some cases, it's not realistic or desirable to have your tickets routed to the single group assigned to the ticket. Creating custom queues allows you to route work to multiple groups based on the queue the tickets are assigned to. Multiple queues also give you the option to define secondary or "overflow" groups that receive tickets through a queue only if all agents in the primary groups are unavailable. When you assign multiple primary and secondary groups to a queue, omnichannel routing treats all primary groups as a single pool of agents, and when necessary, expands it to include all agents in the secondary groups as well. When you use queue-based routing, omnichannel routing uses the queue's primary and secondary groups to assign the ticket to an agent, ignoring any group that might be specified on the ticket itself.
For more information, see Creating additional omnichannel routing queues.
Understanding how omnichannel routing orders tickets within queues
As soon as a ticket is eligible for routing, omnichannel routing attempts to assign it to an eligible and available agent. If it can't be assigned immediately, the ticket is inserted into a queue. There are two ways you can configure omnichannel routing to insert and order tickets within queues: ticket priority and timestamp or time to SLA breach. The standard omnichannel routing configuration uses the time at which a ticket becomes eligible for routing and, on Professional plans and above, the ticket's priority.
When a new ticket is created or updated, ticket triggers automatically fire and then omnichannel routing evaluates how to insert it into a queue to be routed to an agent. If you've created custom queues, omnichannel routing evaluates queue conditions to find a match for the ticket and then inserts it based on SLA targets or ticket priority; if a ticket doesn't match any of the custom queues, it's inserted into the standard omnichannel routing queue on the same basis. If you haven't created custom queues or a ticket doesn't meet the conditions for any of your custom queues, it's inserted into the standard omnichannel routing queue.
Ordering tickets by priority and timestamp
- Ticket eligibility for routing
- Routing eligibility timestamps
- Routing ineligibility time
- Ticket priority (Professional plans and above)
Ticket eligibility for routing
Ticket eligibility for routing by omnichannel routing depends on whether the tickets are entering the standard queue or custom queues.
- Assigned to a group
- In a status or status category of New or Open
- Unassigned
- (Email tickets only) Has the auto-routing tag
- In a status or status category of New or Open
- Unassigned
- The ticket isn't assigned to a group and doesn't match a custom queue.
- The ticket is assigned to an agent.
- The ticket has a status (or status category) of Pending, On Hold, or Solved.
- The ticket has been soft deleted.
- (Email tickets and the standard queue only) The ticket doesn't have the auto-routing tag.
Routing eligibility timestamps
- The initial eligible for routing timestamp is when a ticket becomes eligible for routing through omnichannel routing for the first time.
- A subsequent eligible for routing timestamp is when a ticket becomes eligible again for routing through omnichannel routing after having already been eligible and ineligible previously.
Routing ineligibility time
Omnichannel routing tracks the time tickets spend being ineligible for routing and uses this to determine which routing timestamp to use when inserting a ticket back into the routing queue. This is referred to as the routing ineligibility time.
Checking ticket ineligibility for routing prevents performance issues caused by tracking an ever-growing number of timestamps and accounts for decreasing priority as tickets age.
Ticket priority
On Professional plans and above, omnichannel routing automatically orders tickets based on priority first and then by their routing eligibility timestamp. This sorting method prioritizes the oldest and most important tickets.
However, if you use SLAs, ticket priority and age might not be the most important metrics to use for ordering tickets within your queues.
Ordering tickets by time to SLA breach
Ordering tickets by time to SLA breach brings your routing logic into alignment with your service commitments and can improve your ability to meet those goals.
- The method of ticket ordering you use determines the order of tickets within any given queue, but doesn't influence the priority of ticket assignment across queues. If an agent can receive work from multiple queues, tickets from the queue with the higher priority are assigned to the agent before tickets from the lower priority queue. This is true regardless of how soon tickets in the lower priority queue will breach their SLA targets. Take this into consideration when creating and ordering custom queues.
- When ordering tickets based on the time to their next SLA breach, the setting is applied only to new and reopened tickets. Tickets already in the queue when this setting is turned on remain ordered by priority and timestamp as they were before.
- Ticket ordering is based on the SLA targets as they existed when the ticket entered the queue. If SLA policies are modified before the ticket is routed to an agent, the old SLA targets are still used for the purposes of routing.
- When ordering tickets based on the time to their next SLA breach, all tickets with SLA targets are ordered ahead of tickets without SLA targets, regardless of ticket priority and timestamp. Tickets without SLA targets are ordered based on their priority and routing eligibility timestamp.
If you want to order tickets based on SLA targets, update your omnichannel routing configuration to prioritize tickets with service level agreements.
Putting it together: Ordering tickets by priority and timestamp in a queue
The standard configuration orders and assigns tickets based on the ticket's priority and routing eligibility time. Let's walk through a ticket's life cycle with the standard omnichannel routing configuration:
- On January 1, 2024, a customer sends an email, and a ticket is created at 08:30.
- The creation of the ticket causes the triggers to run and then
omnichannel routing to evaluate queues for the ticket.
- When the triggers fire, the auto-routing tag is added and the
ticket is assigned to Group 1. These ticket updates occur
one minute after the ticket was created. (08:31)
The initial eligible for routing timestamp is 2024:01:01:08:31.
- Omnichannel routing recognizes the ticket as eligible for
routing and adds it to the queue using the ticket's initial
eligible for routing timestamp to determine its
order.
- If all tickets in the queue have the same priority, tickets with timestamps before 2024:01:01:08:31 will be ahead of this ticket in the queue, and those with timestamps after that will be behind it.
- If not all tickets have the same priority, tickets with the highest priority are all added to the front of the queue in timestamp order, followed by tickets with the next highest priority in timestamp order, and so on.
- When the triggers fire, the auto-routing tag is added and the
ticket is assigned to Group 1. These ticket updates occur
one minute after the ticket was created. (08:31)
- When the ticket reaches the front of the queue, omnichannel routing
looks for an agent in Group 1 that is available and has spare capacity.
It finds an agent at 08:37 and assigns the ticket to them.
The ticket becomes ineligible for routing as soon as it's assigned to the agent. The ticket's routing ineligibility time begins at 2024:01:01:08:37.
- After three days of working on the ticket, at noon (12:00) on January 4,
2024, the agent reassigns the ticket to Group 2.
The ticket becomes eligible for routing again because the new group assignment removes the previous agent assigned to the ticket. Because the ticket's routing ineligibility time was less than 15 days, it re-enters the queue and is ordered based on its initial eligible for routing timestamp (2024:01:01:08:31).
Assuming equal priority, this ticket is inserted ahead of all tickets that became eligible for routing after this ticket was initially added to the queue.
- Omnichannel routing assigns the ticket to an agent in Group 2 a few minutes after it's added to the queue.
- After 20 days of being assigned to the agent in Group 2, the agent
decides to reassign it to another group to which they don't belong.
(Timestamp: 2024:01:24:10:45)
Because the ticket's routing ineligibility time exceeded 15 days, the ticket is placed in the queue based on its priority and latest subsequent eligible for routing timestamp of 2024:01:24:10:45. Tickets of equal or greater priority that became eligible for routing prior to January 24, 2024, at 10:45 am and haven't had an ineligibility period of 15 days are ahead of this ticket in the queue.
- When the ticket reaches the front of the queue, omnichannel routing assigns it to another agent. This agent works on the ticket and changes the status to Solved.
107 comments
Barry Neary
I have DM you about thi
0
Kyle K.
Is it possible to use this to set up an overflow system for calls?
With omnichannel the feature to add secondary/backup groups via IVR doesn't work, I was hoping this feature would give us something equivalent but it doesn't seem to work when we try to set it up on our instance. I know the article mentions call tickets but it doesn't seem to care about the primary group's availability- the primary group is getting the live calls even if offline.
0
Barry Neary
Hi Kyle K.
Yes, setting up a secondary group in a queue should mean that if a call goes into that queue and the primary group is not available an available agent in the secondary group should be routed the call.
If not, could you raise a ticket with Zendesk support?
0
Barry Neary
Hi Ahmed
If in your example Queue1 has higher priority than Queue2 , then that will take precedence, i.e. a low priority ticket in Queue1 will be assigned before a urgent priority ticket in queue2.
By default you would need to add the auto routing tag, so that if its unassigned it will be automatically routed to another agent. However we have the option that we can have unassigned tickets flow back through queues if you wish (thats a change we make on the backend for customers who want this, we are working to make that a front end configurable option)
It would only get a new routing eligibility time if it has been assigned to the agent for more than 7 days (I beleive). Up to that point, if it is reassigned back into a queue then the system will use the original date created and hence the ticket should be placed towards the top of the queue as this date will likely be older
0
Thomas D'Hoe
Related to: https://support.zendesk.com/hc/en-us/articles/6712096584090/comments/6960387626010
What can happen with handling priorities this way (FIFO) is that you may not handle tickets according to SLA breach.
See this view (screenshot below) - which is based on one of our Queues (conditions view same as that of the queue) sorted by Tickets Request date & grouped by Prio.
The queue will assign these tickets to an agent (routing engine) and start at the top of the list. This means that ticket #1131236 with prio high and a sla breach of -38days will have to wait until all Urgent tickets are handled (and no urgent ticket may arrive before the ticket with prio high will be assigned by the routing engine)
A possible workaround is to change tickets that are close to being breached from prio (putting them higher in the queue) or depending on the business give these SLA breach tickets a TAG and create a prio 1 queue for handling SLA breach tickets. 🤔
0
Barry Neary
HI Thomas D'Hoe
We are planning to support ordering within queue by SLA natively
Barry
0
Georgi Panayotov
Hi Barry Neary
We would like to explore the following scenarios.
Multiple agents are part of multiple groups.
For some of the groups we would like to utilize the OCR Queues so tickets should be auto-assigned based on priority (it's a custom field and we have triggers that set the relevant priority).
For some of the groups we don't want to have the auto-assignment but agents should manually pick it up at their discretion regardless of the agent's status.
For tickets routed by OCR Queues, we want to enable the reassignment so reopened tickets should go back to the OCR Queue following it's logic if the agent is not online.
How can we achieve it?
1
Barry Neary
Hi Georgi Panayotov
For email tickets that you do not want to be auto assigned, you could :
1) Have no queue setup, so these tickets dont get assigned to any queue. For example, for tickets you do want to auto assign, add the auto route tag and have that as a condition for a queue. Email tickets that dont have the auto route tag will not go into any queues and not be auto assigned. They will appear in views as normal
For messaging tickets:
1) Have a queue setup for messaging tickets that you do not want to auto route, but allocate an empty group to the queue. Then setup a view so that agents can manually pick these messages from the view.
I can DM you to have your reassigned tickets go back through queue logic, its a setting on the backend at the moment
1
Georgi Panayotov
Barry Neary Yes, please DM me.
0
Leslie
Hi Barry Neary How can we do this:
"Yes, each time ticket is updated the queue conditions are checked but only if they are still in the queue. By default, once a ticket is assigned and leaves a queue, when its reassigned it does not go back through the queue logic.
However we can change this for your account so on reassignment (or unassignment) the ticket will go back through the queue logic, if you wish?"
Thank you so much!
0
Thomas D'Hoe
Hi Barry Neary , any thoughts about auto-tagging tickets when they are in a queue - and untagging if they leave a queue?
When tickets have a queue tag, it can massively improve workflows (used in triggers) and custom reporting. (building report to see only queue ticket)
1
Connor Garrett
Very big +1 to what Thomas D'Hoe recommended.
0
Daniel Codesal
Hi Barry Neary
“I can DM you to have your reassigned tickets go back through queue logic, its a setting on the backend at the moment”
Can I have your support with this setting please.
0
Thomas D'Hoe
Hi, regarding to following bullet point in the article:
Does this mean that all custom queues must be empty before tickets from the standard queue are routed? Or is a scenario possible where tickets in the custom queue are still waiting to be assigned to an agent and tickets from the standard queue are assigned because of agent availability?
A possible scenario could be that you provide a specific agent group to handle tickets from the standard omnichannel queue. If you exclude this group from in the conditions of the custom queues (i.e., there is no custom queue match and the agent group of the standard queue is not a primary or secondary custom queue group) , will the tickets from the standard queue then be allocated? Or should the custom queue(s) be empty first?
Or in other words, does it work the same like explained here?
=> When an agent is eligible to receive work from multiple queues, tickets from the queue with the higher priority value are assigned before tickets from a queue with a lower priority value. A custom queue's priority value is considered only when an agent receives work from more than one queue.
0
Richard J
Hi Barry Neary is it possible to explain a bit clearer the question asked on this page by Rashed Ripon?
Does a reopened ticket always sit in the 'default queue', therefore it is at the bottom of priority if you have other custom queues (those queues will always be above the default queue)?
Struggling to understand the routing of New + Queued versus Reopened + Routable.
0
Barry Neary
Hi Thomas D'Hoe
Lets say ticket1 is in a custom queue (which is allocated to Group A) and ticket 2 is in the standard queue and a trigger fires on ticket 2 that also assign it to group A, it is ticket1 that will be assigned first to an agent in that group, as custom queues take precdence over the standard one when it comes to routing tickets in a specific group.
If ticket 1 was in custom queue that was allocated to a different group than ticket 2 is assigned to, then the precedence issue does not come in to play.
Effectively the standard queue is given priority 101 - so whatever priority the custom queues have (1-100) they will always be higher priority. This concept of queue priority only becomes important if you have an agent or group of agents are being allocated tickets from more than one queue.
3
Johannes Garske
How does it work with skills-based routing?
We have a setup where our groups are nearly our skills, so i wonder if we also can use it with some groups-conditions.
1
Barry Neary
Hi Johannes Garske
with skills routing turned on, tickets with skills will go into the queue and be assigned to whatever groups are allocated to that queue. However within the group it will look for agents with the required skills. If it cannot find an available agent in the primary group with the skill, it will overflow to secondary group and look for an agent there. If it still cannot find an agent, ticket will remain in queue until one becomes available
1
Johannes Garske
Hey Barry Neary
thanks for the answer.
So it is first the group which is important and then the skill?
Because we cannot have SLA as a condition in the queues.
When the ticket is then in the queue it will look up for agents which are assigned to the group? How does it than match with the skills?
Or do we need to set-up the Skills with conditions (groups and skills are not available there) and not just add the assignees?
Or does the skill from the ticket is matched with the skill from the Agents automatically?
1
Thomas D'Hoe
Hi Johannes Garske ,
Yes, the latter - you assign skills to the ticket with triggers first. After going through the trigger cycle, the Omnichannel enginge will run through the omnichannel queues (top to bottom) - once there is a match , the ticket will be added to that queue (based on the conditions you have set for that queue).
Omnichannel will try to assign a ticket to an agent within the primary group(s) or secondary group(s) you have assigned to that queue. The ticket will be assigned if an agent is available (online) , has capacity and has the right skill (based on the skills added to the ticket by triggers before).
I recorded a video earlier for my team where I explain custom queues, maybe it's useful for you guys too:
- Understanding Custom Cues in Zendesk 🎥
- Understanding how ticket priority works for (Custom) Queues in Zendesk
(sorry, videos are pretty amateurish :-))
2
Johannes Garske
Thanks Thomas D'Hoe
This is so nice!
So i need to assign primary and secondary groups to a queue so that it will get assigned? When i only do one prmiary it is not assigned until an agent is available?
How does it work when an agent is in a group but it is not the primary group, does the ticket still will be assigned to that agent?
Condition is that the skill will match
Is there any chance you can share the miro-boards?
Thank you so much!
1
Thomas D'Hoe
Hi Johannes Garske ,
The tickets will be assigned to one of the agents, a primary or secondary group member for that specific queue.
Here is the Miro Board: https://miro.com/app/board/uXjVK-9tNlc=/?share_link_id=427742085841
2
Georgi Panayotov
Barry Neary Can you DM me to have reassigned tickets go back through queue logic enabled for our Sandbox, since its a setting on the backend at the moment?
0
Johannes Garske
Thank you so much Thomas D'Hoe
Could you please also enable this for us Barry Neary ?
0
Richard J
Also interested in this queue logic setting for reassigned tickets Barry Neary
But want to understand by default how a reopened + reassigned back-to-group ticket is prioritised versus a new and custom queued ticket.
0
Barry Neary
Hi Richard J
If we enable the capability so that all reassigned tickets go back through the queues, then the reassigned ticket will be put in the first queue that it matches the queues conditions. It will be ordered in the queue by ticket priority and then date created. So for example, if all the other tickets in the queue have the same priority as the reassigned ticket, then whichever ticket is oldest will be at the top of the queue.
If we dont enable the capability so that all reassigned tickets go back through the queues (i.e. the default behaviour), then if an agent reassigns a ticket to another group, it wont go back through the queue logic. In this new group, reassigned tickets will be given a lower priority versus new tickets that are being assigned to that group from queues.
1
Support Petiscope
Hi Barry Neary I am interested on having reasssigned tickets go back through queue logic. Can you assist to activate the setting on your back end
:-)
Thanks a lot
0
Layla Atayeva
Hi Barry Neary
We launched OCR 2 weeks ago, and while we have seen some really exciting improvements, I am struggling to figure out how to arrange this type of work flow :
We want phone calls to be prioritized over messaging conversations for those agents that take calls since messaging can be asynchronous where as phone call cannot. We end up in a situation where we have little to no active messages in queue, but our phone queue will sky rocket as agents are all tied up working messaging tickets. I am having a hard time achieving a balance.
I have tried changing capacity to 1 messaging conversation to those agents who take calls as well. This didn't help so I have since reverted to 2.
I thought using custom queues would help achieve this, so I created 3. priority calls > standard calls > messaging conversations in that order of priority. Agents were still being routed messages while calls were in queue.
Is there a better way to achieve what I am trying to accomplish?
0
Michael Locurcio
Hi Barry Neary - We are testing OCR in our Sandbox and might be missing something in the documentation. We use messaging, but we treat the messaging ticket the same as an email/webform. We order the “work” view by a custom field that is the support package they pay for.
How can we use OCR to route the messaging ticket like an email ticket. We have queues setup, we don't want them to jump the line, don't want them to have to be accepted or flash an accept button. We jsut want them to fall in-line with emails and get assigned as the next ticket in the queue. Is what we want to do possible with OCR? Can we point me to the right config?
0
Thomas D'Hoe
Michael Locurcio , I think you need to enable auto-accept feature: https://support.zendesk.com/hc/en-us/articles/6206214897562-Announcing-auto-accept-functionality-for-live-chat-and-messaging-customers
0