ServiceNow Skills and Routing Explained

What Skills and Routing Do

Skills and routing are systems for matching work items to people based on their capabilities and current workload. Skills define what abilities a person or team possesses: technical knowledge, language abilities, certification, or domain expertise. Routing logic evaluates available skills and assigns work to people who have the required skills and capacity to handle it. Effective routing gets work to the right person quickly, improving customer satisfaction and ensuring that work is handled competently.

Routing can be simple or sophisticated depending on organisational needs. Simple routing might assign all incidents to a group regardless of skills. Sophisticated routing considers required skills, team member skills, current workload, location, language preferences, and other factors. Better routing decisions improve efficiency and customer outcomes.

Where Skills and Routing Live in ServiceNow

Skills are defined in the Skills table and assigned to users or groups. Routing rules are defined in the Routing Rules application. Each routing rule evaluates work items and matches them to people based on criteria. Rules can be sequential, meaning the system evaluates them in order and uses the first rule that matches. Rules can also be evaluated together, allowing more complex logic.

Different types of work can have different routing logic. Incidents might be routed based on technical skills and current queue depth. Change requests might be routed to managers based on impact area. Service requests might be routed based on service category and language preferences. Each work type can have its own routing strategy.

Skills can be assigned at the user level, the team level, or both. A user might have specific skills, and their team might have skills that are assumed to be held by team members. Routing logic can consider skills at both levels when finding available resources.

A Worked Example: Technical Support Routing

A support team handles requests for different products. Some team members are skilled in product A, others in product B, others know both. When a request comes in, routing logic identifies what product the request concerns, then finds a team member who has skills for that product and has available capacity.

If no team member with required skills is available, routing logic might queue the request for the next available person with required skills, escalate to a more experienced team member, or assign to someone with partial skills and notify them that they might need assistance. Different organisations have different strategies.

Over time, routing history shows which team members handle different types of requests. Managers use this data to identify skill gaps, plan training, and balance workload. If one team member always gets specific request types, that might indicate they have unique skills, or it might indicate that routing rules are biased toward that person.

Common Misunderstandings About Skills and Routing

A frequent misunderstanding is thinking that routing is purely technical matching. While skills are important, other factors affect good routing: workload balance, team member preferences, development opportunities, and schedule constraints. Technical matching is only part of effective routing.

Another confusion is assuming that all skills can be formally defined and assigned. Some skills are obvious like programming language knowledge or product expertise. Others are subtle like communication ability or customer sensitivity. Routing systems work best with clearly defined skills. Fuzzy skills are harder to route on.

Some organisations incorrectly assume that routing rules are set once and never changed. In reality, organisations should review routing effectiveness regularly and adjust rules as team capabilities change, new products are introduced, or workload patterns shift.

Optimising Skills and Routing

Effective skills and routing starts with clear skill definitions. Skills should be specific enough to be meaningful but not so granular that assignment becomes impossible. A skill like troubleshooting is too broad. Skills like troubleshooting email servers or troubleshooting network connectivity are more useful.

Skills should be reviewed and updated regularly as team members develop new abilities. Someone who has been troubleshooting a product for years has deeper skills than someone just trained. Skill levels can be captured by assigning proficiency ratings: novice, intermediate, expert. Routing can then consider proficiency when matching work.

Workload and availability are as important as skills for effective routing. A highly skilled person with no available capacity is not a good match for urgent work. Routing should balance skill requirements against workload distribution. Over time, this approach improves both quality and team member satisfaction.

Start by checking whether routing is the constraint

When work sits too long before someone picks it up, the instinct is to add skills and routing rules. That response assumes the delay is a matching problem, and often it is not. Work can wait because nobody is assigned to the queue at the hours it arrives, because the group that owns it has too few people, or because the triage step asks for information the requester has not provided. Routing cannot fix any of those. Before designing a routing model, look at the time each item spends in each state, and check whether the wait is spent before assignment, after assignment or while waiting on the requester.

Customer-facing cases have their own pressures, which the customer service case routing guidance covers. Routing earns its cost when the work is varied enough that a person who receives the wrong item loses real time, and when there are enough specialists that matching them to items is a meaningful choice. Below that level, a well-run queue with a clear triage owner is often cheaper to maintain and easier to explain.

Comparing the bases for routing

Routing can key off different information, such as the assignment group an item belongs to or the skills of the person who should take it, and each basis fails in its own way. The table is a practical guide to choosing one as the primary basis, with others used only as tie-breakers.

The bounce between groups is the failure that can do the most damage to trust. Each reassignment resets the requester’s view of progress, and the item often loses context on the way.

Building a skill taxonomy that people will maintain

Skill taxonomies tend to start too detailed. A long list of narrow skills looks precise, but nobody keeps it accurate, and the routing rules built on it inherit every stale entry. A workable taxonomy is built from the work itself rather than from an org chart, and it is reviewed at a set interval by the people who receive the work.

1. Export the last period’s closed items and group them by the outcome required, not by the system they touched.
2. Identify the groupings that required a different person to resolve them, and call those the candidate skills.
3. Remove any candidate skill that no one currently holds, and merge any two that the same people always share.
4. Assign a proficiency level only where a routing rule actually uses it, since an unused level adds maintenance without changing any assignment.
5. Name an owner for the taxonomy and set a review date, and log each change with the reason it was made.
6. Test the taxonomy against a sample of recent items and check that each one would have reached someone able to resolve it.

Overflow, escalation and the loops they create

Overflow rules are where routing can quietly go wrong. A rule that sends work to a second group when the first is busy is sensible until the second group sends it back when it is busy too. The item then cycles between groups, each one assuming the other is handling it. Prevent this by giving every overflow path a final owner, and by recording the reason for each transfer so that a loop is visible in the data rather than discovered by a complaint.

Specialists also need protection from becoming the only route. When routing always sends a particular kind of item to the same person because they are the only one with the skill, the rest of the group never learns it, and the single point of failure grows. Rotating some of that work to a second holder of the skill, even at a cost in speed, reduces the risk when that person is away.

Testing routing before it reaches real work

Routing rules are easy to test in a way that matters. Take a set of recent items with known outcomes, run them through the proposed rules, and check whether each would have reached someone with the right skill and available capacity. Items that would have routed wrongly show which rule needs changing. Repeat the test with a set of items from a quiet period and a busy one, because load-based rules often behave differently under pressure than they did on paper.

The check the team should not skip is who ends up with the work. A rule that is technically correct can still concentrate work on the most experienced person in a way that the group will not sustain. Looking at the distribution of assignments over a month is the simplest way to see that before it becomes a staffing argument.

When manual triage is the better answer

Routing automation is not always the right answer. Where the volume is low, where the work requires judgment that a rule cannot capture, or where the items are rarely similar enough to match, a named triage person who assigns work each morning is clearer and more accountable. The escalation criteria and support handoff guidance covers how to make that manual step explicit so it does not depend on one person’s memory. Automation can then be introduced later for the part of the work that has proved predictable.

Questions about skills and routing

How many skills should a person hold?

Enough that the routing rules can find a second person when the first is unavailable, and few enough that each skill has a clear owner. Someone holding most of the skills in a group can be a sign that the taxonomy is too coarse to separate people, or that the group is under-resourced for its work.

Should skill ratings be used or only skill presence?

Use ratings only if a rule will act on them. If the routing only asks whether someone can handle an item, presence is enough. A rating that sits unused in a profile will drift out of date and mislead anyone who reads it later.

How should routing handle items that match no skill?

Send them to a named triage owner rather than to a general pool. A general pool can become a place where items wait for someone to notice them, and the requester experiences that as the system ignoring them.

Does routing need to be reviewed after a reorganization?

Yes, and it should be reviewed before the reorganization takes effect, not after. Groups, skill holders and shift patterns are the inputs routing depends on, and a change to any of them can silently leave work without an eligible owner.