Skills-Based Routing: Build Queues That Reach the Right Agent

Skills-Based Routing: Build Queues That Reach the Right Agent

A routing rule can be technically correct and still make service worse. Imagine a twelve-person support team where every difficult billing call is directed to the same two experts. The match looks intelligent, but those agents accumulate a long queue while capable colleagues wait for work. Customers hear hold music, supervisors interrupt specialists, and the supposed efficiency becomes a bottleneck.

Skills-based routing (SBR) needs more than a list of agent abilities. It needs rules for eligibility, proficiency, presence, capacity, waiting time and escape paths. This guide explains how to build a practical model for a small or mid-sized contact centre, test its failure cases and keep it useful after launch.

What skills-based routing should decide

Skills-based routing is a method of assigning customer interactions to agents whose recorded capabilities match the work required. It can apply to voice calls, chats, messages, emails and cases. A skill might represent product knowledge, language, regulated-work authorisation or the ability to handle a particular customer need.

An automatic call distribution (ACD) system places incoming calls into queues and distributes them according to configured rules. SBR adds agent attributes to that decision. Instead of sending the next call merely to the longest-idle person in a queue, the routing process asks which available people are suitable for this particular interaction.

Contact centre as a service (CCaaS) describes cloud-delivered contact-centre software. Many CCaaS products include routing capabilities, but the operating principles in this guide are vendor-neutral. Product labels vary; the team still has to decide what its skills mean, when to relax a match and what happens when no suitable agent is available.

SBR should answer five questions in order:

1. What does the customer appear to need?
2. Which skills are genuinely required to handle that need safely?
3. Which logged-in agents are eligible and capable?
4. Which eligible agent has capacity now?
5. How should the rule change as the customer waits?

The fifth question prevents an ideal match from becoming an indefinite wait.

Start with customer intent, not your organisation chart

A common first attempt mirrors departments: Sales, Support, Billing and Retentions. Those labels may be useful queues, but they are too broad to describe specialist capability. The opposite mistake is creating a separate skill for every product, exception and internal team. That produces hundreds of combinations nobody can maintain.

Build a compact taxonomy from real contact reasons. Review several weeks of dispositions, ticket categories, transfer reasons and call notes. Group work by the knowledge or authorisation needed to resolve it. A manageable first version might contain:

• Billing adjustments
• Technical diagnosis
• Account cancellation
• New-business enquiries
• English and Welsh language handling
• Priority-account service
• Regulated payment handling

Separate a required skill from a useful preference. If only authorised staff may take a card payment, eligibility must be strict. If an experienced product specialist would merely be preferable for a general question, the rule can relax after a short wait.

Capture customer intent as close to the entry point as possible. An Interactive Voice Response (IVR) menu, account lookup, dialled number, web form or existing case can supply routing attributes. The input must be trustworthy: a vague menu choice such as “other” should not trigger a narrow specialist route. The SessionTalk guide to contact-centre IVR and customer routing explains how to collect intent without trapping callers in a deep menu.

A worked example for a twelve-agent service team

Consider a service desk with twelve agents. All twelve can handle general account questions. Six can make routine billing corrections. Three can diagnose an advanced connectivity fault. Two can serve priority accounts, and one of those two is also the strongest connectivity specialist.

A priority customer calls about intermittent service. The routing input carries two attributes: `priority account` and `technical diagnosis`.

The team could define the decision like this:

• First 30 seconds: offer the call to an available agent who is eligible for priority accounts and rated at least intermediate in technical diagnosis.
• From 30 to 90 seconds: keep priority-account eligibility mandatory, but allow any trained technical agent rather than only the most proficient.
• After 90 seconds: send the call to the priority-service overflow group and alert a supervisor that specialist matching was relaxed.
• If nobody matches: offer a callback or staffed general-service path rather than leaving the caller in a queue with no destination.

This model protects the customer-tier requirement while allowing the technical preference to widen. It also avoids concentrating every advanced call on the single top-rated specialist.

Now change one fact: the same customer chooses a payment option that requires a specific authorisation. That skill should not relax merely because the caller has waited. The safe fallback may be a scheduled callback from an authorised agent, not a transfer to somebody who cannot complete the work.

The example shows why skills are not equal. Each skill needs a type: mandatory eligibility, ranked preference or contextual information. Without that distinction, the routing engine cannot make a sensible compromise.

Keep eligibility, proficiency, presence and capacity separate

Combining every factor into one opaque score makes troubleshooting difficult. Treat them as separate gates.

Eligibility protects hard boundaries

Eligibility answers whether an agent may handle the interaction at all. Use it for permissions, language requirements, contractual service groups and work that requires training or authorisation. An ineligible agent should not receive the contact, even when the queue is under pressure.

Document who grants eligibility, what evidence supports it and when it expires. If a compliance course must be renewed annually, the related routing attribute should have a review date rather than remain forever.

Proficiency ranks valid choices

Proficiency distinguishes among eligible agents. Three levels are often enough: learning, competent and advanced. More levels create false precision unless supervisors can explain and calibrate each one.

Avoid using job title as a proxy. A senior agent may be advanced in billing but new to a recently launched product. Base proficiency on observed work, quality review and current coaching evidence. Give agents visibility of their profile so incorrect ratings can be challenged.

Presence describes whether the agent can receive work

Logged in does not always mean available. Presence should reflect active status, break, after-call work, meeting, offline device and other states the routing platform can use reliably. Voice delivery also depends on a reachable endpoint. A Session Initiation Protocol (SIP) phone may be registered while the user is away, and a mobile softphone may need push notification delivery before it can alert consistently.

Test status changes on real desktop and mobile devices. If presence updates lag or agents remain available on an abandoned endpoint, routing logic will select people who cannot answer.

Capacity limits concurrent load

Voice usually consumes an agent's full attention. Email and messaging can be asynchronous, while live chat may allow limited concurrency. Do not assign the same capacity weight to every channel.

A simple model might allocate one voice slot, up to two live-chat slots, or a controlled number of asynchronous tasks. When a voice call arrives, decide whether it should pause new digital assignments. The answer depends on service design, but it must be explicit; otherwise skilled agents become overloaded because each channel regards them as free.

Make waiting behaviour part of the design

A routing diagram is incomplete until it shows time. For every interaction type, define what happens at the initial match, after each threshold and at the maximum acceptable wait.

Use widening rings, not a sudden collapse

Start with the best qualified pool, then widen one preference at a time. For example:

• Ring 1: required product skill plus advanced proficiency
• Ring 2: required product skill plus competent proficiency
• Ring 3: adjacent trained team with a supervisor support path
• Final path: callback, voicemail or staffed general queue

Do not remove mandatory eligibility during widening. Record which constraint was relaxed so reporting can distinguish ideal matches from fallback assignments.

Give no-match interactions an owner

A new product code, unrecognised language or bad integration value can produce an interaction that matches nobody. Route these exceptions to a monitored destination. Assign somebody to review why the attribute failed and correct the source data or rule.

An empty queue is not a harmless configuration detail. It is a customer waiting for work the system has made invisible.

Protect small specialist groups

Reserve capacity or set an allocation rule when one skill is scarce. If the only advanced technician also handles general queries, unrestricted longest-idle routing may fill that person's day before specialist demand arrives. Conversely, permanently reserving the specialist can leave capacity unused.

Use recent arrival patterns to choose a controlled reserve, then review it. A supervisor may release reserved capacity during a quiet period or when another trained person is available.

Test failure cases before normal traffic

A happy-path test proves very little. Build scenarios that put pressure on the model and observe both routing decisions and the agent experience.

Test scarce-skill demand

Place several specialist interactions close together. Confirm that the first contacts reach suitable agents, later contacts follow the intended timeout path and general work does not starve. Check whether the same expert receives every contact despite other competent agents being available.

Test stale and contradictory profiles

Mark an agent unavailable, remove a certification and create conflicting proficiency values. Confirm that the routing result follows the authoritative source. Test what happens when a supervisor changes a skill while the agent is logged in.

Test devices and networks

For voice, call from an external number and observe alerting on the endpoint the agent actually uses. Include office Ethernet, home Wi-Fi and mobile data where those conditions are part of normal work. Test rejected calls, missed mobile push notifications, one-way audio, device switching and warm transfers.

A routing decision is not successful merely because an event log says “offered”. The agent must receive usable audio and enough context to handle the interaction.

Test out-of-hours and no-match routes

Run the journey when specialist teams are closed, every matching agent is busy and the intent value is blank. Confirm announcements are accurate, callbacks create owned work, voicemail reaches a monitored inbox and emergency routes do not depend on an unavailable person.

Small organisations planning the surrounding number, device and resilience design can use the small business phone system requirements checklist to make these tests part of the wider calling environment.

Measure matching quality without hiding the cost

A higher proportion of specialist matches is not automatically better if customers wait longer and two experts burn out. Review a balanced set of measures:

• Percentage of interactions receiving the initial ideal match
• Percentage assigned after a skill or proficiency rule was relaxed
• Queue wait, abandonment and callback completion by contact reason
• Transfer and requeue rate after assignment
• Resolution and repeat-contact outcomes
• Workload share by agent and skill group
• Occupancy and after-contact work for scarce specialists
• No-match volume and routing-exception age

First Contact Resolution (FCR) can indicate whether better matching helped solve issues, but it should not stand alone. A specialist may improve resolution while the waiting time makes more customers abandon. The guide to measuring and improving First Contact Resolution shows how to define the outcome and read it beside balancing measures.

Inspect distributions, not just averages. If an advanced technician receives 45% of specialist work while two equally proficient colleagues receive 15% each, investigate presence, capacity and tie-breaking rules. The overall queue result may look acceptable while the assignment pattern is unhealthy.

Run a short weekly routing health check

Routing models decay because products, people and demand change. A 30-minute weekly review can keep a small implementation under control.

Bring the service owner, a supervisor and whoever maintains routing data. Review:

1. No-match and exception interactions, starting with the oldest
2. Contacts that waited beyond a timeout threshold
3. Skills relaxed during assignment and whether the fallback worked
4. Transfers caused by incorrect intent or agent profiles
5. Workload concentration among scarce-skill agents
6. Skills added, removed or due for evidence review
7. One rule change to test, with an owner and success measure

Keep a change log that states the old rule, new rule, reason, expected effect and rollback point. Avoid changing several thresholds at once; otherwise the team cannot tell which adjustment altered the outcome.

Ask agents for evidence as well as opinions. “The billing queue is wrong” is a starting signal. Three interaction IDs showing incorrect eligibility, missing context or delayed presence provide something the routing owner can reproduce and fix.

Make the right match reachable in real work

Skills based routing works when the model recognises customer intent, protects mandatory boundaries, ranks suitable agents, respects live capacity and changes deliberately as the customer waits. Start with a small taxonomy, test the uncomfortable scenarios and watch workload concentration as closely as headline service measures.

If specialist voice handling includes desktop and mobile agents, run a focused SessionCloud trial with the people who receive escalated calls. Test SIP provisioning, incoming alerts, device changes, warm transfers and call continuity under real working conditions while you validate routing rules in your existing service workflow. The aim is not to assume a platform decision; it is to prove that the selected agent can actually receive and handle the call well.