Omnichannel routing with unified agent status allows you to direct tickets from email (including web form, side conversations, and API), calls, and messaging to team members based on their availability and capacity. On Professional and Enterprise plans, tickets can also be routed based on priority (see Summary of features by plan). Using omnichannel routing means agents can set a single unified status for all channels, and important tickets are assigned to the agents who are most available to work on them. This provides the following benefits:
- Agents can respond to tickets faster
- You can prioritize work from high-value customers, including calls
- Agents are automatically assigned tickets and don’t have to go looking for them
- Agents can’t "cherry pick" the tickets they want to work on
- Agents can work on multiple ticket channels at once
- You can route calls to specific groups of agents based on the caller's country code of callers or other attributes
You can use capacity rules to limit the amount of work that’s assigned to agents at one time. However, regardless of these rules, agents can assign themselves work in excess of these limits if they want to (see Creating capacity rules to balance agent workloads).
With omnichannel routing, instead of setting status individually by channel, agents can set a single unified status for Support, Talk, and Messaging. On Professional and Enterprise plans, admins can also define their own custom statuses such as “Out to lunch” or “In a meeting.” This can assist you when deciding how you want to route work items (calls, tickets, and messages) based on the agent status and capacity. See Adding unified agent statuses.
To use omnichannel routing, you have to enable and configure it. If you decide to stop using it, you can turn it off.
This article contains the following sections:
Requirements and limitations of omnichannel routing
There are a few requirements for using omnichannel routing, as well as some limitations you should consider before enabling the feature.
Requirements
- The Agent Workspace must be activated for your account.
- If your account has a Chat subscription, native messaging or Sunshine Conversations must also be activated.
- You can't be using live chat.
Limitations
Omnichannel routing with unified agent status currently has the following limitations:
- Omnichannel routing can't be enabled if you’re using live chat. Only Messaging is supported.
- Broadcast and hybrid modes for messaging aren't supported.
- Focus mode isn't supported.
- Routing of email tickets by skills in omnichannel routing is currently in an Early Access Program (EAP). If you're interested, you can sign up for the EAP here.
- The ability to set an agent's status if they don't accept a number of message assignments, known as automatic idle, isn't supported yet.
- When using agent statuses, operating hours won't automatically set an agent's status.
- Light agents can't be assigned tickets and can't set a status.
- The ability to change a Talk agent’s status from the Talk dashboard, mobile apps, or by using the Talk APIs isn't supported. Integrations that use Talk APIs to change agent statuses might also be impacted.
- The ability to set up multiple call routing fallback groups in Talk settings for a single line or IVR keypress isn’t supported with omnichannel routing.
- Tickets are created for all calls as soon as they enter the queue.
The setting “Create tickets for abandoned calls” is no longer available.
Tip: You can create a workflow to automatically close tickets created for abandoned calls.
- If call forwarding is enabled and the status of an agent is automatically set to offline because the agent has been disconnected, calls to the agent will no longer be forwarded to the agent’s phone.
- Explore dashboards will show per channel agent statuses but not unified custom statuses.
- At the time omnichannel routing is activated, agent statuses can get into an inconsistent state. It is important to manually set every agent's unified status to offline initially, then allow them to set their own status after that. For more information, see Agent statuses are changing to online when enabling omnichannel routing.
- When using priority phone numbers in Talk, call tickets are assigned High priority but aren't necessarily put directly at the top of the queue.
- Talk Partner Edition isn't supported. The way you route calls for Talk Partner Edition depends on the integration you're using.
How omnichannel routing works
When you use omnichannel routing, tickets are generated for all channels of work when they enter the queue, enabling you to run triggers on them, including incoming calls. For brevity, channels of work are labeled as Email (including tickets generated from email, web form, side conversations, and API), Messaging, and Talk.
Omnichannel routing routes work to agents based on the following:
- Availability. This is defined by the single unified status the agent sets across channels.
- Capacity for each work channel. You define the maximum capacity for each channel and decide which tickets are eligible for routing.
- (EAP) Skills. This is defined by the skills assigned to agents and Support tickets, and only applies to email tickets.
Then triggers are used to assign the tickets to groups, assign a ticket priority, and add a routing tag to the ticket. The following table shows the order in which tickets are routed to agents:
Plan | Order in which tickets are routed |
---|---|
Suite Team and Growth |
Tickets are assigned to agents in the order they are created. |
Suite Professional and Enterprise |
The ticket with the highest priority and oldest creation date, is routed to an agent within the assigned group who has an eligible status and the most spare capacity. |
Tickets are assigned to agents based on the following:
- Agent's status for the channel:
- Email tickets: An agent must have a status of online or away to receive email tickets.
- Messaging conversations: An agent must have a status of online to receive active messaging tickets.
- Calls: An agent must have a status of online to receive incoming call tickets.
If an agent forgets to set their status to offline, the status of the agent is automatically set to offline or away, as defined by an admin, when one of the following events is detected:
- An agent closes the Agent Workspace without signing out (by closing down their computer or browser window or putting their computer to sleep)
- An agent’s connection is lost due to a network outage
- An agent is idle for longer than the idle status threshold defined by admins
See Setting your unified agent status with omnichannel routing.
- Agent's spare capacity for that channel:
- An agent must have fewer open tickets or active messaging conversations than the defined maximum capacity for that channel to have spare capacity. See Creating capacity rules to balance agent workload.
- If more than one agent has an eligible status and spare capacity, the agent with the highest spare capacity for the relevant channel is assigned.
- If more than one agent has an eligible status and the same spare capacity for the relevant channel, the ticket is assigned to the agent who hasn't been assigned a ticket in the longest time.
- To be assigned an inactive messaging ticket (more than 10 minutes without a reply), an agent must have spare capacity, but the ticket doesn’t use up any of that capacity.
- Agent's skills (EAP for email tickets only):
- An agent must have the same skills as the ticket in addition to having an eligible status and spare capacity.
- If you select Fallback to routing model, tickets will be assigned without regard to skills if an agent with the matching skills is unavailable when a ticket reaches the top of the queue. If this option isn't selected, tickets will sit in the queue until an agent with the matching skills becomes available.
Here's an example of a scenario for omnichannel routing:
- An important VIP end user has an urgent issue that needs to be resolved.
- They submit a ticket using the email channel.
- The account admin has set up a trigger for the account to add the auto-routing tag to these tickets and then assign a group and priority.
- As a result of this trigger, the end user's ticket automatically routes to a specific group with an urgent priority.
- Omnichannel routing now assesses the ticket based on agent status and capacity.
- The routing system first understands that two agents are available for work.
- Second, it finds the agent with the most spare capacity for emails and assigns the ticket to this agent.
Reassigning messages and calls in omnichannel routing
Messaging conversations and calls require time-sensitive responses. Therefore, omnichannel routing has special reassigment logic for each.
Reassigning messaging conversations
With reassignment timing, a message can be reassigned to another agent in the group if the original agent does not take the message within a specific time threshold. The default threshold is 30 seconds. On Enterprise and above, that threshold can be customized.
The reassignment timing setting must be turned on during setup to reassign messages automatically if they aren’t accepted within the specified time. If that setting isn’t enabled, the routing engine will keep trying the same agent.
Reassigning incoming calls
When a call is offered to an agent, they can choose to accept or decline it. If the agent declines the call or doesn't answer within 30 seconds, the call is returned to the queue and assigned to another available agent. The call will continue to be offered to available agents in a round-robin fashion until the maximum queue waiting time expires.
- Hours since created > (calendar) Less than >1
- Status > Less than >Solved
- Channel > is > Phone call (incoming)
Summary of features by plan
The availability of omnichannel routing features varies by plan level. The following applies to your Zendesk Suite plan level, or to the plan level of all individual products:
Team | Growth | Professional | Enterprise |
---|---|---|---|
Routing email, messaging and call tickets |
Routing email, messaging and call tickets |
Routing email, messaging, and call tickets |
Routing email, messaging, and call tickets |
Routing based on capacity and agent status |
Routing based on capacity and agent status |
Routing based on capacity, agent status, and skills (EAP) |
Routing based on capacity, agent status, and skills (EAP) |
Default unified agent statuses |
Default unified agent statuses |
Default unified agent statuses |
Default unified agent statuses |
Routing based on priority |
Routing based on priority |
||
Up to 5 custom statuses |
Up to 100 custom statuses |
||
Message reassignment |
Customizable reassignment time |
Related articles
See the following articles for more information to help you get up and running with omnichannel routing and agent statuses:
165 Comments
Hi Prince Singh
Unfortunately TPE is not currently supported in omnichannel routing - this is on the roadmap however (likely 2023)
Hi LVB and Slava Skorbezh
We are looking at having two configurable options:
1) Having inactive messages in queue treated differently from active ones (as is today) - this means once a message goes inactive after 10 mins it is auto assigned (no need to click Accept) to the next online agent and wont take up capacity
2) Having inactive messages in queue treated the same as active ones - so inactive messages will flash the Accept button and will take up capacity
Would option 2 be acceptable for now?
Barry Neary For us option 2 is preferable. To be honest, I do not understand the logic of the first option at all.
By the way, you are one of the most involved Zendesk PMs. That's very cool, thank you.
Barry Neary I want to support Slava Skorbezh
The second option seems to be more correct in terms of customer experience and convenience for the agent.
Since in the first option, if we have more than 100 inactive tickets, then they will be assigned to agents until they run out.
Also have a question. If according to option 2, then which tickets will be assigned in priority active or inactive?
Thanks!
The logic of option 1 was to try and allow the agents to get through the messages that were inactive quickly so you can get to the active ones at the bottom of the queue
Assuming all the messages are of equal priority, then the older inactive messages are at the top, where the end user may not be still there, whereas the new active ones are at the bottom, where the end user is more likely to be there awaiting a response.
Anyway, thx for you feedback and we will looking offering you an option as to how you want it to work
Barry Neary Thanks for the clarification. The fact is that live agents are just humans. And by assigning them chats above the capacity, you can't increase their ability to respond :)
Thanks Barry Neary,
Definitely agree with what others have said here. The assignment of inactive chats wholesale to whichever agent goes Active first feels more like a consequence of incomplete design than of deliberate decision making.
The option to choose how these are handled will be good. Option 2 will definitely be what is selected by us.
I would like to have both options or even make an if-statement that switches automatically when the queue hits 10 pending customers or 5 minutes and then switches from option 2 to option 1? if that makes sense
I think when you come to the point where your agents are not able to keep up with the requests option 1 would be highly recommendable and option 2 would only add to the drama.
If I have to choose one I think I would stick with option 1 because of the quantity of incoming tickets/mssgs vs agent capacity.
Hi Barry Neary,
Kudos for being an active PO,
I would like to echo the sentiments here, both options are viable depending on situation. It would be great that we are able to switch up or down when required. It would give us the flexibility to manage operation better!
As stated by Tim, our agents are still human after all.
We are using Live Chat and messaging. Will Omnichannel work then for the messaging and emails, but not the Live Chats?
Can Live Chat co-exist with Omnichannel?
If you have Agent Workspace with Messaging enabled, the Omnichannel feature is available for you and your Messaging tickets. You can only choose either "Messaging" or "Live Chat" to enable at a time, if you are using Messaging you cannot be on Live Chat too.
As long as Messaging is what you're currently using, Messaging tickets (or persistent conversations almost similar to live chat) comes with the Omnichannel feature. See Messaging vs. live chat.
When a customer has started a chat with an agent via messaging, and then does not reply for some hours and comes back, normally the chat is updated with the same agent to follow up, however sometimes they are offline or at lunch and the ticket is not reassigned to other available agents
I'm wondering If we use omnichannel routing, if it could reassign these tickets to an agent that is online instead of the agent who previously had the chat with them and is now offline or out to lunch
Hi Pedro Cassian
Yes, this is a common request and we are working on the ability to reassign messages that reopen based on agent status - e.g. reassign back to group if agent isint offline
Right now, a workaround is that agent bulk adds a tag to all their messages when they are finished their shift. Then have a trigger that has as a condidtion that if a message changes ticket status from solved, pending or on hold back to open AND has the tag then set assignee to NULL. The routing engine will then reassign the message to someone else in the group
Hi Barry Neary
Yesterday we enabled omnichannel routing for the first time and were pleased with the experience.
But if there are not many tickets in the queue and agents' capacities are already full, I would like that an agent could take tickets as before from the accept button.
HI Irina Kurda
Understood - alternatively the agent can look into a view that contains unassigned tickets and either play through them or manually open them and assign them to herself...
Hi Barry Neary
The only problem with unassigned tickets — you can not leave only Play button. If agents are allowed to manually open unassigned tickets they often try to pick up the easiest. I hope there are plans to add the ability to take more chats from the accept button.
We trialed omnichannel routing for a day and turned it off. It seems like a major oversight that multiple channels will route to an agent at the same time. I had hoped this would resolve the issue with focus mode not working properly after enabling messaging, but it doesn't. Curious who on the product development team is able to both answer a phone call and perform verbal troubleshooting while providing sales support to chat customer simultaneously? (Seems like really basic functionality that just wasn't thought out.)
Also very unhappy with inactive chats that came in overnight all dumping on the first person who logs in in the morning.
Lots of room for improvement here before this will be a useable feature.
Hi,
Can we expect to have the focus mode compatible with the omnichannel routing soon?
Would that be possible to apply this omnichannel routing only for some brands or agents?
Thanks
Elsa
Hi Travelwifi/Elisa
Focus mode is on the roadmap - but at present its looking like Q2 next year.
To confirm, you would like
- only some agents to be automatically routed tickets
- only tickets coming in under certain brands to be automically routed?
Hi,
I would need to only apply the rooting for tickets coming in under certain brands?
Another Question. If a ticket (especially messaging ticket) was in status solved or pending and changes to open because the customer is contacting us again, and the agent who was handling the ticket is not online, is the ticket automatically reassigned to a new agent?
Thanks
Elsa
We just started using this today and I'd like to be able to see how many agents did not accept a chat when it was offered to them. We are seeing a delay of 2-3 minutes before something is accepted by a rep, but I don't know if it's a flaw in the system or if it's happening because reps are not accepting the message and it's rolling to the next one. How can I figure out which scenario we have going on?
I want to support the previous comment. Information about not accepted chats is very necessary thing. Now there is no understanding why one ticket is not assigned for 2 minutes, and the other is assigned in a couple of seconds
Hi, we are planning to add further information to the ticket event log to show which agents were offered the message/call as well as how actually accepted it
Hi Barry Neary,
I configured Slack via messaging. Tickets created via Slack are not getting assigned to agents.
It does have the required tag and gets assigned to the relevant group, but do not get assigned to an agent. I do get the notification sound, but ticket do not get assigned.
Tickets created via other messaging channels like Web, Facebook and Twitter are getting assigned properly.
I contacted the support team, they informed me that this is not supported.
Messaging is supported and Slack (part of messaging) is not supported, this is a bit confusing.
Can you please check and share some clarification on this?
Regards,
Kulin
Barry Neary Looking at the article you shared. I do not see that agents are notified the same way as a new chat for a group. We need agents to get the same audible & visual notifications for when a chat is transferred to their group as when a new chat comes in. Can you confirm this? Just to be clear, we need this for messaging.
Hi Jason Walker-C
There is an issue currently with the audible alert which may be why your agents are not hearing it - this should be fixed by the end of the week. When in place, the button should flash and the audible alert sound
Barry
Hi Barry Neary
We've been using this feature for over a week now and have run into a problem we can't solve ourselves.
Some tickets are being routed to another group of agents. These tickets are not taken by agents right away, but after enabling omnichannel routing all these tickets started to be automatically assigned to agents. Is there any way to fix this?
Hi Irina Kurda
Are these tickets messaging tickets?
Barry
Barry Neary
Yes, these tickets are from the messaging channels
I am admin for zingbox.zendesk.com . My "Get Help" button was broken. I cannot file a zendesk product support ticket. Anyone?
Please sign in to leave a comment.