Earlier this week I published an Introduction to OmniChannel routing that gave an overview of the new ways Zendesk allows you to assign tickets to agents and groups making use of availability, agent skills and ticket priority.

I ended the article with the following thought:

It's important to know that queues still require the existence of the auto_routing tag to work. But I am tempted to forgot assignment triggers completely and only rely on queues.

This article will dive into the specifics on how this kind of setup could work.

The basics

Let's recap the basics first.

In a traditional Zendesk setup a ticket is created and we have triggers that set the ticket priority and assign the ticket to a specific group based on the ticket channel, category or form.

Omnichannel Routing picks up these tickets and use agent availability and capacity to assign the ticket to the best agent at the time.

But now that we have queues we can also use them to route tickets to the right group or groups based on conditions. Which creates an issue since we now have two competing systems – triggers and queues – that battle for assignment. And it also makes setups complicated because we need to take both into account to get the complete picture of how our assignment rules work.

Even worse, imagine a trigger assigning finance tickets to Sales, and a queue assigning them to Finance. Understanding which one "wins" requires a lot of reading Zendesk documentation and it's not clear from the get to.

So my idea is to make this easier and go all-in on queues and Omnichannel Routing.

Let's dive in.

Situation Sketch

We have a Zendesk environment with two forms: a Support Form and a Sales Form. There's two corresponding groups of Agents: Support Team and Sales Team.

We also setup Omnichannel Routing with an auto-routing tag, and we've configured agent statuses and capacity rules.

Our goal is to creating routing rules that will assign all Support tickets to the support group, and the Sales tickets to the sales group.

Triggers

Now for the radical part: I have deactivated all triggers that assign tickets to groups or agents. They are replaced by two triggers.

Enable Omnichannel Routing

This first trigger adds my Omnichannel Routing tag auto-routing to all created tickets. This enables the tickets to be routed.

Set Default Priority

It's also best practice to set the priority of every ticket created. Ticket Priority is taken into account for the order in which tickets are routed to agents and are required for SLAs to work. So I have the habit of setting all tickets to priority Normal by default and then we can always add additional triggers to shift the priority to urgent, high or low based on specific conditions.

Queues

Before queues we would have setup a Zendesk environment via triggers with, in our case, two triggers.

Now that queues are here, we can move all that logic into queues.

Support queue

First off, let's create a queue for ticket submitted through the support form. Similar to triggers, we set the conditions (e.g. form = support form) and then we select a primary group to handle these tickets. In our case, this would be the support group.

Sales queue

Our second queue is a queue that looks for tickets with Form is Sales Form. We assign these to the Primary Group Sales.

So far, this works similar to how we would setup a trigger in the past. But queues have some niceties to them. We can use the priority field to decide how queues should handle ticket collisions.

About priorities

Imagine we have two types of tickets for Sales: Product Info, and Quotes. We can create two queues for sales. A Quotes queue with a priority 1, and a Product Info queue with priority 2.
If we now have multiple customers sending in a requests, some about quotes, some about products, this will make sure that the quotes tickets get priority over the products. And within the queue, tickets are then handled by priority and creation date.

What happens now?

When a customer creates a ticket, this ticket will be tagged and enable Omnichannel Routing to start doing its thing.

1. A ticket is created in Zendesk for the Support group
2. The ticket is assigned to the Support queue. You can verify this via the ticket events view.
3. Once an Agent becomes available the ticket will be assigned to them.

There's a few things that are handled different than in traditional trigger based routing:

• Queues only assign tickets once an agent becomes available. So until a ticket is assigned to an agent, it's group is set to -
• Available agents can mean: someone goes online, someone has capacity (e.g. they can handle 3 conversations and they just closed one), or someone has a matching skill
• Once a ticket is assigned to an Agent, it will show up in their Agent Home. They can work, with confidence, from just Agent Home, and you can be sure all tickets will be assigned and handled in the right order, without cherry picking.

Queued tickets view

Since tickets are only assigned to groups and agents upon agent availability, I advise you to create a view for Team Leads that shows the queued tickets. Even though agents get tickets offered as they have capacity, a team lead might want to know the backlog still in the queues.

They can use that view to manually assign specific tickets that they feel should be handled now.

Fallback queue

One of the benefits of using queues instead of triggers for assignment is that the admin center reads a lot clearer. In one view you can see the queue name and its associated primary and secondary groups for assignment. Whereas in triggers you would probably need to give them very descriptive names to get name, group and conditions visible for agents.

This gives you the benefit that, at a glance, you can detect issues with your assignment rules and reorder or edit them as needed.

As you'll notice in the screenshot above, my queue list ends with a Fallback queue. This queue basically makes sure that all tickets are routed to an agent, even for scenarios I didn't take into account in the queue conditions above.

In the example below a ticket was created in the Complaint Form. Since this is not an existing condition in any of my queues, it's assigned to the fallback queue.
That queue has the sole condition if Group is - and has a priority of 100, while being added as the bottom most queue. This makes sure that these tickets are added to a queue, but will be handle with the lowest priority.

So when a customer creates an unmapped ticket, the ticket is assigned to the fallback queue. Then once an agent of any of the primary or secondary group is available, they get the ticket assigned in their respective group.

Conclusion

The approach above might be a bit radical if you've been using Zendesk for a while. It moves away from assigning tickets to a group, and fully dives into the concept of Agent assignment. It makes use of Agent Home, skills and availability and makes sure that tickets are handled by the right person. By assigning to agents it prevents cherry picking and gives you a top-down control over assignment.

There's a few things I would love to see though. A native way to view queued tickets by queue would be a nice starter for example.

For now, I've redesigned my own Zendesk instance to make use of this now approach 100% and I've moved all assignment to queues and omnichannel routing. It's a bit experimental, so keep an eye on the blog for updates on how it works in a few weeks.