Zendesk Skills Based Routing: Skill Based Routing Setup, Agent Skills, and Skills Timeout

Does Zendesk have skills based routing, and what plan do you need?

Yes, and there are two of them. Zendesk documents standalone skills-based routing and skills in omnichannel routing as separate features, and the gate on both is the same: Suite Professional, Suite Enterprise, or Suite Enterprise Plus, or, if you are on a standalone Support plan rather than a Suite, Support Enterprise. That second clause catches people out more than the first. A Support Professional account has no skills at all, and the jump to Support Enterprise is a bigger step than most teams expect when the only thing they wanted was to send Spanish tickets to Spanish speakers.

Everything else is shared. Skills live in Admin Center under Objects and rules, then Business rules, then Skills. You build skill types as categories and skills inside them, so a Language type holds Spanish, German, and Japanese while a Product type holds the three things you sell. Assigning skills to agents can be done in bulk from the Skills page, where you can select up to 50 agents at a time to add or remove from a single skill, or one at a time from the sidebar of an agent profile. That bulk limit matters if you are onboarding a class of forty new agents and re-skilling an existing team in the same week.

Standalone skills-based routing does not assign anything

This is the single most expensive misunderstanding on the page, so it is worth being blunt. Standalone skills-based routing is a sorting feature. It attaches required skills to tickets, then makes those tickets findable through views, and the agent still has to go and take one. Nothing is pushed. If your reason for buying skills was to stop agents cherry-picking, standalone skills-based routing will not do it, because picking is the entire mechanism.

Two view styles exist. A skills-based condition view, which Zendesk recommends, shows each agent the tickets whose skill requirements match the skills that agent holds, and it works per agent from a single shared view definition. A skills-match view filters to the same idea but comes with hard limits: only one skills-match view is permitted per Support instance, it displays a maximum of 30 tickets, and it can time out on large data sets. Closed tickets are excluded from condition-based views entirely, which is fine day to day and confusing the first time somebody goes looking for an old ticket.

The channel coverage is narrower too. Standalone skills-based routing reaches email, web form, side conversations, and the API. It cannot route voice or messaging. And there is a stale-data catch worth writing on a sticky note: skills applied through routing rules do not update if the ticket conditions change later. A ticket that arrives as a billing question and turns into a technical escalation keeps the billing skill.

Skills in omnichannel routing: the version that actually pushes work

Omnichannel routing is the engine that assigns. It takes email, messaging, Talk calls, and eligible chats, puts them in a queue, and offers or assigns each one to an agent based on status, capacity, priority, and skills together. Skills are one input among several rather than the whole rule, which is the right design: a perfect skill match who is already at capacity is not the right answer.

Skills get onto tickets through triggers, not through a dedicated skills rule engine. You write a trigger with an add-skills action, condition it on whatever tells you the ticket needs that skill (the form, the brand, a custom field, the requester organization), and mark each skill as required or optional in the same action. Because triggers run on ticket creation and on update, a ticket that changes character can have its skills re-stamped, which is exactly the gap standalone routing leaves open.

The practical consequence of putting skills behind triggers is that your skill logic and your routing logic live in different places. The queue decides eligibility by group and conditions. The trigger decides which skills the ticket demands. When something is not routing, you have to check both, and the usual culprit is a trigger that never fired because its conditions did not match, not the routing configuration everybody looks at first.

Skills timeout and skill priority: how a requirement gets dropped

Every skill on a ticket carries a priority, and the priority decides whether it can ever be abandoned. Zendesk exposes four values, and the developer docs give the exact syntax: the priority is appended to the skill UUID after a hash, in the shape skill_uuid#priority, so a trigger action holds something like ["ea535736-d36b-45d2-a00e-14a274588c87#1","eb3306b5-182a-4dfe-8501-e62a270e7012#0"].

0 is required. It is considered on every routing decision and it never expires. 1 is optional high priority and expires last. 2 is optional medium priority and expires next. 3 is optional low priority and expires soonest. If you do not set a priority, Zendesk applies 1, which means a skill you thought was mandatory is quietly optional. That default is responsible for a good share of the tickets that end up with the wrong agent.

The skills timeout is what triggers the dropping. Defaults are one hour for email, 30 seconds for messaging, and 30 seconds for Talk calls. When the threshold is reached, omnichannel routing sheds optional skills from lowest priority upward and assigns to whoever is available on status and capacity alone. For messaging and calls there is an extra condition: a timeout can only occur if no agent with the matching skills has been available, meaning online with spare capacity, for the whole duration. So a specialist who is online but full does not stop the clock in the way people assume.

Think about what this means for the queue you care most about. A one hour email timeout on a compliance queue means that after sixty minutes the compliance requirement evaporates unless you set it to priority 0. Setting everything to required removes that risk and creates a different one, since a required skill nobody free holds means the ticket does not move at all.

The limits that bite once you are past a hundred agents

The caps are generous at first and then they are not. You may define up to 10 skill types, each holding up to 30 skills. Ten types sounds like plenty until you map a real support organization: Language, Product, Tier, Region, Brand, Certification, Channel, Integration, Customer segment, and Escalation level is exactly ten, and you have not left room for the next thing anybody asks for. Thirty skills inside a type is the tighter constraint in practice. A company with forty SKUs cannot put each one in a Product type, so somebody starts grouping SKUs into families, and the routing gets coarser than the business wanted.

The other limits are smaller but worth knowing before you design around them. Only one skills-match view per Support instance. That view shows at most 30 tickets. Bulk skill assignment handles 50 agents at a time. And the skills model itself is flat: a skill is held or it is not, with no proficiency level, so you cannot express that one agent is a strong German speaker and another is passable. Teams work around that by creating German and German-native as separate skills, which spends two of your thirty.

When a routing layer beside Zendesk is the cheaper answer

Zendesk omnichannel routing with skills is a competent engine and if you are already on Suite Professional or above, it is running well, and your skill map fits inside ten types, adding anything to it would be waste. Use what you paid for.

The case for a layer beside Zendesk is specific. It is strongest when the only reason for a Suite Professional or Support Enterprise upgrade is skill matching, because the per-agent difference across a fifty-agent team is a real budget line. It is strong when you have hit the type or skill ceiling and are grouping distinct products together to fit. It is strong when dropping a skill at a timeout is unacceptable and you need a named fallback tier instead of an expanding pool. It is strong when capacity has to be enforced rather than advisory, since Zendesk capacity rules do not stop an agent assigning themselves work beyond the limit. And it is strong when the same people also take CRM leads or internal requests, because nothing inside Zendesk can see that work.

Assigner sits beside Zendesk rather than replacing it. Zendesk stays the system of record and keeps the ticket, the macros, and the reporting. Assigner decides who, using skills, enforced load, availability, and true circular round robin rather than idle-time ordering, and it records the rule that made each decision so the answer to why did this go to her is one line rather than an audit trail.

Does Zendesk have skills based routing?

Yes, in two separate forms. Standalone skills-based routing tags tickets with required skills and surfaces them in views, so agents pull the work themselves. Skills in omnichannel routing is the version that actually assigns work, combining skills with agent status, capacity, and priority across email, messaging, and Talk. Both require Suite Professional or above, or Support Enterprise on a standalone Support plan.

What plan do I need for Zendesk skills based routing?

Suite Professional, Suite Enterprise, or Suite Enterprise Plus. If you are on a standalone Support plan rather than a Suite, skills require Support Enterprise, so Support Team and Support Professional accounts have no skill matching at all. Suite Professional was listed at $115 per agent per month billed annually in August 2026, which makes skills an expensive single feature to unlock.

What is the difference between standalone skills based routing and skills in omnichannel routing?

Standalone skills-based routing sorts, omnichannel routing assigns. Standalone attaches skills to tickets and filters them into views for agents to pick from, covering only email, web form, side conversations, and the API. Skills in omnichannel routing pushes each ticket to a matching agent who has capacity, and covers messaging and Talk calls as well as email.

How many skills can you have in Zendesk?

Up to 10 skill types, with up to 30 skills inside each type. A skill type is the category, such as Language or Product, and the skills are the values inside it. The 30 per type limit is usually the one that bites first, because a company with more than thirty products cannot give each one its own skill and has to group them into families.

How do skills get added to a ticket in Zendesk?

Through triggers, using an add-skills action. You condition the trigger on whatever indicates the ticket needs that skill, such as the form, the brand, a custom field, or the requester organization, then list the skills and set each one required or optional. Triggers run on ticket creation and on update, so a ticket that changes character can have its skills re-stamped.

What is the Zendesk skills timeout?

It is the period omnichannel routing will hold a ticket waiting for an agent with the required skills before it starts dropping optional skills. The defaults are one hour for email, 30 seconds for messaging, and 30 seconds for Talk calls. When the threshold is reached the optional skills stop being considered and the ticket goes to whoever is available on status and capacity alone.

What are the Zendesk skill priority values?

There are four, appended to the skill UUID after a hash in the form skill_uuid#priority. Priority 0 is required and never expires. Priority 1 is optional high and expires last. Priority 2 is optional medium. Priority 3 is optional low and expires soonest. If you do not set a priority, Zendesk applies 1, so a skill you assumed was mandatory is actually optional.

How do I stop Zendesk dropping a required skill?

Set that skill to priority 0 in the trigger action. Required skills are considered on every routing decision and never expire, so a ticket needing a certified agent will wait rather than fall through to somebody who is merely free. The trade is real: if nobody holding a required skill ever becomes available, the ticket does not move, so required skills need a monitoring view behind them.

Can Zendesk skills based routing handle skill levels or proficiency?

No. A Zendesk skill is binary, held or not held, with no proficiency rating attached. Teams that need levels usually create separate skills for each level, such as German and German-native, and route to the stronger one first with the weaker one as an optional lower-priority skill. That works, but each level consumes one of the 30 skills allowed inside a type.

Why is my Zendesk skills based routing not assigning tickets?

Check which feature you actually enabled first. Standalone skills-based routing never assigns anything, so if that is what is switched on the behavior is correct and the fix is omnichannel routing. If omnichannel routing is on, the usual causes are a trigger whose conditions never matched so no skill was applied, agents who do not hold the skill, agents not in an online status, or every matching agent already at capacity.

Do Zendesk skills work on reopened or updated tickets?

It depends which feature applied them. Skills applied by standalone routing rules do not update if the ticket conditions change later, so a ticket that shifts from billing to technical keeps the original skill. Skills applied by triggers can be re-stamped, because triggers run on update as well as creation, but only if you wrote the trigger to fire on that update.

Can I route by skill on Zendesk Support Team or Suite Team?

Not with native skills, which start at Suite Professional or Support Enterprise. The two options are to upgrade the plan or to run a routing layer beside Zendesk that reads the ticket and assigns the agent while Zendesk stays the system of record. Assigner takes the second route, adding skill, workload, and availability rules without changing your Zendesk tier.