Tiering moves a ticket up a ladder until it reaches somebody allowed to finish it. Swarming keeps the ticket with whoever took it and brings the help to them instead. The difference is not really about teamwork. It comes down to one rule, which is whether a ticket is allowed to change hands at all.
Almost everything written on this subject gets that wrong, and gets it wrong in the very same direction, by turning the question into a culture question, collaboration set against bureaucracy and trust set against process, as though the thing you were picking out was a personality. Read enough of them and you would think the choice was about what sort of company you wanted to be, when the whole of it turns on something a good deal more boring than that, and a good deal easier to go and check, and checkable this week rather than after somebody has reorganised the department.
What swarming and tiering actually mean
Tiering you already know, and if you want the structure of it properly laid out we have written the whole thing under tier 1, tier 2 and tier 3. The short version of it runs like this. A ticket lands with tier 1, who answer it where the answer is written down and pass it up where it is not, and it climbs until it reaches a person with the knowledge or the permission to close it, which on a busy desk can mean three people and two days. The words for the whole of it were borrowed out of ITSM, and out of ITIL before that, and they went and settled into customer support desks that have never once run a server between the lot of them.
Swarming takes the ladder away, and the name is not a loose one either, on account of it belonging to a documented practice called Intelligent Swarming, put on paper by the Consortium for Service Innovation, who are a non-profit body rather than anybody over here selling you software. Their practices guide is public, we pulled the wording on this page off it on 4 September 2026, and every third-party figure further down came off the very same source.
Here is what their guide says the thing does. Instead of routing a hard ticket up through levels, you get the people most likely to solve it working on it as quickly as possible, and collaboration happens by asking for help, which they call raising a hand, or by asking one specific person, or by somebody wandering past and offering help nobody asked them for. There are no tiers in it at all. What there is instead is generalists, who are good at poorly defined problems and at talking to a customer in their own context, and specialists, who are good at the well defined ones, and neither of them sits above the other.
And then there is the one sentence almost nobody ever quotes back, which carries more weight on its own than everything else in the guide stacked together.
Why the real difference is ownership and not teamwork
The Consortium’s guide puts it in one sentence. The person who takes ownership of the issue owns the issue until it is resolved.
Read that twice. Swarming is not defined by three people crowding round the one screen, it is defined by the ticket staying put, and whoever picked it up keeps it start to finish, with everything else in the model existing to bring help over to that person rather than to move the work away from them. Tiering is the opposite rule and it is every bit as simple, the work moves and the person stays, and the whole of the argument people have about these two models sits on top of that one difference without much of anybody naming it.
That reframe is worth more than every comparison chart on this subject, on account of it giving you a test you can run this afternoon. One question. When a ticket on your desk turns out to be hard, does it get reassigned to somebody else, or does it stay with the person who has it while somebody else helps them.
If it gets reassigned, you are tiering, and it does not matter in the slightest whether you have got tiers written down, or job titles with numbers in them, or an org chart at all, nor does it matter one bit how friendly the handover was. The ticket changed hands. Your customer’s thread now belongs to a person who was not there for the first half of it, and that person is reading up on the whole of it while the customer sits waiting.
If it stays put, you are swarming, whether or not anybody has ever used the word out loud on your desk. Most have not.
Everything people usually argue about here sits downstream of that one rule, whether tier 1 ever learns anything, whether the customer has to go and repeat them selves, whether your best engineer gets pulled off whatever they were doing. All of it follows from where the ticket lives. None of it follows from how nice everybody is to one another, which is the thing most of these pages are actually measuring at the moment they believe them selves to be measuring a model.
Why most desks that say they swarm are still tiering
Apply that test honestly and something awkward turns up, which is that a great many desks describing them selves as swarming are doing no such thing, and have not been doing it for as long as anybody there can remember.
The usual shape of it goes like this. Somebody reads about swarming, likes the sound of it well enough, and opens a channel in Slack or in Teams called something along the lines of support-help. Tier 1 hits a hard one, posts it into the channel, an engineer wanders in and answers it, and everybody feels collaborative about the whole business. Genuinely good practice, mind you, and not one person in that story has done anything anybody could reasonably object to.
But then watch what happens to the ticket. On most desks it still gets reassigned over to the engineer, because the engineer is the one who needs to see the reply go out, or because the tooling, whether that is your help desk or a board in Jira, makes assignment the only way of putting a thing on somebody’s list, or plainly said out of habit. And the moment it moves, you have got tiering with a chat channel bolted onto the side of it, which is a perfectly reasonable thing to run and is not the model anybody thinks they installed.
The reverse turns up as often, and it is the funnier one. Plenty of desks with tier 1 and tier 2 printed on the org chart are quietly swarming half their tickets already, because the person on the ticket asks in the channel, gets the answer, and sends the reply out them selves without ever touching the assign button. The chart says one thing and the desk does another, and it has been doing it for a good long while without anybody noticing.
So before you restructure anything at all, go and look at last month. Count how many tickets changed owner, then count how many were answered by the original owner after somebody had helped them out, and pull the pair of numbers into a CSV if your reporting will not put them beside each other. That is your actual model, right there, in numbers rather than in intentions, and most teams doing it find they are running a mix that not one person ever sat down and decided on. That is normal enough.
What the 95% rule really tells you about which model to pick
There is a threshold buried in that same practices guide, and it is the most useful number on this whole subject, which is very likely why so few pages bother printing it.
They write that the tiered model works efficiently if the majority, 95% or more, of issues are simple and known, and resolved during the customer’s first contact. They also note that historically each level resolved 70 to 80 percent of what it received, and that a number of companies now see 80 percent of issues solved by customers through self-service before anybody is involved at all. Those three figures come off their practices guide, pulled 4 September 2026, and they are the only third-party numbers on this page.
Now, the way that 95% usually gets used is as a stick to beat tiering with. Almost nobody clears 95%, therefore tiering is broken for almost everybody, therefore swarm, and you can see the logic of it well enough and it is not a mad one.
Except run it the other way about and it says something a good deal more interesting. The threshold has nothing whatever to do with your org chart, it is about what proportion of your tickets are simple and known, and simple and known is a property of your documentation and your permissions rather than of your reporting lines, which means it is a property you can go and move. Write the article and a whole category of ticket becomes known. Open up an access right, carefully, with something logging who did it, and it makes no odds at all whether that right is held in Active Directory or in your SSO tooling or in the product’s own roles, another whole category turns simple.
Which means a desk sitting at 60% simple-and-known has two ways out of it, and everybody points at the wrong one. The first is restructuring. That costs you months, unsettles the lot of them, and does nothing whatever about why those tickets were hard in the first place. The other way is duller. You go and write things down, which is cheap and slow and nobody much enjoys it, and it moves the very number the threshold is actually measuring. The other page on this cluster makes the very same argument from the other end, that the tier line is drawn by documentation rather than by skill, and the two of us arrived at it from opposite directions, which is usually a fair sign that a thing is true rather than a sign somebody has been reading their own notes back to them selves.
Restructure a documentation problem and half a year later you are sat with the very same problem, drawn out on a flatter chart. Truth be told that is most of what happens, and it happens to people who are nobody’s fool.
Why swarming moves the cost instead of removing it
Now for the thing nearly every page on this term leaves out altogether, and it is not a small thing to be leaving out.
A hard ticket costs somebody’s attention, and that cost does not go anywhere at all when you change the model, it only changes who pays it and at what moment. Tiering pays it in queue time, which is to say the ticket waits and the customer waits and your first response time on that thread goes out the window, along with whatever your SLA had to say about the matter. Swarming pays it in interruption, right now, out of whoever gets pulled in. The bill lands the same day.
And the person being pulled in is precisely the one you can least afford to interrupt, seeing as knowing the thing is the entire reason anybody called them over in the first place.
Nobody prices this. A queue is an unpleasant thing to look at on a dashboard and it is easy to point at as waste. But a queue does a second job as well, which is to hold the interruptions off somebody long enough for them to think. Your tier 2 people batch four escalations at eleven o’clock and work through the lot of them in one sitting, having lost their concentration exactly once. Swarm the very same four and you have interrupted the one person four separate times across a morning, and anybody who has ever tried to hold a hard problem in their head knows well enough what those four interruptions cost, and it is not four small things added up, it is the morning gone, and the morning was the thing you thought you were buying with all of this.
So the honest framing of it is a trade rather than an upgrade. Swarming buys you speed on the individual hard ticket and it buys that speed with the concentration of your most expensive people. Sometimes that is a wonderful trade to make, a live outage, an account worth defending, a customer with one foot out the door, and the interruption is plainly worth every minute it takes. And then there are the mornings where it is a dreadful one, a steady stream of medium-hard tickets, not one of them urgent, the lot of them perfectly capable of waiting the hour, and swarming shreds your specialists’ day for a gain no customer anywhere would notice.
Fair is fair, tiering has the mirror-image failure and it is real. The Consortium lists it plainly, that tiering creates multiple queues and turns a real-time activity into a backlog, along with silos, handoffs, bouncing between the wrong teams, and forcing every issue through a rigid predefined process whether it suits it or not. All of that is true, and skating past it here would be a cheap trick. The point is only that both models have a bill and most of the writing on this only ever adds up one of them.
What tiering is genuinely good at
Since we have just made the case for the other side, we may as well make this one properly too.
Tiering sorts, and the sorting pays for its self the moment the thing being sorted keeps on repeating. Password resets, invoice copies, where-is-my-order off the back of a Shopify store, how-do-I-export-this-to-a-CSV. A desk taking three hundred of those a week does not want its senior people anywhere near the lot of them, and a structure whose entire job is keeping them away is doing exactly what it was built to do. The Consortium’s own 95% condition is a description of that desk. Those desks are real.
It is also, quietly, a training structure, though a badly run one teaches nothing. Where it works, tier 1 gets to see the answer that eventually went out, so the very same ticket next month never leaves them at all. Where it fails, tier 1 forwards into a void and hears nothing back, and that second version is the one every critic of tiering has in mind, fairly enough, on account of it being depressingly common.
And it scales in a way swarming does not, on the simple ground that a ladder can be staffed by a rota and a swarm cannot. Night shift, holiday cover, a sudden Monday, and a tiered desk absorbs it by putting more people on the bottom rung. A swarm absorbs the very same surge by asking more of the people who already know things, and there are only so many of them, and they were already busy.
Tiering tends to earn its keep quietly, which is part of why it gets so little credit for it. A queue nobody complains about usually means the sorting underneath is doing its job.
Eleven tickets on a Wednesday, and what each model does with them
Every figure below is made up, mind you, and made up by us, though the shape of the thing will be familiar enough to anybody who has worked a desk.
Say a desk of eight takes eleven tickets before lunch on a Wednesday. Eight of them are ordinary, answered off articles inside a few minutes each, and neither model does anything different with those. Nobody swarms a password reset. Nor does anybody go and escalate one.
That leaves three. One is a report showing wrong totals for a single account. One is an integration with your CRM that stopped syncing overnight and is throwing errors back through the API. One is an angry customer with no technical fault at all, who wants somebody senior to say sorry properly.
Tiered, all three go up. They land in a second queue, they sit there while tier 2 finishes what tier 2 was already doing, and they get picked up around two o’clock. The customers have each been told somebody is looking into it. Total specialist time, call it 90 minutes across the three, in one uninterrupted block. Total customer wait, call it 4 hours each.
Swarmed, the three people holding those tickets each raise a hand. The specialist is pulled in three separate times, at 10.20, at 11.05 and at 11.40. Call it 30 minutes of their attention each time and 90 minutes again, except it is now scattered across three interruptions and the recovery either side of them, so their own morning is gone. Customer wait drops to under an hour on all three. Nobody handed anything over, so nobody repeated them selves, and the person who took each ticket learned something they will keep.
Look at the two of them side by side and there is no winner. There is a customer who waited 4 hours against a specialist who lost a morning, and which of those two costs you more is a question about your business rather than about support. The angry customer is the interesting row, incidentally, because that one wants a person and not an answer, and passing it upward teaches the customer that shouting works. That one wants sideways movement, not up, which is a distinction the escalation piece works through properly.
How the answer changes between a desk of four and a desk of forty
Under about five people the argument is void and you are already swarming. Four people in one room, or one channel, hit a hard ticket, ask out loud, and answer it between them without a single rule being written down. Formalising that costs you more in ceremony than it returns, and the same is true of tiering at that size. A desk of four that installs tier 1 and tier 2 has just invented a handover between two people who sit next to each other.
Between roughly five and twenty people you find the real decision, and that is the size most of these pages are quietly aimed at without ever saying so. Big enough that asking out loud has started to fail, seeing as asking now means interrupting somebody whose day you cannot see, and small enough that a formal ladder still feels absurd on the face of it. That size runs best on a mix, and almost nobody wants to admit to running a mix.
Above twenty and above forty, the ladder starts asserting its self whether you install it or not. Rotas, shifts, timezones, cover. What you get in practice is a shallow structure with swarming inside it, which is to say a ladder of two rungs where anything reaching the second rung stays with whoever caught it. That shape is the one most large desks land on after trying both. Almost nobody writes it up. It has no name and it makes a poor headline.
The size question is not really about headcount either. It is about whether the people who know things are reachable without an appointment. A desk of thirty sat in one room may as well be a desk of six. Nine people split across three timezones, on the other hand, are functionally a large desk, and the whole of the swarming argument gets harder the moment the person you want to raise a hand at is asleep.
Which model your ticket mix is asking for
If you want one rule out of the whole of this page, here it is, and it is not the ticket-mix rule everybody else closes on.
Sort your hard tickets into two piles. Pile one is problems that are genuinely new, which nobody on the desk has seen before and which no article could have covered because the thing had not happened yet. Pile two is problems that are known perfectly well by somebody, somewhere, and simply are not written down or are locked behind a permission the person on the ticket has not got.
Swarming is built for pile one. That is what the Consortium says it is for, that it is most effective in solving new, complex problems, and the whole raise-a-hand mechanism only makes sense when the answer does not exist yet and has to be made between people.
Pile two is not a structure problem at all and no model fixes it. Swarm a pile-two ticket and you have interrupted a specialist to have them recite something that should have been an article. Escalate the very same ticket and you have queued it to have somebody recite the very same thing. Both models fail on that ticket, at different speeds, and what actually fixes it is a knowledge base entry and half an hour of somebody’s time.
So the ratio between those two piles is your answer. If most of it is genuinely new, swarm, and take the interruption bill on the chin. If most of it is merely unwritten, then neither model is the job in front of you, and the job in front of you is the writing. Most teams who sit down and sort it honestly discover pile two is the bigger of the pair by a distance, which is an uncomfortable finding, and it is the most useful uncomfortable thing on this page. That is also why “match the model to your ticket mix”, which is how nearly every article on this term signs off, is advice that sounds complete and tells you nothing. Your ticket mix is not a fixed thing. A good half of it is your own documentation habits, turning up dressed as tickets.
What to run for two weeks before restructuring anything
Nobody should reorganise a support team off the back of a blog post, ours included. What you can do inside a fortnight, at no cost and with nothing to undo afterwards, is this.
- Pick one slice, not the whole desk. One product area, or one queue, or the tickets from your five largest accounts. A slice big enough to see a pattern in and small enough that a bad fortnight harms nobody.
- Write down the rule for that slice and put it somewhere visible: on these tickets, nobody reassigns. Whoever takes it keeps it. If you are stuck, ask, and the person helping you does not take the ticket off you.
- Give the asking a real home. An internal note on the ticket beats a Slack thread every time, since the note travels with the conversation and the Slack thread is gone by Thursday. Wherever you put it, agree the one place before you start.
- Count two things and only two, not CSAT, not AHT, not whatever else your dashboard already draws for you. How long each hard ticket took end to end, and how many times a specialist got pulled off their own work. That second one is the number nobody records and it is the one the whole of this argument turns on.
- Ask the specialists at the end of the fortnight, privately and plainly, whether their own work got done. Their answer is the cost side of the ledger and no dashboard anywhere will tell you it.
- Compare against the same slice a fortnight earlier. Not against a benchmark from a page like this one, and not against the desk next door, since neither of them has your product or your customers.
Two weeks of that settles more than three months of arguing about it will, and the finding tends not to be the one anybody sat down expecting. Plenty of teams run this and discover the interruption count is far lower than the specialists claimed, and plenty of others discover it is far higher, and both of them learned something they could not have read anywhere.
Where our own product stands on this, and what it costs
Our own answer to the whole of this is built into the product, so here it is with the bias showing.
Maxdesk has no tiers in it. There is no tier field, no team object, no group object and no skill-based routing anywhere in the thing, and that is a design decision rather than a gap we are working up to. What there is instead is one owner by name on every conversation, statuses and priorities, internal notes that your team can read and your customer cannot, and a shared inbox where everybody can see who is holding what, whether the mail behind it arrives out of Gmail or out of Outlook. Structurally that sits nearer the swarming end than the tiered one, and we would rather say that outright than pretend to neutrality on our own page.
Where the AI support agent does assign, it assigns by workload and not by skill, sending each new ticket to whoever is holding the fewest open ones at that minute. That is honest balancing and it is not swarming and it is not tiering either, and anybody wanting tickets routed by who knows what will not get it from us. Automation rules will route on tags and senders and content on every plan including the free one, which covers a good deal of it in practice, but a rule is not a skill model and we are not going to dress it up as one.
The money angle is worth a line, since it changes this argument for anybody paying per seat. Swarming costs more on per-seat pricing, plainly, because pulling a third person onto a ticket means a third licence, and we have seen that quietly kill the idea on desks where the model would have suited fine. Our bill does not work that way. It goes by the workspace, human agents are unlimited on every plan including Free at $0, and putting four people on one hard conversation adds nothing to what you pay. Pro is $20 and Elite is $99, with the AI features on Elite alone. Those figures were checked on 4 September 2026.
The case against everything above
We have argued one side of this fairly hard, so here are the places the argument gets weakest, and a fair bit of it is at our own expense.
The ownership test is a clean rule and real desks are not clean places. Plenty of tickets genuinely should change hands. Somebody goes off on leave halfway through one of them. Somebody picks up a ticket they had no business picking up, and now and then a conversation turns out to belong to sales rather than to support at all. Treating “the ticket never moves” as a commandment produces its own silliness, and the Consortium is describing a default rather than a law of nature.
We also cannot measure the interruption cost for you and neither can anybody else, which is a bit awkward for a page that has just called it the deciding factor. There is no honest figure for what a broken morning costs a specialist. We have looked. What we can say is that it is not zero, and that leaving it out of the sum, as most writing on this does, guarantees the sum comes out favouring swarming.
Our own position is not neutral and you should weigh it that way. We ship no tiers, so an argument that tiers matter less than people think is an argument that flatters the product. Read this page knowing that, and note that we have also said outright that we do no skill-based routing, which is the thing a serious swarming desk would most want and the thing we have not got.
And there is the plain limit that email is the only channel we ship, wherever your mail happens to be hosted, Google Workspace or Microsoft 365 or something older than the pair of them. Everything above is about written tickets. A desk running phone or live chat has a different version of this question entirely, since you cannot queue a person on a phone the way you queue a thread, and swarming on a live call is a different practice with different mechanics. Nothing on this page covers that, and saying so outright beats letting you find it out in week three.
Last of the lot, the figures. The three Consortium numbers came off their public practices guide on 4 September 2026 and we have quoted them as their own, not as ours. Our own plan details were checked the same day. Both go on the list for a re-check in the first quarter of 2027, and if something real is riding on one of these numbers, open the Consortium’s own page and read it your own self first.
Common questions about swarming and tiering
What is the difference between swarming and tiered support?
Tiering passes a ticket upward until it reaches somebody able to finish it, so the work moves and the person stays. Swarming keeps the ticket with whoever took it and brings help to that person instead. The defining difference is ownership, not how collaborative the team is.
What is Intelligent Swarming?
Intelligent Swarming is the documented name of the practice, published by the Consortium for Service Innovation. It replaces tiers with generalists and specialists, and works by people asking for help, asking a specific person, or offering help. Its core rule is that whoever takes ownership of an issue keeps it until it is resolved.
Is tiered support dead?
No. The Consortium’s own guide says the tiered model works efficiently where 95% or more of issues are simple, known and resolved on first contact. High-volume repetitive queues fit that description well, and a ladder also covers shifts and holidays in a way a swarm cannot.
How do I know which model my team is actually running?
Count how many hard tickets changed owner last month against how many were finished by the person who first took them. That single count tells you your real model, whatever the org chart says. Most desks find they are running a mix nobody ever chose.
Does swarming work for a small support team?
Under about five people you are almost certainly swarming already, without the name, so there is nothing to install. The decision genuinely matters between roughly five and twenty people, once asking for help means interrupting somebody whose workload you cannot see.
What does swarming cost that tiering does not?
Interruption. A swarm pulls specialists off their own work in the moment rather than letting them batch escalations, so you trade customer waiting time for your most experienced people’s concentration. Count how often specialists get pulled in during any trial, because that number decides the whole question.