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 Irina Kurda
Currently messaging tickets in the queue are treated differently according to whether they are active or inactive.
Active tickets are those in which there has been conversation on the ticket in the last 10 mins, Inactive ones are ones in which there hasnt
Active messages get assigned using the Accept button and take up capacity. Inactive ones are directly assigned to agents and dont take up capacity (althought the agent has to have spare capacity to be assigned them). So there is the situation where one agent can be assigned multiple inactive messages,
We are working on giving you the option of whether you want to treat active and inactive messages the same. In the meanwhile, as a workaround, you could setup a trigger that assigns inactive messages to a seperate group that has no members. Then agents can go to a view for this empty group and manually work through the inactive messages. The trigger would look like this:
Action: assign to empty group
Barry Neary
Thanks
We will try this way of working
No timeline for when it will be possible to manage active and inactive tickets?
For this limitation mentioned in the article:
Can you clarify a little more on what this means? My initial impression is that it does not overlap with our IVR menu settings, and am wondering if this changes the customer's experience in their calls to us?
HI Irina Kurda
We are looking at Q1
Hi Barry Neary
It's very cool that this feature could be released in Q1. We need it, too.
Irina Kurda
Currently inactive messages (those in which there has been no communication for 10 mins) are considered not to take up capacity and hence mulitple inactive messages can be assigned to the one agent - they dont count against their max capacity.
We are working on offering the option to treat the inactive messages the same as active ones ...
As a workaround you could have inactive messages moved to an empty group and have agents go through them manually?
Something like:
Kulin Joshi
We will be adding Slack message to the omnichannel routing engine in Q1
Thanks Barry Neary
We will try to use your option today. But there is one question: we put that the ticket has been updated, but if the client does not write anything, it will not be considered that the ticket has been updated?
HI Irina Kurda
The client does not need to write anything, the message going from active to inactive means that the ticket is updated and the trigger should fire
Thank you so much.
We will try this way of working
Hi Barry Neary
Tried the option for the inactive ticket yesterday. Unfortunately, it didn't work for us, because the setting was triggered whenever the ticket was updated. In our case: after creating a ticket, the client's information is added to it and the redirection setting was triggered in just a few seconds
Hi Barry Neary,
How does the idle messaging conversation gets assigned to agents automatically?
Is it linked to the status of the agent? Does it only get assigned when the agents are online?
I do understand that it is not linked with capacity, so I would really like to understand how does it work?
Regards,
Kulin
Hi Kulin Joshi
Currently if the message has no conversation for 10mins it becomes inactive.
Inactive tickets are assigned only to online agents that have spare messaging capacity, but once they are assigned they do not take up any capacity - so one agent could be assigned several inactive messages (beyond their max capacity).
When they are assigned, the Accept button doesnt flash - they are automatically assigned like email tickets.
We are looking to offer an option whereby inactive messages are routed the same as active ones ...
Is there any plan for this to support the classic live chat in the future?
Hi Barry Neary,
The Unified status is currently only supported for messaging and does not support chat.
Messaging can be activated per brand, so if we have two brands, then we can have the messaging active on one and chat active on the other.
Since both are linked with the agent workspace, so the unified status will be common.
In this case, chat and messaging will work on-site, but agents will only be able to accept messaging tickets. Chats will not be assigned to agents.
Am I correct here and is there any solution where we can use both chat and messaging?
Regards,
Kulin
Hi Kulin Joshi
We do plan in H1 2023 to support customers that are mixed mode - ie. have bith Chat and Messaging
Barry Neary re. the plan to support customers that are mixed mode have both chat and messaging, will this also support users who are purely using the classic live chat message and NOT using the new messaging?
Hi Barry Neary
We had switched over to Omnichannel for a few weeks already, and so far we are liking it. We are happy that the Messaging & Email tickets are routed/ assigned to agents directly.
We noted that Messaging has sound notification enabled, which is great, but are there any plans to enabled sound notification for newly assigned ticket for Email Support? TQ
Barry Neary few feature requests as we're standing this up:
Hello,
Is there ZAF client API for omnichannel feature? I was not able to find anything related to it. If not, is there a roadmap for when we going to see it? I need it to implement the app for custom capacity handling.
Thanks,
Andriy
When will fallback groups be added back to Talk? We love omni routing but we really need Fallback groups back it feels like a massive piece of functionality to be removed. Thank you
Barry Neary You stated that there was an issue that will be fixed in a week. It's been a month and still not working. Any idea when this will be fixed? https://support.zendesk.com/hc/en-us/articles/4409149119514/comments/5108276229530
Hi,
I just noticed that this feature is not respecting agents' OOO status. System unassigned a ticket from the agent because OOO status yet within a minute assigned it back to him. See screenshot below. I think this should be treated as a bug since it makes no sense to assign tickets to OOO agents and you can't do it manually so the system should be an override.
We found the same thing, and it's really disheartening that Zendesk's own solution doesn't respect the OOO setting in ... Zendesk's solution.
It's clearly a bug to me, and a fix should be prioritized as it's really dangerous to have a ticket re-assigned to someone who is OOO. That's a really easy way to have something go unnoticed by support agents.
Hi
The Out of Office app is not compatible with omnichannel routing (OCR) from the perspective that OCR uses the agent status as defined by the agent status picker rather than the OOO one. We are actively working on a feature in OCR that would reassign tickets that are reopened while the agent is offline
Jason Walker-C
The bug related to audio issues was indeed fixed - so your issue must be unrelated,
To confirm, is this issue that you have highlighted a bug or a feature request? Did notifications work as you describe previously but since you have switched on omnichannel routing they no longer work?
Thanks Barry. Just to be clear, being Offline and being Out of the Office are sometimes two separate things and should be treated differently. Or at least have two separate options to set how to handle each.
For instance, an agent might be Offline as they've gone home for the night. Even if a Pending ticket switches back to Open following a customer response, the ticket should still stay in their queue, assigned to the same agent for follow-up the next day.
But if they're Out of Office (on vacay, etc) the ticket should be unassigned and routed to another agent.
I suppose this could be handled via custom statuses, though ..
I think expectations for offline vs out of office would depend on operating hours. Some of our tickets have 24/7 operating hours, so if a ticket waits for that agent to get back on shift the next day then we've breached SLA.
One approach that for me might make sense is to base the reassignment on the ticket's schedule - if it's in schedule, open, and the agent is offline then reassign.
Hello, great feature. When our agents are using messaging, they get a ding are prompted to accept a conversation here:
Once I turn this on, they do no get that. How do I make that happen again with Omnichannel Routing?
Please sign in to leave a comment.