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
HI Michael Locurcio
You could turn on auto assign for messaging, so from an agent perspective they dont see Accept button flashing for messagings, they are directly assigned just like emails.
If you setup a queue and have the queue conditions be such that both messages and email tickets go into the queue, then assuming all the tickets have the same ticket priority, they will assigned out based on date created - i.e. whichever ticket is the oldest will be assigned first independent of whether its a message or email.
Of if you want, you can have queues based on the custom field support package they paid for. Then you can prioritize the queues. So for example:
- Support package 1 tickets are higher priority than support packakge two
- Create two queues, one for support package 1 tickets and the other for support package 2
- Set the priority of support package 1 queue to be higher than support package 2
- if both queues are allocated to the same group, that group will receive support package 1 tickets first until there are no more left, then they will receive support package 2 tickets
0
Jason V
Hey Barry,
So queues solved our talk issue where calls can now be routed to the right office.
That being said we're noticing its hurting our ability to respond to messages as they get buried in our work loads and we don't respond in a timely enough matter.
1. Do queues only work with OCR turned on?
2. if so, is there a way we can retain a flashing accept button with OCR?
In an ideal instance:
- Talk - can be routed to the right groups based on region and queues
- Messaging - can be more broadcasted where agents can pick them up in a timely matter
0
Michael Locurcio
Hi Barry Neary - Your scenario is exactly as I want it to work.
In my Routing configuration, I have auto accept set to ON, is that the same as Auto Assign?
What is happening is that the Messaging ticket doesn't require pressing Accept, but it does open the ticket and flash on the screen. Is that the expected behavior? Is that what is supposed to be happening for email tickets too or is it just via views that an agent sees they have work to do.
Thanks!
-Michael
0
Johannes Garske
Hi Barry Neary
what will happen when an agent don't work on an assigned (email) ticket?
I tested it and it don't get reassigned. We want that when an agent don't do anything on the ticket, it will go back to the queue and will be reassigned.
Do we need to setup an automation for this?
1
Barry Neary
HI Michael Locurcio
In my Routing configuration, I have auto accept set to ON, is that the same as Auto Assign? Yes
The behaviour you describe for messaging is expected. For email, they are directly assigned with notifying the agent, but we are working on a feature to have email notify the agent in the same way messages do when you have auto accept on.
0
Barry Neary
Hi Johannes Garske
Yes, an automation is probably best. You could use ‘hours since assignee update’ as a condition and have the action be to set the assignee to null or to another group
0
Max
Hi Barry Neary
Once the OCR is activated, we see in the Talk console a routing field for each number, to assign calls to a group.
I guess then the calls go to a standard queue.
But what's happening if I set up as well custom queues for calls ?
Are my calls gonna be routed to the group I specified on Talk console or Custom Queues overread this configuration ?
Thank you for clarifying
0
Barry Neary
Hi Layla Atayeva
Have you considered using focus mode? This feature will prevent message being assigned to agents if they are on a call, and vice versa.
So if you have queues set up (priority calls > standard calls > messaging conversations in that order of priority), then when an agent doesnt have any active messages assigned to them they will receive calls, either from priority or standard call queues. They will continue to receive calls from these queues and wont receive any messages until there are no calls left in the queue (due to focus mode).
0
Jason V
Hi Barry Neary wanted to bump up my ask in case it was missed. I see a lot of discussion here about how to disable flashing messaging accept button - but I need that functionatlity.
I understand broadcasting chats are not suported with OCR, but I can't figure out how to get messages to be more prevalent other than creating a view where we go in to pick.
0
Layla Atayeva
Hi Barry Neary
I should have clarified in my original question, but yes I do have focus mode enabled.
I thought the issue was that we had 2 capacity set, so when they finished a message and had capacity for one more they would receive another message since they were not eligible for a call. Which ideally it would not assign a second message if there are calls in queue, but changing capacity to 1 we still have the same issue.
0
Barry Neary
Hi Layla Atayeva
Could you have two groups - one for calls and one for messages. The call queues would have the call group as the primary and the message group as the secondary. Then the message queue (which has the lowest queue priority) would have the message group.
So if the call group gets overwhelmed with calls, they would overflow to message group (with focus mode turned off)?
0
Layla Atayeva
Barry Neary
Is there any way to achieve this without turning off focus mode? I hesitate to put agents in a situation where they have both messaging and call tickets. We already have messaging and call groups as well since while all agents take messaging tickets, not all take calls. But I haven't been able to successfully make this routing work for us without back logging phones.
0
Dietke Fowler
Barry Neary https://support.zendesk.com/hc/en-us/articles/6712096584090/comments/6960337987226 Sorting a queue by nearest time to SLA breach is important to us as well.
0
D.Fitz
Hi Barry Neary,
Based on your comment above I'm setting up an automation to unassign tickets based on ‘Hours Since Assignee Update’ to remove tickets from agents' queues after a period of inactivity. However, it's not clear to me how newly assigned tickets (i.e. those routed by Omnichannel) differ from other ‘Open’ tickets. For instance, if an agent is working on a ticket and receives a reply from a customer, we wouldn't want to reassign this, but if there is a ticket which has not yet been handled, how would we differentiate these tickets with the automation?
0
Barry Neary
Hi D Fitz, could you combine ‘hours without assginee update’ with ‘hours without requester update’ ? Have both be must have conditions before action is taken?
0
Max
Hi Barry Neary
Did you get a chance to read my previous comment about Talk?
Thank you in advance
0
Johannes Garske
Hey,
does anyone know how to create the second trigger when it was again not solved from an agent?
According to ZD it is only possible to run an automation one time per ticket which means that we have to create an automation each time we want to reassign a ticket after x hours and give this ticket a tag.
Does anyone could please share their workflow?
We want to avoid to make some mistakes, because i don't really get this with hours since assigned and when this trigger then need to fire.
Thanks!
0
Michael Locurcio
Barry Neary - I noticed with the Live Data for reporting, when an email gets assigned, the live data decrements the queue down and it no longer stays on the report.
With messaging, the ticket stays on the report, based on my testing until the ticket is CLOSED. Is that the expected behavior? Can you comment on the difference? I have some theories.
0
Barry Neary
cc: Agnieszka Czajka
0
Barry Neary
Hi Max,
If a call goes into a custom queue, it will be assigned to whichever group(s) you have specified there (cc: Rohan Gupta )
0
Barry Neary
HI Jason V
we're noticing its hurting our ability to respond to messages as they get buried in our work loads and we don't respond in a timely enough matter.
Do you have focus mode turned on?
1. Do queues only work with OCR turned on?
Yes
2. if so, is there a way we can retain a flashing accept button with OCR?
When a message is assigned to an agent the accept button flashes. Optionally you can enable auto accept and the button wont flash
I understand broadcasting chats are not suported with OCR, but I can't figure out how to get messages to be more prevalent other than creating a view where we go in to pick.
Do you have focus mode turned on?
0
Barry Neary
Hi Layla Atayeva
You could try the above solution with focus mode on? So the calls would go to a dedicated call group but overflow to the messaging group only if the agents in the messaging group were not on active messages?
0
Haymo Grossmann
Hi Barry Neary I am interested on having reasssigned/unassigned tickets go back through queue logic. Can you assist to activate the setting on your back end?
Thanks a lot
0
Arianne Batiles
Hi Haymo Grossmann
I'm Arianne from the Advocacy team and I'm creating a ticket on our behalf for this request. Kindly check your inbox for updates.
0
HELENE LECOINTRE
Hi Barry Neary
I am interested on having reasssigned/unassigned tickets go back through queue logic. Can you assist to activate the setting on your back end please ? 😊
Thanks a lot 🙏🏽
0
Danielle
If we have the backend re-routing un-assigned tickets back to the omnichannel routing queue logic enabled, how does that impact when/how that ticket is routed the second time? Does it up the priority or something similar?
Secondly, which has the higher priority: the initial queue eligibility or the subsequent queue eligibility?
0
Dayner Carry
Hi! I'm trying to implement Omnichannel and Queues for the team. When using Queues it seems to be assigning the newest tickets first, ignoring older tickets in the backlog. How can this be solved? Thank you!
0
Barry Neary
Hi Dayner Carry
Queues should order first by ticket priority (Urgent tickets first, then High etc) and then by date created. Are some of the tickets reassigned and others are new?
0
Daniel Codesal
Hi Dayner Carry,
When I first started using queues I noticed something similar. Looking at the events history I realised the older tickets hadn't been assigned a queue as they were created before the queues were set up. Whereas the newer tickets had been assigned a queue as they were created after the queues were set up. A queue always takes priority over standard omnichannel routing, so all tickets assigned to a queue - regardless of timestamp - will be auto assigned before a ticket without a queue.
So I bulk updated the older tickets e.g. change the priority to low then back to normal or add a tag and then immediately remove the tag. After I had updated them, the older tickets were then assigned a queue and routed before the newer tickets.
Hope this helps.
0
Dayner Carry
Thanks Daniel and Barry. It indeed seems to only be assigning tickets that existed after the queue was created. I've tried updating the older tickets, as well as adding the auto-routing tag to them, but newer tickets are still being assigned first. Any ideas?
0