Round-Robin vs Skill-Based Routing vs Just Claiming

The vendor demo is at the part where the ticket arrives and, with a small animation, lands on the right technician. "The system automatically assigns every ticket to the best available agent," says the presenter. The operations manager at Northgate Retail nods, because that does sound better than what happens now. What happens now is three people, one shared view, and a question shouted across the room at 10:15: "Who's got the VPN one?" Two people say "me". The demo has four agents, all present, none at lunch, and a ticket that already knows what it is about. The desk has none of those things, which is why it is watching a demo.

A routing model is the rule by which a ticket that has arrived in the queue gets a named owner. There are three families worth knowing. Round-robin deals tickets out in turn, like cards. Skill-based routing reads something about the ticket and sends it to the person tagged for that kind of work. Claiming leaves the ticket in a shared view until a person takes it. Every tool and every desk uses one of these, or a mix, whether anyone chose it or not. This article is part of our Queues & Routing series, and it is about choosing on purpose.

It covers the three models in plain words. It then covers the fairness argument for round-robin and where it breaks. The load-balancing variant follows. Next comes the right-first-time argument for skill-based routing and what it costs to maintain. Then it covers why claiming suits a small team, how first-reply-claims works and what it prevents. Next comes the collision case, where two people take the same ticket. Then it covers mixing the models by routing to a department and claiming within it. A short war story, a decision table you can copy, and what claiming needs in place follow, in that order.

The Three Models in Plain Words

Round-robin is the dealer going round the table. The first ticket of the morning goes to Priya. The second goes to Tomas, the third to Marcus, the fourth to Priya again, and so on until the day ends. Some versions weight the deal, skipping whoever already holds the most or whoever is marked away. But the principle is the same. The ticket's owner is decided by where the dealer's hand happens to be when it arrives. It is not decided by anything about the ticket or the person. It is simple, it is automatic, and it needs nobody to look at anything.

Skill-based routing is a sorting machine with labels. A rule looks at the ticket: at its subject, a form field, the requester's department, a keyword in the body. It matches that against a list of who handles what. "Anything with VPN in the subject goes to Tomas." "Anything from the warehouse goes to the person tagged Warehouse." The ticket lands on a person because something about it matched something about them. Done well, it means the right person sees the ticket first. Done at all, it means somebody has to keep the list of who handles what true. That is harder than it sounds and gets harder every month.

Claiming is the shared view and a person's hand. The ticket arrives in the unassigned list. Everyone on the desk can see it. The first person to take it owns it. Nothing automatic happens between arrival and taking. The desk relies on people reading the shared view at fixed times and applying judgment: the oldest ticket, the most urgent one, the one about the system they know. Claiming is what every desk does before anyone configures anything. It is also what a good many desks should keep doing after they have the option not to.

Round-Robin: The Fairness Argument

The case for round-robin is fairness, and it is a real case. Every technician gets the same number of tickets. The quiet one who never volunteers gets as many as the loud one who grabs the interesting work. Nobody can dodge the shared view by not looking at it. The view does not need looking at; the tickets come to you. For a manager who has watched one person take all the easy tickets and another take all the hard ones, a dealer looks like a cure. The dealer cannot play favourites.

It breaks on the difference between equal counts and equal work. A password reset and a two-day investigation each count as one deal. A technician who draws three investigations in a morning is buried by lunch. A colleague who drew six resets is reading the news, and the counts say they are even. Weighted versions try to fix this by dealing to whoever holds fewest. They promptly reward the person who hoards, because held tickets are now a shield against new ones. Round-robin is fair the way a lottery is fair: everybody has exactly the same chance of drawing the printer.

It also breaks on absence. The dealer deals to whoever is in the rotation, and the rotation is a setting, not a sensor. If Marcus is on leave and nobody took him out of the rotation, a third of the morning's tickets land on an empty chair. Those tickets sit there looking owned, which is worse than sitting unowned in a view someone reads. Tools that let agents mark themselves away help, provided the agent remembers. The agent who forgot to set the out-of-office on their mail is the same person who will forget this. The desk ends up checking the dealer's work by hand, which is claiming with extra steps.

Round-robin suits a desk where tickets are genuinely alike, everyone can do everything, and attendance is predictable. An example is a large first-line team handling one kind of call, with shifts and a rota. That is not most small desks. On a desk of three, where one person knows the finance system and one person is at the dentist, the dealer has no idea what it is doing. It is not the dealer's fault. It was never told what a ticket is.

Least-Loaded: The Load Argument

The load-balancing variant assigns each new ticket to whoever currently holds the fewest. It is worth a paragraph because it is the one managers reach for after round-robin disappoints. The argument is that counts, not turns, should decide, so the busy person stops getting busier. It is a better argument than fairness and it fails for the same reason. The count the tool sees is held tickets, not active work. Held tickets are the easiest number on a desk to manage upward. The technician who leaves twelve tickets in a waiting status with no date holds twelve and receives nothing new. The technician who closes everything by Friday holds two and receives the weekend.

If you use a load-based deal, define load as active tickets only. With that deal, exclude anything in a waiting status. Read the per-person holdings weekly as if you were running a claiming desk anyway, because you are. The holdings review and the ceiling it checks against are in Team Queues vs Personal Queues. A dealer that reads an honest count can be useful. A dealer that reads a dishonest one is a machine for rewarding the wrong behaviour very consistently.

Skill-Based Routing: The Right-First-Time Argument

The case for skill-based routing is fewer handoffs. If the VPN ticket lands on the person who knows the VPN, nobody has to read it, realize it is not theirs, and pass it on. In that case, the requester hears from the right person at the first reply instead of the second. On a large desk with real specialisms, that saves a visible amount of time. A routing rule is cheap to write. The appeal is that the ticket arrives already sorted, which is what the demo showed.

It breaks on classification. A rule can only route a ticket by what the ticket says about itself. Tickets are written by requesters, who describe symptoms, not systems. "Nothing works since this morning" is not a VPN ticket until somebody reads it, and the rule has not. A rule that matches on a form field is only as good as the requester's choice from the list. And a rule that matches on keywords routes every message containing the word "printer" to the printer person. That includes the one about the printer being fine but the e-mail not sending. The ticket has to be classified before it can be routed. On a small desk the person who classifies it is the person who could have just taken it.

It breaks on maintenance too. The list of who handles what is true on the day it is written and decays from there. People learn things. People leave. The finance system gets replaced. The person tagged Warehouse moves to projects. Nobody owns the list, so nobody updates it. After a year the rules route confidently to a map of the desk as it was. I built a skill matrix once. It was accurate for eleven days. The desk then spent a year routing around it by hand, which is claiming with a detour.

And on a desk of one to ten, it breaks on arithmetic. A skill, on a small desk, is usually one person. "Route finance-system tickets to the finance-system specialist" means "route them to Ines". Ines has leave, sick days, a course and a lunch break. During all of those, the rule keeps firing. A rule that routes to one person is not a routing rule. It is a personal queue with an automatic feed, and it has every problem of the personal queue with none of the judgment.

Claiming: Why It Suits a Small Team

Claiming suits a desk of one to ten people because those people already know what the rules would have to be told. They know who is in today, because they can see them. They know who knows the finance system, because they ask her. They know that the oldest ticket matters more than the newest. The requester's name is on the oldest ticket and they will meet him in the corridor. All of that knowledge lives in the room, updated continuously, free of charge. And a claiming desk uses it every time somebody opens the shared view. The automatic models try to encode the room in settings. On a small desk the room is cheaper and more accurate.

The cost of a wrong automatic assignment is also higher on a small desk than the cost of looking. When a dealer or a rule lands a ticket on the wrong person, someone has to notice, read it, reassign it and tell the next person. On a desk of three, that is a meaningful share of the morning. Reading a shared view of six unassigned tickets takes thirty seconds. The automatic models save that thirty seconds and spend it several times over on corrections. The maths only turns in automation's favour when the view is too long to read. That is a problem a small desk is lucky not to have.

Claiming also keeps ownership honest in a way the automatic models cannot. When a person takes a ticket, they have read it and decided they can do it. They have promised, in the tool, to the requester. When a dealer assigns a ticket, nobody has read it and nobody has promised anything; the name on it is a prediction that the person will get round to it. The difference shows up a week later in the number of assigned tickets that have never been opened. That is the sign of hoarding. A claiming desk produces less of it, because taking was a choice.

Many small-team ticketing tools are claiming tools by design. It is worth knowing which kind you have before you go looking for settings. A claiming tool routes each ticket to a department or team queue and lets any agent who can see the unassigned ticket take it. It does not deal tickets out to people and it keeps no skill matrix. A tool built for larger desks usually offers all three models and defaults to one of the automatic ones. You can switch those off. If your tool is the first kind and you want a deal or a skill rule, you want a convention. The convention is usually enough. The swarming model, where the whole team pulls from one view and nobody is a tier, is the same idea from the other direction. It is described in Tierless Swarming.

How First-Reply-Claims Works

First-reply-claims is a claiming rule with no separate "take" step. The first public reply on an unassigned ticket makes the replier the owner. It removes the state that causes the most trouble on a claiming desk: "assigned but not touched". It does so because the act of taking is the act of talking to the requester. The requester hears from a human and that human now owns the ticket, in one motion. Many claiming tools do this automatically. Some need a separate take or assign click before the reply, and in those the "assigned but not touched" state is still possible. Check yours by replying to a test ticket with no owner and reading the owner field afterwards. Check too whether an agent who is assigned a ticket by someone else is e-mailed. In a tool that does not do that, the person who assigned it has to say so out loud, every time.

A holding reply claims too, and that is correct. "We have your ticket, I am looking at it, I will update you by 14:00" is a reply. So the person who sent it now owns the ticket, and they should. They own it because they have just promised the requester something with a time on it. The rule makes the holding reply honest: you cannot send one and walk away, because walking away leaves your name on a promise. If you are sending a holding reply on behalf of the desk without intending to own the ticket, you have discovered a reason to leave it unassigned. In that case, let a colleague claim it with the real first reply.

The one edge to plan for is the triager. A desk with a triage rhythm has somebody reading new tickets at fixed times. If that person replies to each one with an acknowledgment, they own all of them by the end of the sweep. That is hoarding by accident. The fix is to triage with internal notes, which are never mailed and do not claim. The fix also includes assigning explicitly where a ticket needs a specific person. The triager who wants to own nothing writes notes. The triager who wants to own something replies. The rhythm itself, and how to run it on a small team, is in Triage Rhythms for a Small Team.

The Collision Case

A collision is two people claiming the same ticket at the same moment, and every claiming desk has them. Both read the unassigned view at 10:14. Both see the VPN ticket at the top, both open it, and both start typing. Whether this is a thirty-second inconvenience or a two-reply embarrassment depends on the tool and on one habit. The tool's part is to let exactly one claim win and tell the other person immediately, before their reply goes out. The habit's part is to say "I have 4471" in the team chat the moment you take something. That costs nothing and prevents most collisions before the tool has to.

A tool that handles collisions badly lets both claims through, or lets the second reply go out without warning. And the requester receives two answers from two people, sometimes contradictory, which is the one outcome worse than silence. Test yours before you trust it. Have two people open the same unassigned ticket and press claim within a second of each other. See what each screen says. In a tool that handles it well, one claim wins and the other agent is told on the spot, and the losing agent closes the tab and takes the next ticket. The whole event takes less time than the sentence describing it. In a tool that handles it badly, both screens say "assigned to me", and you have just learned why the chat habit exists.

Collisions are a sign of a healthy claiming desk, not a sick one. They mean two people read the shared view at the same fixed time and both went for the oldest ticket. That is exactly the behaviour the rule asks for. A desk with no collisions is a desk where only one person reads the view, and that is the desk to worry about. If collisions happen several times a day, stagger the sweep times by five minutes rather than trying to assign who takes what. The moment you assign who takes what, you have written a routing rule and will have to maintain it.

Mixing the Models: Route by Department, Claim by Person

Most small desks should use two models at once, and the mix is not a compromise. Route by department automatically. The door a request came through, the mailbox, the form choice, the chat widget, is a reliable signal about which team it belongs to. It costs nothing to act on that signal. Then claim by person inside the department, because the signal about which person should take it is in the room. This is skill-based routing at the only level where the "skill" is stable, the team. It is claiming at the level where it is not, the individual. The mechanics of the first half are in Routing by Department, Form and Mailbox.

Round-robin has one honest use on a small desk, and it is rotating a duty rather than dealing a ticket. Rotate who runs the morning triage sweep. Rotate who takes the first look at chat. Rotate who reads the team queue at 16:30 and makes sure nothing is left. Those are turns, and turns are what a dealer is good at. The tickets themselves still get claimed by a person who has read them. Do not let a rule assign to a person. Rules assign to queues. People assign to people.

When a desk grows past about ten, or splits into shifts, or takes on a genuinely separate specialism with its own staff, the balance can shift toward automation. That is the time to revisit this table, not before. The decision is driven by whether the shared view has become too long to read at a glance and whether the room still knows who is in. Until both of those change, the cheapest, most accurate router on the desk is the person reading the list.

A Short War Story: The Rule That Kept Firing at Redbrook Engineering

Redbrook Engineering's desk, five technicians supporting a design office, set up a routing rule on the day the new tool went live. Any ticket with "CAD" in the subject or the form's system field went straight to Ines. Ines knew the design software and had asked for exactly that. It worked well for four months. Then Ines took three weeks' leave. Nobody changed the rule because nobody remembered it was a rule rather than a habit. Twenty-three tickets about the design software landed on her personal queue in her absence. Each of them was marked owned. None of them were in the shared view, and none of them had been read. The ninth of the twenty-three was a licence-server fault that stopped four designers drawing for two days. The design office escalated the fault by walking across the car park. The cost was two days of four designers' time plus the project deadline that moved because of it. The tickets had been handled, in the sense that a rule had done something to each of them. The desk deleted the rule and added "CAD" as a department form choice instead. It let Ines claim what she wanted from a view the whole team could see. A routing rule does not know who is in the building, and it will route to an empty chair for as long as you let it.

The Routing Model Decision Table

The table is the template for this article. Find the row that describes your desk, read across, and the model in the right-hand column is the one to start with. The rows are deliberately about your situation rather than about the models' features. The features are what the demo shows and the situation is what you have. Copy it, strike the rows that do not apply, and keep it with the queue policy.

What Claiming Needs in Place

Claiming is not "do nothing". It is a model with four moving parts. And a desk that has only the first one will get the black hole and blame the model. Before you rely on claiming, check that each of these exists and is written down somewhere people can see it.

• A shared unassigned view that every technician can see and that opens by default.
• The written rule that unassigned means the team's, with "oldest or most urgent first" beside it.
• Fixed sweep times, at least three a day, when somebody reads the shared view on purpose.
• A collision habit: say what you have taken, in the team chat, the moment you take it.
• A triage convention: notes do not claim, replies do, and explicit assignment carries a note.
• A weekly look at per-person holdings so that taking stays a promise rather than a filing action.
• A cover rule for absence: before leave, release or hand over; on sickness, the lead reassigns by a fixed time.

The last item is the one that round-robin and skill-based routing both get wrong by default, and claiming only gets right if someone does it. A claiming desk with no cover rule will leave the absent person's tickets exactly where they are, which is nowhere anyone is looking. The cover routine, and the handover that goes with it, is in Vacation Coverage Without the Pile.

Back at Northgate Retail, the operations manager watched the rest of the demo and bought the tool, which was a fine tool. She did not turn on the automatic assignment. The three technicians kept the shared view, added the sweep times to the wall, and started saying "I have it" in the chat. "Who's got the VPN one?" was last heard about a week later, and the answer, for once, was one person.

Frequently Asked Questions