When Tierless Swarming Beats Tiers

10:12, in the desk channel at Meridian Parts. Dana: "4418, label printer in dispatch prints half a label and stops. Reinstalled the driver, same thing. Anyone seen this?" 10:14, Marcus: "The one by the loading door? It hates the long USB run. Try the short cable from the spares drawer." 10:19, Priya: "Also restart the spooler after. It holds the half-printed job and everything after it queues behind." 10:23, Dana: "Short cable, spooler restart, printing. Thanks both." Eleven minutes, start to finish. Ticket 4418 was assigned to Dana, who had never touched that printer. The two people who fixed it were never assigned anything, and neither of them left their desk.

That is swarming, and on its good days it is the fastest support model there is. Swarming is a model where whoever is available pulls the ticket, keeps it, and asks for help in the open rather than passing it up to a higher tier. This article is part of our Support Tiers series, which is mostly about tiers. This is the article about not having them. The case for lanes is made in What Support Tiers Are Actually For. This article takes the other side seriously, including the part where it goes wrong.

It covers what swarming is and the three rules that make it work, then where it beats tiers and where it loses. Next come the chat-channel version for a small desk, with a Tuesday's worth of numbers, and the failure mode where everyone does everything. Then come a side-by-side comparison with tiers and the hybrid most small teams settle on. Next it covers keeping the record when the work happens in chat and what happened at Kestrel Payroll. It ends with a rules card to pin above the channel.

What Swarming Is

Swarming is pull, not push. In a tiered desk a ticket is pushed up a chain until it reaches someone who can resolve it. In a swarm the ticket stays where it landed, and help is pulled toward it. Nobody escalates. The person holding the ticket asks, and the people who know answer, and the ticket does not move.

Help happens in the open, which is the second rule and the one that makes the model more than a group of friends. The question goes into a place everyone can see, usually one chat channel, rather than to the one person the asker thinks knows. Three things follow. The best-placed person answers, not the best-known one. Everyone who reads the thread learns the answer. And the thread is a record, until it scrolls away.

The ticket keeps one owner from start to finish, which is the third rule and the one most often forgotten. Whoever pulled it owns the user, the updates, the note and the close, however many people helped. A swarm without an owner rule is a crowd standing around a ticket, each assuming someone else will write to the user. The user, meanwhile, has heard nothing since 10:12.

The version with these rules written down is sometimes called intelligent swarming, a term from the knowledge-centered service world. The qualifier is doing honest work. Swarming without rules is a chat channel with tickets in it. The word itself is borrowed from insects, which should have been a hint about how it behaves when nobody is watching.

Where Swarming Works

Swarming works on small teams, from two to perhaps six people. That is because the whole point is that everyone can see every ticket and every question. Past six, the channel gets loud, the threads overlap, and the person who could answer has muted it. The model does not degrade gracefully with size. It degrades suddenly.

It works when skills are broad and overlapping. If three of four people could resolve most tickets given a hint, a hint in the open is the fastest route to resolution there is. If the skills are narrow and disjoint, a question in the channel has exactly one possible answerer. In that case, the swarm is a tier with a worse interface.

It works when the team is in one room or one channel that everyone reads, all day. Co-located teams swarm by turning around in their chairs. Distributed teams need the channel to be the room. That means notifications on and a habit of reading it within minutes, not hours. A channel checked twice a day is a slow queue with a friendlier font.

Above all it works where asking for help is normal. Swarming depends on the person holding the ticket saying "I do not know this" in front of the whole team within a few minutes of discovering it. On a team where that costs face, people will hold tickets for an hour to avoid posting. In that case, the model's one advantage is gone. The culture is the precondition. The channel is just where it shows.

Where Swarming Fails

Swarming fails at volume. Forty tickets a day across four people means the channel carries ten or more live threads at a time, each pulling attention from everyone who reads it. The helpers stop reading. The askers stop asking. The desk quietly becomes four people working alone with a chat window open, which is not swarming; it is a queue without the queue.

It fails with narrow specialists, because every question about the firewall goes to the one person who understands the firewall, whatever channel it is asked in. That person is now being pulled into every firewall ticket at the moment the asker got stuck, which is a random time of day, every day. Tiers at least batch those pulls into a queue the specialist opens on their own schedule.

It fails where there is no culture of asking. It fails in a subtler way where there is a culture of asking but none of answering. In that case, the question goes up, three people see it, and each assumes one of the other two is on it. A swarm needs someone to say "looking" within a few minutes, or the asker is waiting on a crowd.

Its deepest failure is that when nobody owns the ticket, everyone does. A ticket that four people have touched in a thread is a ticket that four people believe someone else is updating. The user gets no reply, the note never gets written, and the close happens by accident when someone archives the thread. The ticket that visited four queues under tiers visits four people under swarming, in one afternoon, in one thread. It is faster, and it is the same mistake.

The Chat-Channel Version for a Small Desk

The small-team version is one channel and one rule. The rule has three parts: post the ticket number, say what you tried, ask one question. "4418, label printer in dispatch, half a label then stops, driver reinstalled, same. Anyone seen this?" is a complete post. A screenshot with "this??" is not, and the channel fills with those within a week unless the rule is written where everyone can see it.

The ticket number is there so that the thread can be found from the ticket and the ticket from the thread. What you tried is there so that the first three replies are not the three things you already did. The one question is there because a post with four questions gets zero answers; nobody wants to take on a paragraph. Three lines. A junior technician can write it in thirty seconds, and the senior one can read it in five.

Here is a Tuesday in the Meridian Parts channel, counted by Dana because somebody asked whether the channel was worth it. Nineteen tickets were opened that day. Seven were posted to the channel. The first reply to each came in a median of four minutes, the slowest in eleven. Five of the seven were resolved in the thread in under fifteen minutes, by the owner, with a hint from someone else. One (a payroll export error) was answered with "that is the vendor, open a case, here is the template", which is a swarm doing an escalation's job in one line. One got no answer for forty minutes because Marcus and Priya were both in the server room. Dana resolved it herself at 11:50 from the mail client's own log. Time spent by helpers across the day: about thirty-five minutes. Time saved by the owners, by Dana's estimate: about three hours.

Those are the numbers on a good day with the rule in place. The same channel on a bad day looked very different, and the difference was not the people.

When Everyone Does Everything

The failure mode every swarm reaches eventually is that everyone does everything. The channel is open, the questions are good, and the senior engineer answers all of them, because the senior engineer can. By the third week they are answering forty questions a day, each one a two-minute reply and a fifteen-minute climb back into the thing they were doing. Forty interruptions a day is not a workload. It is weather.

Nobody decides this. It is the swarm working as designed, with the best-placed person answering every question. The best-placed person is the same person every time. The project they own (the backup redesign, the firewall replacement, the thing with a deadline) moves in fifteen-minute pieces and then stops moving at all. The desk's numbers look wonderful. The risk register does not, and nobody is reading it, because the person who would is in the channel.

The fix is two rules, and they are the two that turn a chat channel into a model. The first is swarming hours: fixed windows, say 10:00 to 10:30 and 15:00 to 15:30, when everyone reads the channel and answers. Outside those windows the channel is for posting, not for expecting a reply, and the owner keeps working the ticket alone. The second is the owner rule. A ticket posted to the channel still belongs to the person who posted it. Only they update the user, write the note and close. Helpers help. They do not take over, and they do not go quiet because they assume the thread is the update.

Swarming hours sound like they would slow the desk, and they slow a few tickets by an hour. What they buy is the senior engineer's morning, in one piece, and a desk that can tell "stuck" from "would like a second opinion". Add one exception: a ticket at risk of breaching its target, or an outage, may be posted with that said in the first line. That post gets a reply at once. Everything else waits for 10:00. I have run a swarm of five. Our best month was the second and our worst was the fourth. The only difference was that by the fourth we had stopped keeping the hours.

Tiers Versus Swarming, Side by Side

The honest comparison is a table, because each model wins on some rows and loses on others. Which rows matter depends on your desk. The rows are what a small desk notices first: how fast tickets move, how often people are interrupted, how much the team learns, how far the model scales, and whether you can measure it afterward.

Read down the swarming column and notice how many rows end with "unless" or "if". That is the shape of the model. It beats tiers on speed and learning when a few rules are kept, and loses on every other row the moment they are not. Tiers are slower and harder to break. Swarming is faster and easier to break. Pick on that basis, not on which one sounds more modern.

The Hybrid Most Small Desks End Up With

Most small teams that try both end up with an L1 lane and a swarm behind it. It is a good place to end up. The lane takes every ticket, resolves the known and the simple from a written list, and owns the user. Everything the lane cannot resolve in its time box goes to the channel, with the three-line post. There, the rest of the team swarms it during hours. There is no L2 queue and no L3 queue, only "the lane" and "the rest of us", with vendors behind that.

The hybrid keeps what each model is good at. The known half of the queue never reaches the channel, so the channel is quiet enough to read. The senior people are interrupted only by problems that need them. The unknown ticket gets help in minutes rather than a handoff and a wait. The owner rule carries over unchanged: the lane technician who posted the ticket still owns it, and the swarm is their L2.

The hybrid also fixes the measurement problem halfway. Tickets resolved on the lane without a post are the L1 resolution count. Tickets posted to the channel are, in effect, escalations, and counting them tells you whether the lane's list is long enough. Who takes the lane on which day is in Tiers for a Three-Person Team. The charter that defines what the lane resolves is in L1, L2, L3 in Practice.

Keeping the Record When the Work Happens in Chat

The thread is where the diagnosis happens, and the ticket is where it must end up, because the thread will be gone. Chat channels scroll, get archived, get migrated, and are searched by nobody six months later at 17:40 when the printer does the same thing. The ticket is the record. The owner copies the answer into it before closing: what was wrong, what fixed it, who suggested it, in two or three lines.

Write that copy as an internal note, not as a reply to the user. That lets it be candid about what was wrong with the first guess. The user gets the clean version. In QuerySolv an internal note is never mailed to the requester. The full-text search runs across whole conversations. So a note that says "half a label, USB run too long, short cable plus spooler restart" is findable from "half a label" next time by someone who was never in the channel. Whatever your tool, the test is the same: could a new technician find this fix from the ticket alone?

Then write the knowledge article, if the problem will recur, and credit the helper in it. In a swarm the owner's name is on the resolution and the helper's is in a thread that is about to disappear. That is bad for morale and worse for the numbers. If you want to know who is carrying the desk, the note that says "fix from Marcus" is the only place that fact survives.

A War Story: One Month at Kestrel Payroll

Kestrel Payroll's four-person team dropped their tiers in the spring and moved to a single channel. That followed a month in which escalations had taken a day each to be picked up. The first month was the best the desk had ever had. Median resolution fell by half. The two junior technicians learned more in four weeks than in the previous six months, and the users noticed. In the fifth week Tomas, the team lead, went looking for the status of the backup redesign. Lena, the senior engineer, had owned it since before the change. Tomas found it had not moved in six weeks. Lena's channel history showed why: she had answered between thirty and fifty questions a day, most in under two minutes. She had not had a clear hour since the tiers came down. They kept the channel and added swarming hours, two half-hour windows with an outage exception. They also added an owner rule so that nobody expected Lena to follow up the threads she had answered. The backup redesign finished three weeks later, and median resolution rose by twenty minutes, which the users did not notice.

I have been Lena in that story, and I did not notice for five weeks either. The channel was so pleasant to be useful in that I mistook it for the job.

The Swarming Rules Card

The card is short on purpose, because it is meant to be pinned at the top of the channel and read by someone on their first day. Fill in the hours and the exception before you pin it. Change the hours when the desk changes, and read the card aloud at the first team meeting after anyone joins.

SWARMING RULES                              Channel: ____________
Owner of this card: ____________   Reviewed: __________

1. POST, DO NOT PASS.  A ticket stays with whoever pulled it.
   Nobody escalates. You ask; the ticket does not move.

2. THE THREE-LINE POST.  Every post has, in this order:
   - the ticket number
   - what you have already tried
   - one question
   No screenshots without a number. No "anyone?" without a question.

3. ONE OWNER.  The person who posted owns the user, the updates,
   the note and the close, however many people helped.
   Helpers help. Helpers do not close.

4. SWARMING HOURS.  Everyone reads and answers the channel from
   ____:____ to ____:____ and from ____:____ to ____:____.
   Outside those hours you may post, and you keep working alone.
   Say "looking" within five minutes during hours, or nobody is.

5. THE EXCEPTION.  A ticket at risk of breaching its target, or an
   outage, may be posted at any time with that in the first line.
   It gets a reply at once. Nothing else does.

6. THE RECORD.  Before closing, the owner copies the fix into the
   ticket as an internal note: what was wrong, what fixed it, who
   suggested it. The thread is not the record. The ticket is.

7. THE LANE (if you run the hybrid).  Known and simple problems
   are resolved on the L1 lane from the list and never posted.
   Posting is the lane's escalation; count the posts.

Seven rules is the most a card can hold and still be read. An eighth is usually one of the first seven with a particular person's name attached. The fix for that is a conversation, not a rule.

Ticket 4418 printed its labels at 10:23. The fix is in the ticket in one line with Marcus's name on it. That is the part the channel would have lost. That is swarming done well: the speed of three people in one thread, with a record that outlives the thread. It beats tiers on a small desk with broad skills and the hours kept. It loses everywhere else. The honest thing to do is run the numbers for your own desk, keep the rules, and notice when the senior engineer has gone quiet about the project.

Frequently Asked Questions