Zendesk Omnichannel Routing: The Two Capacity Numbers

What it replaces

Group assignment answers one question: which group owns this ticket. It has nothing to say about which person, or whether they're already busy. Triggers can push a ticket to a group, and then it waits in a view for someone to pick it up.

Omnichannel routing answers the second question. It looks at who is online, what their capacity is, how much they are currently holding, and assigns directly to a person. It covers email, messaging and Talk from the same logic, which is where the name comes from.

That's a genuine improvement in a busy queue. It also means the system now has an opinion about how much work a person can hold, and that opinion ships set to 1.

One thing to say plainly before the findings, because it makes them more useful rather than less. The instance is a Zendesk sandbox we control, and nobody had touched its routing before we switched it on. That is exactly why the defaults below are worth reading: they are what Zendesk hands you, unshaped by any admin's earlier decisions.

The default state, recorded

We turned omnichannel routing on and read the account settings back immediately. Nothing below was customized, this is what the checkbox alone gives you.

routing.enabled            true
assignment_method          highest_spare_capacity
max_email_capacity         1
max_messaging_capacity     1
skills_enabled             false
reassignment_messaging     true, 30 second timeout
queues                     0
autorouting_tag            auto_route_ocr

Those two capacity values look alarming. An agent who can hold 1 email ticket at a time would stall any real queue. So we opened the Capacity rules page to see it in the interface.

It says something different. The Initial capacity rule, preconfigured by Zendesk and applied to 6 assignees, sets Email 5, Messaging 3, Talk 1. That is the rule in force. The API's max_email_capacity: 1 is not what your agents are working under.

Two things follow, and both matter more than the original numbers.

The two figures live behind different endpoints, and the obvious one is the wrong one. max_email_capacity sits in the account settings object, under routing. Reading it as an account-wide ceiling is an inference from where it lives, not something the reference states outright, and it is worth holding loosely. The rule that governs your agents is a separate object served by the Capacity Rules API at /api/v2/capacity/rules, note the slash, which is where we kept typing an underscore. We initially guessed capacity_rules, routing/capacity_rules and omnichannel/capacity_rules, got 404 from all three, and briefly concluded no endpoint existed. It does. Guessing a REST path and reasoning from the 404 is how you end up confidently wrong, and it's the same failure this post is about.

Query the documented endpoint and you get the real figures:

GET /api/v2/capacity/rules

[{ "name": "Initial capacity rule",
   "description": "This rule was preconfigured by Zendesk to start with",
   "default": true,
   "assignees": { "count": 6 },
   "capacities": { "email": 5, "messaging": 3, "voice": 1 } }]

Same account. Two endpoints. Two answers.

So the practical rule is: audit capacity against /api/v2/capacity/rules, not against account settings. An audit script pointed at the settings object reports 1 and is wrong by a factor of 5.

Capacity is a preference, not a ceiling. Zendesk states it on the Capacity rules page: "Agents can always pick up more than their capacity," and the documentation confirms it, "it's still possible for agents to exceed the specified capacity by manually assigning work in excess of the limits." Routing uses the number to decide who gets the next ticket. It doesn't stop anyone taking more.

Why tickets sit unassigned while agents look idle

This is the most common symptom, and it usually has one of five causes.

No group is assigned. For group-based routing, which is what Team and Growth get and what the standard queue uses, this is Zendesk's first requirement and the easiest to overlook: tickets must have a group assigned before routing will touch them. A ticket with no group sits still no matter how much capacity is free.

Everyone is at capacity. With the default rule that is 5 concurrent email tickets each. Check the rule, not the API field.

Nobody's in a routing-eligible status. Routing reads agent status. Being logged in is a separate thing. An agent who never sets one isn't a candidate.

Email tickets are missing the auto-routing tag. This one catches everybody. Talk and messaging route automatically, but an email ticket has to carry the auto-routing tag to enter the standard omnichannel queue. On our instance that tag is auto_route_ocr. If no trigger applies it, email tickets never enter routing and just sit in their group.

No queues exist. We had 0 custom queues, which means no custom routing rules, so everything falls back to default behavior.

The three settings to change first

1. Read your actual capacity rule before changing anything. Open Capacity rules in Admin Center rather than querying the API. Capacity rules apply to a set of assignees rather than to a group, which is why the screenshot above reads Assignees 6. You set different numbers per rule and pick who it covers, so a team handling long investigations can sit lower than one doing quick replies.

2. Create the auto-routing trigger before you expect email to route. A trigger that adds the auto-routing tag on ticket creation is the piece that connects your email channel to routing. Without it, you have switched routing on for messaging and Talk only, which is a confusing half-state to debug.

3. Decide whether you need queues at all. Queues let you route to a primary group and fall back to a secondary one after a wait. They're worth building when you have real overflow behavior to express. With 1 group, like the instance here, the default configuration is fine and a queue adds nothing.

What your plan actually gives you

One thing to settle before you plan around queues, because it changes the advice. Zendesk splits this by tier: on Team and Growth "omnichannel routing uses group-based routing", while on Professional and Enterprise "you can choose between using custom queues or group-based routing with the standard omnichannel routing queue". So custom queues are a Professional-and-above tool. If you are on Growth, the section above about deciding whether you need queues does not apply to you, and the auto-routing tag is the only path email has.

The incentive behind the gap

Two capacity numbers exist in two places and Zendesk's own help documentation reconciles them nowhere. Both are individually defensible: a conservative account-wide fallback can't be accused of burying an agent on day one, and a starter rule of 5 gives a usable out-of-the-box experience.

The incentive worth naming is which of the two gets the attention. Capacity rules are part of omnichannel routing, the newer thing Zendesk wants accounts to adopt, so that surface gets the interface, the documentation and the authoritative value. The older field in account settings is left in place because removing it would break whatever already reads it. A vendor is rewarded for making the new feature work well and is rewarded not at all for maintaining a signpost on the old one.

The cost of having both lands on you, quietly. Nothing in either surface says "this figure is superseded", the field names don't hint at a hierarchy, and the endpoint that returns the authoritative value is one most people would not guess. An admin auditing capacity the fast way gets a confident, wrong answer with nothing to indicate it. That isn't a vendor being dishonest. It's a vendor documenting two features separately and never writing the paragraph that connects them.

Checking the state without clicking through

The whole routing configuration comes back in one request, which is faster than the interface and gives you something you can diff after a change:

GET /api/v2/account/settings.json

The routing object holds enabled, assignment_method, skills_enabled, the reassignment timeouts and autorouting_tag. All of those are trustworthy.

Worth separating two things that get discussed together. Omnichannel routing decides who a ticket goes to and how much of their capacity it consumes. Deciding what a ticket is, so it reaches the right group in the first place, is a different job, and our guide to AI ticket routing and triage covers that side. Capacity rules will happily distribute mislabeled tickets evenly. See our Zendesk API guide if you have not used the endpoint before.

The two capacity fields in that object are the exception. On our instance they reported 1 while the applied rule said 5, so read capacity from /api/v2/capacity/rules instead, or from the Capacity rules page in Admin Center, which shows the same values.

Common questions

Why are my Zendesk tickets not being assigned? Check the capacity rule in Admin Center first (the default rule is Email 5, Messaging 3, Talk 1), then agent statuses, then whether email tickets carry the auto-routing tag.

Why does the API say my capacity is 1? Because you're reading the wrong object. max_email_capacity lives in the account settings object; the rule actually applied to your agents is served by the Capacity Rules API at /api/v2/capacity/rules. On our instance those two disagreed, 1 against 5.

Does omnichannel routing work for email? Yes, by one of two routes. With the standard queue, an email ticket has to carry the auto-routing tag before it is picked up, which a trigger applies. With custom queues the tag stops being a requirement, and Zendesk routes email, messaging and calls to whichever queue they match. A ticket matching no custom queue is not simply swept into the standard one. Zendesk says such tickets "still require a group assignment, and email tickets also require the auto-routing tag, before they can be routed by omnichannel routing through the standard queue". Messaging and Talk route automatically either way.

What is the difference between queues and groups? A group is who owns the work. A queue is a routing rule that can send work to a primary group and fall back to another after a wait.

Does omnichannel routing affect SLAs? Not directly. It changes who gets the ticket and when, so it changes whether SLA targets are met, but the policies themselves are evaluated independently.

Can I turn it off again? Yes. Note that Zendesk documents the disruption for turning it on: the moment it is enabled, every agent is set offline and prompted to choose a new status. Plan the switch for a quiet hour on that basis.

Where an AI layer fits

Routing decides which person receives a ticket. It has no opinion about what the ticket says, which is why a well-routed queue can still be a big one.

Macha runs on top of the Zendesk you already have. It reads the ticket, including custom field values and attachments, and can classify it, write fields back, add an internal note, or post a public reply, using your existing triggers and webhooks as the entry point. In routing terms that matters because a ticket classified and enriched before assignment reaches the right person with the context already attached. It suits teams whose routing is sound and whose queue is simply longer than the people in it can work. Setup runs through the Zendesk integration, and billing is per ticket, so one thread with one person is one charge however many replies it takes.

Start your free trial and connect your Zendesk in a few minutes.