Want help applying this guide?Ask the DripTell team
At 9:05, a customer asks why an underwater camera housing leaked. Three people are free, but only one knows how to inspect the pressure seal. Sending the conversation to the fastest available person creates a transfer. Waiting forever for one named expert creates a silent queue.
Use skills based routing only for capabilities that change who can safely handle the customer’s need. Mark a skill as required when the wrong person cannot complete the work. Treat useful but nonessential experience as a preference, and publish what happens when the ideal match is unavailable.
Skills should express a real customer constraint
A routing skill is not a compliment and it is not a job title. It is a capability the work genuinely needs, such as authority to approve a refund, fluency in the customer’s chosen language, or training on a regulated product. “Senior,” “helpful,” and “good with difficult customers” are too vague to decide ownership.
- 1Name the customer consequenceStart with the action, authority, language, or risk that changed who could complete the work.
- 2Mark required or preferredRequire only the capabilities that cannot be relaxed safely.
- 3Choose the match modeUse exact matching for hard constraints and closest matching for safe preferences.
- 4Own the no match stateName the fallback owner, waiting rule, customer message, and permitted actions.
- 5Review correctionsUse transfers, manual changes, waits, and outcomes to remove or refine skills.
Start with recent conversations that were transferred, delayed, or reopened. Ask what the first owner was unable to do. A specific, repeated gap may deserve a routing skill. A difference in speed or confidence may belong in coaching instead.
Microsoft’s current overview of skill based routing describes the core relationship clearly. Work carries required skills, representatives carry skills and proficiency, and the routing system also has to respect workload. That separation matters. A qualified person who has no safe capacity is not an available match.
Keep the initial skill list small. A dozen overlapping product labels can turn one customer need into an impossible combination. Your lead routing policy should use the fewest facts needed to find a capable owner and leave uncertain classification visible.
Separate required skills from preferences
Suppose a customer needs a billing address corrected. Product knowledge may help, but any trained support representative with account access can finish the action. That skill is preferred. Now suppose the customer disputes a regulated payment and only a designated role may approve a reversal. That authority is required.
Required skills may justify waiting because an unqualified answer creates greater harm. Preferred skills should improve the first choice without blocking a safe generalist. A shared inbox should keep the customer owned while the system looks for help.
Use this decision matrix before adding a skill to a rule.
| Customer condition | Skill treatment | If no ideal match exists | Evidence to review |
|---|---|---|---|
| Action requires restricted authority | Required | Keep owned and escalate to the authorized role | Permission and approval record |
| Customer explicitly chooses a language | Required when understanding cannot be assured | Offer a qualified interpreter or agreed callback | Preference and correction history |
| Product question is common and documented | Preferred | Route to a trained generalist with approved knowledge | Resolution and transfer evidence |
| Issue is unusual but not unsafe | Preferred | Let the owner consult an expert without transferring | Consultation and outcome |
| Classification is uncertain | No automatic hard requirement | Keep in a visible triage queue | Corrected skill and final owner |
Choose exact matching only when waiting is safer
Exact matching sounds disciplined, but it can strand work when every attached skill becomes mandatory. Microsoft’s current skill match documentation says an exact match searches for a representative who meets all required skills and proficiency levels. If none is available, the work remains unassigned in the queue. Closest matching can rank partial matches, including people who lack some requested skills.
Neither choice is automatically better. Use exact matching when authority, safety, privacy, or reliable understanding cannot be relaxed. Use closest matching when a capable generalist can act safely, preserve context, and consult a specialist if needed. Do not let a vendor setting make that risk decision for you.
Test combinations, not only individual skills. “Spanish” may have coverage while “Spanish plus returns plus supervisor” leaves one possible owner. A useful support operating model exposes that scarcity before launch.
Build the fallback before launch
Every skill rule needs a no match state. Name the queue or person who owns it, how long the ideal match is allowed to remain unavailable, what the customer is told, and which safe actions the fallback owner may take.
An honest fallback may let a generalist consult an expert, offer an owned callback while preserving arrival time, or let a duty manager remove a falsely attached skill. In a serious case, waiting may be safer than assigning someone without authority.
An ownerless “other” queue is not a fallback. Configure automation rules so failed matches remain observable. Manual overrides should record who changed the skill and why. Apply the same access controls to skill and permission data used for ownership.
Run a shadow test before automatic assignment. Include missing data, several attached skills, a full expert, a wrong classification, and a case that crosses a shift. Compare the recommended owner with the person who could complete the work.
Review no match cases every week
The most useful report is not the percentage routed automatically. It is the set of customers who received no safe first owner.
Review time to accepted ownership, no match volume, transfers caused by missing capability, manual skill corrections, fallback use, and the oldest waiting work. Slice the evidence by skill combination. A broad average can look healthy while one rare combination waits for hours.
Use inbox reports to find the affected windows, then read a small sample. Remove skills that do not change handling. Split one only when distinct authority or capability appears in the evidence. Update proficiency when responsibility changes.
DripTell can keep routing, ownership, notes, and conversation history together while teams apply these rules. The policy still has to be written by people who understand the customer risk. Good skills based routing does not always find the most specialized person. It finds a safe owner quickly and makes the exceptions impossible to ignore.
Frequently Asked Questions
What is skills based routing in customer service
It is a way to match incoming work with people who have the capabilities the request needs. A sound rule also checks availability and capacity, then defines a visible fallback when no match exists.
How many routing skills should a support team create
Start with the smallest set that changes real handling decisions. Add a skill only when repeated conversation evidence shows that capability, authority, or language meaningfully affects who can complete the work.
Should language always be a required skill
No. Use the customer’s explicit preference and the complexity of the task. If reliable understanding cannot be assured, treat language as required or arrange qualified help. Do not infer nationality from language.
What should happen when no agent matches every skill
Keep the conversation visible with an accountable owner. Depending on risk, consult an expert, offer an owned callback, correct a bad classification, or wait for an authorized specialist. Never let the work disappear unassigned.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy