Last week Zendesk announced that all new instances will have Omnichannel Routing enabled by default. This means that all new customers will get the routing experience, agent status and access to queues, skills and capacity rules enables by default, replacing the old trigger based assignment rules.

Ticket assignment in Zendesk has traditionally been based on triggers and groups. A ticket is created, and based on the form, email address used or specific custom fields we can assign the ticket to a group. A ticket send to [email protected] gets assigned to the support group, or a user submitting a form while selecting login issues as a topic, get routed to our devops group in Zendesk.

This worked, but with all tickets being assigned to a group making sure the right ticket is picked up by the right agent gets tricky since it's basically one giant bucket of tickets offered to your agents. You can use views to sort by SLA, priority or creation date, but you can't really force an agent to work on that specific ticket. (You should't actually force anything to anyone in life, but you try to make a pretty good argument to make them work on that ticket 😇)

With the arrival of Omnichannel routing we can implement a more nuanced system to assign tickets. With omnichannel routing all tickets are placed in a virtual queue. Based on criteria you select, and combined with agent availability the system will assign tickets to specific agents. When a ticket is handled by the agent, the next best ticket is assigned to them until the entire backlog is processed.

Earlier this year I wrote an introduction to Omnichannel Routing which goes into this process in detail, so take a look if you want to grasp the basics, before diving into this article.

An introduction to Omnichannel Routing in Zendesk

This article will give you an overview of Zendesk’s Omnichannel Routing, Agent Availability and the brand new Queues features.

Internal NoteThomas Verschoren

Which ticket gets assigned first?

Omnichannel Routing assigns tickets based on a queue. A ticket is created and is inserted in the System Queue. The topmost ticket of that queue gets assigned to the best available agent, while new tickets are added to the queue upon creation (or update).

The order of those tickets is important though to make sure tickets are handled in the right way. By default the queue is sorted by creation date. Oldest ticket gets handled first, newer tickets are added at the bottom.
If you use triggers to set ticket priority (eg a VIP user gets priority high, or Server down gets priority urgent), then Zendesk will first process all urgent tickets by creation date, then high tickets and so on.

This approach sounds good in theory (urgent tickets should be handled first right?), but there's a caveat that's often overlooked.

In our example image above there's a low priority ticket in the queue. When do you think this ticket gets assigned to an agent? It can only riser to the top of the queue if it's the oldest ticket in the queue and if there are no higher priority tickets in the queue. So if this ticket manages to get to the top of the list, the moment a newer ticket is created with a higher priority our ticket will get pushed down in the queue again and the newer higher priority ticket gets handled first.

Looks good in theory, but what you might end up with is a backlog of low priority tickets that never get high enough in the list to get assigned to an agent.

SLA Based sorting

When I create Views in Zendesk, I recommend customers to sort those views by SLA instead of creating date or priority. Since SLA policies are a running timer based on time and priority, it's a way to combine those to elements and sort tickets in a more natural way.

Let's take a look at the example below. We've got three tickets created at different times with different priorities. We've also got a First Reply Time SLA setup which accounts for the ticket priority.

If we create a view sorted on creation date we'd handle the tickets in the order of 1-2-3. Which is not the best way to handle tickets since we probable want the high priority ticket 2 to be handled before the lower priority ticket 1

Let's say we order them by priority. The new order at 9AM would be 2-1. Or if the backlog is enormous and we don't get a chance to look at ticket 1 before 12PM, the order becomes 2-3-1. What happens now is that our low priority ticket gets pushed down in the list.

This sorting is how Omnichannel Routing works and when looking at this form a Views perspective you immediately see where issues might occur. Those low priority customers like Ticket 1 won't be happy if their tickets keeps getting ignored.

However, there's a solution. If we take SLA's into account, the order would be 2-1-3 and any ticket that is created after 9AM will always be handled after our Ticket 1.

This works great for views, since the topmost ticket in our view will be the tickets whose SLA will be breached first, and there's no chance of low priority tickets getting pushed down and being superseded by higher priority tickets.

And thanks to a recent update to Omnichannel Routing we can have this exact same sorting method for our Omnichannel Routing queues too.

Which agent gets the tickets?

There's a couple of elements to configure which agent gets the ticket. By default the agent with the least amount of assigned work gets the ticket.
If however you've setup Agent Statuses, then the online agent with the least amount of assigned work gets the ticket.

If you have a big amount of incoming tickets though, this might lead to dozens, or hundred of tickets being assigned to your agents. To prevent this kind of backlog per agent, you can use Capacity Rules to set a limit on the amount of tickets an agent can work on at the same time. This way an agent can get 5 emails, 3 messaging conversations and 1 voice call at the same time. Once all agents are at their limit, the rest of the tickets remain in the queue until an agent has availability.

While Capacity Rules are nice to prevent overloaded agent backlog, you still might end-up with an Agent that is chatting with a customer while getting an incoming phone call assigned. With Focus Mode enabled Zendesk will prevent these kind of collisions and will only assign Messaging conversations to agents that aren't calling, or vice versa.

Online status and capacity limits are two great settings to make sure tickets get assigned to available agents that can give the ticket the right kind of attention. However, it doesn't really tell us if the agent can handle that ticket. A product question gets assigned to our support team, but you want to make sure that the agent who gets the ticket assigned can answer those questions. This is where you can leverage Skill Based routing. By enabling skills and assigning them to tickets and agents, the system will then assign tickets to available agents with capacity that also have a matching skillset. (There's also a time-out option so that tickets that require a specific skill but without available matching agents can get assigned to available agents without that skill).

Most of the above actions have been available since the release of Omnichannel Routing, but thanks to the redesign of that section of the Admin Center setting it up has been a lot easier and logical.
There's one setting though that has only recently been released.

As mentioned earlier in this section, Zendesk assigns tickets based on the agents with the least amount of assigned tickets. Or in other words, if we take capacity limits into account, tickets are assigned to agents with the Highest Spare Capacity. If Luke has 3 out of a maximum of 5 tickets assigned, and Han is 2 assigned tickets, the next available ticket will be assigned to Han first.

From a ticket workload perspective this sounds fair, but maybe Han has a lot of easy tickets or works way faster than Luke. If we keep pushing new tickets to Han he'll probably end his day having processed way more tickets than Luke. To prevent this from happening you can use a different Assignment method. Instead of looking at capacity we can Round-Robin tickets and assign them to the agent in order. This way the agent who's gone longest without getting new work will get the ticket first. Which might result in Luke getting a fourth ticket assigned, while Han stays on two.

Reopened Tickets

So far we've only talked about assigning new tickets in the queue. But similar however can use a next-reply-time SLA to sort tickets that already for an agent reply and require an update, we can also decide who should react to that ticket.

By default re-opened tickets are assigned to the same agent that handled the ticket originally. You can however choose to assign the ticket back to the best available agent in the group if the original agent is unavailable or you can omit the group all together and have the ticket be routed back through your queues. The last one is ideal if you have Intelligent Triage updating ticket intents, or do Entity Detection and you want tickets to be assigned to the right team based on new context in the conversation.

Accepting Conversations

Even though we've talked about assigning tickets to agents in this article, what Omnichannel actually does is offering tickets to agents, which agents can then accept to work on.

When agents do not accept a Messaging conversation you can either keep your customer waiting indefinitely, or cancel the routing and try to offer the ticket to the next available agent. Or you can auto-accept for the agent which will immediately connect an incoming conversation with the agent.

This kind of auto-assignment is also available for email based tickets, and with the imminent arrival of Omnichannel Routing for Zendesk Voice, I can only assume the same will happen for incoming phone calls.

Wrapping up the routing options is one final checkbox: "Count inactive conversations towards an agent's capacity".
Basically this means that as long as a messaging session hasn't ended, the conversation will count against an agents' limit even though the customer might not be actively replying. Sessions end after two hours or when the agent clicks End Session.

This last option is useful for scenarios where you expect customers to take a while to respond. They need to do troubleshooting steps away from their phone or laptop, the result of the conversation might take a while (reboot, update, delivery will happen in an hour) and you want the customer to respond to the same agent since they have all the context.

Similar to how we can reroute conversations when a customer becomes inactive, we can also enable an Idle Timeout for agents. This will turn an agent's status from online to away or offline if they don't work in Zendesk for a preset amount of minutes.

Conclusion

As you can see, Omnichannel Routing in Zendesk has gotten tons of extra options that will probably make it fit the way you work. Knowing the options is one thing though, but actually using them to your benefit is another.

So to conclude this article, here's my suggested approach to setup Omnichannel Routing.

1. Make sure all tickets get assigned to a group via triggers. You can use a fallback trigger to assign tickets that don't get picked up by your triggers to a default group
2. Make sure all your tickets have at least a priority normal, and add triggers to assign a higher or lower priority to those that require it.
3. Setup a basic SLA policy for first-reply-time and next-reply-time that applies to all tickets. You can add additional stronger policies for those tickets that need it.
4. Setup agent statuses and capacity limits. At least one configuration should be added for each, you can add more later if you want to handle specific groups or agents differently.
5. Enable Omnichannel routing on all tickets by setting the auto-routing tag via a trigger. This might seem radical but this way all tickets are handled the same way and you don't have the additional complexity of classic trigger assignment and routed tickets.
6. Toggle SLA based routing in the routing configuration and keep Highest Spare Capacity enabled. This way agents work on the most urgent ticket first (based on SLA) and all agents have an equal workload
7. Turn on reassignment for re-opened tickets, and enable the Messaging Time-out for assigned tickets. This way tickets are always routed as fast as possible to the right agent who has time for it. Similarly, also setup an idle time-out for agents.
8. I like Focus Mode for setups that have Messaging and Voice enabled

Skill Based routing, auto-assignment and queues for me are a next step in Omnichannel Routing and should only be configured once you've got the basics setup.

If you notice that you need more granularity in priorities than just low/normal/high/urgent you can enable queues. You can give a higher priority to a set of tickets (e.g. all tickets related to orders) by creating a queue for them. Within that queue the assignment flow of SLA based ordering is then applied. Once that queue is emptied, the next queue of tickets is routed to agents with its own SLA based sorting.

Of you notice that not every agent is as efficient in handling every ticket (you can use Zendesk QA to get insight in effectiveness), you can look into Skills and skill-based routing to send specific complex topics to agents that know about them. All other tickets are then applied via the normal routing rules as configured.

I hope this article helps you getting started with Omnichannel Routing. Let me know!