Recent searches


No recent searches

Understanding how omnichannel routing uses queues to route work to agents



image avatar

Jacquelyn Brewer

Zendesk Documentation Team

Edited Nov 06, 2024


1

107

107 comments

image avatar

Barry Neary

Zendesk Product Manager

Hi Danielle
 
I have DM you about thi

0


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


image avatar

Barry Neary

Zendesk Product Manager

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


image avatar

Barry Neary

Zendesk Product Manager

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


image avatar

Thomas D'Hoe

Community Moderator

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


image avatar

Barry Neary

Zendesk Product Manager

HI Thomas D'Hoe 

We are planning to support ordering within queue by SLA natively 

Barry

0


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


image avatar

Barry Neary

Zendesk Product Manager

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


Barry Neary   Yes, please DM me.

0


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


image avatar

Thomas D'Hoe

Community Moderator

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


Very big +1 to what Thomas D'Hoe  recommended. 

0


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


image avatar

Thomas D'Hoe

Community Moderator

Hi, regarding to following bullet point in the article:

 

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.


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


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


image avatar

Barry Neary

Zendesk Product Manager

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


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


image avatar

Barry Neary

Zendesk Product Manager

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


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


image avatar

Thomas D'Hoe

Community Moderator

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


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


image avatar

Thomas D'Hoe

Community Moderator

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


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


Thank you so much Thomas D'Hoe 

 

Could you please also enable this for us Barry Neary ?

0


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


image avatar

Barry Neary

Zendesk Product Manager

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


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


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


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


Please sign in to leave a comment.