Capacity rules are part of omnichannel routing that help you balance your team's workload by setting capacities on automatically assigned work. The standard omnichannel routing configuration assigns work to the agent with the highest spare capacity for the channel who has an eligible status. For example, you could specify that only 10 open email tickets can be assigned to an agent at a time. This can be a great way of ensuring that your less experienced agents are not assigned too much work while they ramp up.
However, you can also configure omnichannel routing to use round robin assignment. When using round robin assignment, omnichannel routing checks that agents have some amount of spare capacity, but assigns work based on time elapsed since last assignment for the channel rather than how much spare capacity agents have.
Omnichannel routing comes with a default capacity rule that you can use as-is or edit. Admins can also create your own capacity rules to suit your needs. Agents are always assigned to whichever capacity rule you set as the default initially, but you can change their assignment if needed. An agent can only be assigned to one capacity rule, so if you assign an agent to a new rule, they are automatically unassigned from their current one.
Adding capacity rules
Omnichannel routing comes with a built-in capacity rule to get you started, but you can add additional rules as required. You must be an admin to create and manage capacity rules.
To add a capacity rule
-
In Admin Center, click
Objects and rules in the sidebar, then select Omnichannel routing > Capacity rules.
- On the Capacity rules page, click Add capacity rule.
- On the Add capacity rule page, provide the following
information:
- Name: Enter a descriptive name for the capacity rule.
- Description: Optionally, enter a description that helps you to identify the capacity rule.
-
Set as default: New team members are automatically
assigned to the default capacity rule. Team members who are already
assigned to a capacity rule won’t change.Note: If you create a new capacity rule and assign a team member to it, they are removed from the default capacity rule. If you delete a capacity rule, all team members assigned to it are assigned back to the default rule.
- Assignees: Click Add assignee to specify the agents to whom this rule applies.
- Capacities > Email: Enter the number of open email tickets (including web form, side conversations, and API) that can be assigned to an agent at one time. This includes all open email tickets, regardless of how they were assigned to the agent. Tickets that are pending or on hold are not counted towards capacity. (Maximum 500)
-
Capacities > Messaging: Enter the number of
messaging tickets that can be assigned to an agent at one time. Inactive
messaging tickets are counted if messaging activity routing is
selected. Otherwise, only active messaging tickets are considered. This
capacity also applies to chats in some
circumstances. When applicable to live chats, an agent can be
assigned up to this number of live chats and this number of messaging
conversations at the same time. (Maximum
500)
See Understanding how capacity rules work for messaging conversations and live chats.
- Capacities > Talk: Enter the number of call tickets that can be assigned to an agent at one time. Options are 0 or 1. If you choose 0, the agents cannot receive calls. Calls are no longer counted towards an agent's capacity after the wrap-up time ends, if configured, or after the agent hangs up.
- When you are finished, click Add capacity rule.
Your new capacity rule is displayed on the Capacity rules page and begins to work immediately.
Understanding how capacity rules work for messaging conversations and live chats
- The value you specify for Messaging capacity applies to both messaging conversations and live chats separately. If you specify a messaging capacity of 3, agents could be assigned up to 3 messaging conversation tickets and 3 live chats simultaneously.
- In conversations, there is a concept of active and inactive tickets. Zendesk defines a messaging conversation as inactive when an end user hasn't sent a reply in the last 10 minutes. However, admins can use the capacity release settings to modify this value and change the status of inactive messaging tickets.
- The omnichannel routing configuration contains a messaging activity routing
setting.
Messaging activity routing is off by default. When off, omnichannel routing counts only active messaging tickets towards an agent's capacity. This means agents can have any number of inactive messaging conversations and live chats assigned to them in addition to the specified capacity of active conversations. Customizing your capacity release settings can help you fine-tune agent capacity in this scenario. When an inactive conversation becomes active again, agents can exceed the specified capacity. Omnichannel routing won't assign them any new tickets for that channel until they have spare capacity again.
When messaging activity routing is on, omnichannel routing counts all open active and inactive messaging tickets towards an agent's capacity. Omnichannel routing assigns new conversational tickets to agents only when their total number of assigned messaging and live chat tickets, respectively, are below the specified capacity.
52 comments
Pascal Turmel
The point with Round Robin assignment is fairness in ticket assignment.. simply based on Capacity penalizes hard working engineers cycling through their tickets + can encourage bad behaviour (aka keeping tickets open longer than expected to avoid receiving the next one) . For the other point above how should round robin distribution be based.. we do mostly per day and per business week (for orgs with higher volume, an option for per hour should be provided), this is simply because ticket volume usually cannot be predicted and to even out distribution if there is a festive day preventing a group to receive tickets a particular day etc…
0
Pascal Turmel
Could we get another update / ETA from Product Management on the Round Robin feature for OmniChannel ? This is a basic feature one would expect Zendesk to have. At present, I cannot see how anyone can leverage the automated Omni-channel capacity for a fair distribution of tickets.
0
Barry Neary
Hi
Its looking like Q3, potentially Q4
-1
Pascal Turmel
Thanks - Could we be part of an EAP (Early Adopter Program) for this when it opens? We are on the verge of deciding renewal with Zendesk or not: This feature is a major roadblock at this stage for a Go or No Go further with Zendesk
0
Jed Hollander
Barry Neary that's disappointing. Frankly, this whole conversation is disappointing. The problem with the application as it's built now, is you're trying to determine how a company handles their day to day ticketing process when you know nothing of the variables that help inform a team if such a feature can be utilized. In reality, you should be providing a basic feature kit that is industry standard and THEN customize it. You're working backwards and we're been telling Zendesk for the last 3 years what we want out of this specific feature and you're still not listening. Forcing users to a 3rd party app that costs money that you're probably getting a kickback on, is greedy and not good optics.
Makes me think very hard on whether or not I want to renew this product this year.
-1
Barry Neary
Hi Pascal Turmel
We will likely go straight to GA with this.
0
James Skene
Hi
How do I exclude users from the capacity rules? I see no option to delete them?
Scenario: We have had to use an agent license for our Jira integration. We do not want any tickets to be assigned to this user. Is there a way to do this that does not involve a trigger?
Similarly, we have a lot of light agents who have all been allocated to the default capacity rule, if tickets cannot be assigned to light agents, why are they available to be added to Capacity Rules and included in the default, pre-configured rule where I cannot delete them?
Thanks
James
0
Barry Neary
Hi James Skene
You can create a capacity rule that has 0 max capacities for all channels, then assign the agent to this rule, This will ensure they wont be routed anything.
Its on our roadmap to exclude light agents from capacity rules
Barry
0
D.Fitz
We've got a scenario where agents are logging on in the morning, setting themselves online and finding that they have 10-15 Open tickets in their Home page due to customer replies. Their capacity is 5 by default, but this means that Urgent tickets (with an SLA First Reply Time of 1 hour) aren't getting assigned by omni-channel until the number of replies in Agent Home has dropped below 5.
Is there any way to work around this, i.e. prioritise new tickets with certain criteria or differentiate between New and Open tickets?
0
Barry Neary
Hi D.Fitz
One option is to reassign tickets that are reopened while the agent is offline. Another would be to increase the max capacity for these agents. A third could be for agents to change the status of their lower priority tickets to on hold so they can be assigned new higher priority tickets and then go back to the other tickets lster
0
Mayra
I have a question regarding the capacity:
I'm creating a rule for premium service, and for that we want agents to take only 5 tickets (tickets here being considered talk + messaging + email) at a time. So, let's say that, one of the agents are currently on a call, he can get 4 other tickets (messaging or email) but will only receive a new ticket (could also be a call) after the current call is done. Is there a way to do that?
0
Barry Neary
Hi Myra, currently the capacity is per channel rather than across all channels. This has been logged as a potential roadmap item. Barry
0
Jimmy Rufo
Hi All,
I've opened a support ticket on this, but as I only want to apply an OCR rule for one group of agents (8 to be exact), does anyone know if is there a way to ensure all other instance full agents are not part of the OCR configuration? My plan is to deploy this for one use case, that would apply to one specific ticket group. I ensured the capacity rule I wanted only had 8 agents, and wanted to delete the other default rule that had 300+ other agents, but it forced a move of those 300+ agents to my other rule. I don't want those 300+ agents involved at all.
0
Barry Neary
Hi Jimmy Rufo
You can have two rules - one for the 8 agents and the other for the rest. The one for the rest: if you set capacity to zero for this one then these other agents wont be automatically assigned tickets
0
Jimmy Rufo
Thanks Barry Neary , that makes sense, and I will try it.
0
Tina
Hi Barry Neary, regarding your comment reply to D. Fitz on Nov 5. Are there any plans in the future to implement some improvements to cater for this scenario? It would be nice to have some configuration on these tickets that were already replied to that were there before agent signed in (to automatically move to On-Hold so they can receive the more time pressing tickets) or another method.
Currently we are experiencing a similar problem and we've set up some automations to unassign tickets after being held for some time and changing priorities when the SLA is about to breached, though it is more of a workaround for now. Increasing the capacity isn't really the best solution since:
- If people sign on too early, they get all the nearly SLA breached tickets. Even though who sign on a few minutes afterwards may not get some of that workload and they would need to wait for a team leader to sign on to reassign tickets manually.
- Or people who sign on a little later may not receive any tickets since everyone has higher capacity. They need a team leader to reassign tickets to them manually.
Thanks.
1
Jimmy Rufo
Hi Barry Neary , for the rule with the 300+ agents with 0 capacity, would those agents have to adjust to having to set an agent status when navigating to the agent interface? Since they are not going to be active for OCR at this time, I would want to ensure they don't have to adhere to a workflow that is irrelevant to them, and could prevent them from receiving tickets.
0
Barry Neary
HI Jimmy Rufo
Those agents with zero max capacity will not be assigned tickets, independent of what their agent status is set to. So those agents can just ignore their agent status
Barry
0
Jimmy Rufo
Hi Barry Neary ,
I think there is a misunderstanding here. The ~200 agents not using OCR will still NEED to be assigned tickets, just not in an OCR capacity, if that makes sense. The tickets would get assigned manually to them or via transfer of ticket to their ticket group. In that respect, I'd want them to not have to worry about agent status and receive tickets manually as they always had. I have only 8 agents or so that I want to test OCR with, and dealing with the other 200 agents is proving problematic. I'd love to speak with someone close to this feature to find a way to get this implemented, as I've had so many stops and starts.
0
Barry Neary
Hi Jimmy Rufo
Sorry for the confusion: the agents with zero capacity can still be assigned support tickets manually either self assiginging from views or being manually assigned tickets from supervisors. Its the routing engine that will not assign them tickets
0
Jimmy Rufo
Hi Barry Neary ,
My recent concern was specific to agent status toggling, of which there is no documentation regarding if they will default to “Online”, “Offline”, if a default can be set for agents in a particular capacity rule, etc. I know we are meeting on Monday, so may be best to clear this all up early next week. Thanks.
0
Jimmy Rufo
Hi Barry Neary , thanks for the update today. If you or Cory Vegel could refer to me to the post discussing the feature to “stagger” OCR related ticket assignments over time, that would be great!
0