Skill-Based Routing: Simpler to Say Than Do

Skill-based routing sends each contact to the agent best equipped to resolve it, and it’s only ever as good as the data you route on. Get the data right and it lifts first contact resolution. Get it wrong and you’ve built a very efficient way of sending customers to the wrong person. I first wrote about skill-based routing back in 2008, in a post on building a tiered call centre schedule, and my one-line summary then still holds: simpler to say than to actually execute. The concept takes a sentence. The execution touches your customer data, your phone system, your staffing maths and your training plan, and a weakness in any one of them shows up as transfers. Customers feel every one of those transfers, even when your dashboard only shows a slightly longer handle time. This post is about the parts that sit behind the sentence, including the one that surprises most teams: what every extra skill costs you in headcount.

What is skill-based routing actually deciding?

Every routing rule answers one question: who should take this contact? The easy example is language. A French-speaking customer with a data problem should reach your agent in Montreal (or France, for that matter), not an agent in an English-speaking centre who’ll end up transferring them. Technology is the next layer. If only some of your people can support a particular product, contacts about that product need to find them. Tier is a skill too. Your Tier 2 agents are the first rung of your escalation matrix, and routing complex issues straight to them can skip a pointless first touch. Then there’s customer value. As I’ve covered in my 80/20 rule posts, a small share of your customers usually drives most of your revenue, and tiering your customers and your support levels lets you give that group a different path. Skills-based routing is how that path gets enforced on the phone system rather than on a slide. Each of these is a legitimate reason to route. The trouble starts when you use all of them at once.

Stack language, product, tier and customer value together and a two-language, three-product, two-tier operation already has twelve possible combinations before you add a VIP flag. Each combination is its own queue, with its own agents and its own wait time. Some of those twelve will get a handful of contacts a day, and somebody still has to be scheduled against each one. Others will overlap so heavily that nobody on the floor could tell you the difference between them. Before you build a combination, ask what goes wrong for the customer if that contact lands with the general queue instead. If the honest answer is nothing much, it doesn’t need a queue of its own. You can find the full list of what I’ve written on this under skill-based routing, but the principle is short. Route on the skills that genuinely change the outcome for the customer, and nothing else.

Where does the routing data come from?

Skill-based routing allows a lot of granularity and focus, but it depends entirely on what you know, or what the customer tells you. There are really only two sources. The first is your customer database: you recognise the number or the account, and you already know their language, their products and their tier. The second is your ACD (Automatic Call Distribution) menu, where the customer is responsible for deciding what problem they have and pressing the right button. Both fail in predictable ways. Database records go stale when a customer changes products or a new contact joins their team. Menus rely on customers diagnosing their own problem, and most of them will press whichever option sounds closest or simply hit zero. A misrouted contact has to be transferred. Every transfer adds handle time, puts the customer back in a queue, and takes a first-contact resolution off the board, which is why transfer rate belongs next to FCR on your support metrics.

Look at your transfer data before you add a single new routing rule. If a large share of transfers go from one skill queue to another, the routing isn’t broken. The data feeding it is. Fix the menu wording, clean up the account records, and give agents a quick way to correct a customer’s skill tag when they spot it’s wrong. Then check the menu itself by listening to a sample of calls that went to the wrong queue and asking what the customer thought each option meant. It’s usually obvious within a dozen calls. The option labels were written by someone who knows the product, not by someone calling in with a problem. That work is dull. It also does more for resolution than any new routing layer.

What does every extra skill cost you?

This is the part most teams don’t see coming. Splitting one queue into two costs you agents, even when the call volume doesn’t change. Take the example I worked through in my Erlang C post: 96 calls an hour at a three-minute handle time, with a target of 80% answered in 20 seconds. As a single pooled queue that needs 8 agents, which gets you to 90%. Now split the same 96 calls into 72 English and 24 French. The English queue needs 6 agents and the French queue needs 3, so you’re at 9. Split them evenly, 48 and 48, and it’s 5 plus 5, which is 10 agents for exactly the same calls. The Erlang C formula rewards big pools, because a big pool absorbs random spikes that a small one can’t. Every skill you add is a smaller pool.

Scheduling gets harder at the same rate. Every skill needs its own required, actual and gap rows, and a gap in a two-person French queue at 4pm is invisible if you only look at the total. Shift swaps have to match skill for skill, and sick cover gets harder to find. Standard Erlang C takes no account of agent skills at all, which is why multi-skill operations eventually need proper workforce management software to plan them. The way out is training. Every agent who can take a second skill turns two small pools back into one bigger one, and that’s one of the most practical arguments I know for investing in training. Expect some resistance when you change who takes what; agents build routines around their queues, and handling that change openly matters as much as the routing rules. A skill should earn its queue.

Frequently Asked Questions

What is skill-based routing in a contact centre?
Skill-based routing sends each call, email or chat to an agent with the right skills to resolve it, such as a language, a product or a support tier. It uses customer data or the customer’s menu choices to decide where the contact should go. The goal is fewer transfers and more issues fixed on the first contact.

Does skill-based routing need more agents?
Usually, yes. Splitting one queue into several smaller ones reduces pooling, so you need more agents to hit the same service level. In the worked example above, 96 calls an hour need 8 agents in one queue but 10 when split evenly into two.

Why do skill-based routing projects fail?
Most fail on data rather than technology. Stale customer records and confusing phone menus send contacts to the wrong queue, which creates transfers. Too many skills also fragments the team into small queues that are hard to staff.

How many skills should I route on?
Only as many as genuinely change the outcome for the customer, such as language or a specialist product. Start with the fewest skills that prevent transfers and add more only when transfer data shows a clear need. Cross-training agents on a second skill lets you keep queues larger.

Hutch Morzaria

Hutch Morzaria is a CX and Support Leadership professional with 19 years of experience building and leading support organizations across SaaS, Fintech, and enterprise technology. He has held Director-level roles at Q4 Inc, AudienceView, Johnson Controls, and others, and holds ITIL Expert certification across V3 and V4.