The omnichannel routing beta enables you to direct tickets from email, messaging, web form, and API to team members based on their availability, capacity, and the ticket priority. Using omnichannel routing means that the highest priority 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
- 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 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 Balancing your agent workload with capacity rules).
Omnichannel routing includes agent statuses which expand on the default statuses of online, away, transfers only, and offline to enable you to define your own 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 Configuring agent statuses).
Omnichannel routing is available to accounts with the Agent Workspace enabled. Additionally, if your account has a Chat subscription then messaging or sunshine conversations must be enabled.
This article contains the following sections:
How omnichannel routing works
Omnichannel routing routes work to agents based on the following:
- Availability. This is defined by the status the agents sets.
- Capacity for each work channel. You define the maximum capacity for each channel and decide which tickets are eligible for routing.
You’ll then use triggers 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 (generated from email, web form, API, and messaging conversations) 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:
- Messaging conversations: An agent must have a status of Online to receive messaging tickets. See Setting your chat status in the Zendesk Agent workspace.
- Email tickets: An agent must have a status of Online or Away to receive email tickets.
If an agent forgets to set their status to offline, the status of the agent is automatically set to offline 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
- 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.
- 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.
- Inactive messages (more than 10 minutes without a reply) can be assigned only to agents with spare capacity, although inactive messages don’t use up any of that capacity.
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.
Reassignment considerations for omnichannel routing
Reassignment timing reassigns a message to another agent in the group if the original agent does not accept the message within a specific time threshold.
- The reassignment timing setting must be enabled to reassign messages automatically if they aren’t accepted within a specified time. If that setting isn’t enabled, the routing engine will keep trying the same agent.
- A message remains active for 10 minutes in the queue. If it still hasn't been assigned after 10 minutes, the inactive message will be assigned to the next online agent with spare capacity (known as round-robin). It won’t use up any of that capacity. This applies only to messages that have previously been offered to an agent. Inactive messages never offered to an agent (for example, because they come in when all agents were offline) remain in the queue and are not assigned.
Limitations with the omnichannel routing beta
The omnichannel routing beta currently has the following limitations:
- Tickets generated from Talk calls are not included in this beta. However, Talk will continue to work normally when you activate omnichannel routing. For more information, and to be kept up to date about forthcoming releases, see Coming soon: Calls in omnichannel routing.
- 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.
- Broadcast and hybrid modes for messaging aren't supported.
- Skills aren't considered by the omnichannel routing engine. Look for this functionality in upcoming releases.
- If you turn on the omnichannel beta, you will no longer be able to change a Talk agent’s status from the Talk dashboard or by using the Talk APIs. We'll introduce a new API set in a later releases
- 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.