Tiers for a Three-Person Team
It is 08:35 on a Monday. Three people, one queue, nineteen tickets that arrived over the weekend, and a project plan that says the file server move finishes this week. Dana opens the queue. Marcus opens the queue. Priya opens the queue. All three start reading from the top. By 08:50 two of them have replied to the same user about the same printer. Nobody has opened the ticket from the finance director with "urgent" in the subject line, because it is eleventh.
Who is first line on this team? Everyone, which is the same as nobody. Tiers are usually described for desks with a room of first-line technicians and a separate room of engineers. A three-person team reads those descriptions and concludes, reasonably, that tiers are for other people. This article is part of our Support Tiers series. It is about the version that fits three people: not three tiers, and not none, but one and a half.
It covers what one and a half tiers means (a first-line lane that rotates, everyone else as second line, vendors as third). Then it covers how the rotation runs and why weeks beat days, and what the lane resolves and what it hands on. Next come who covers what when someone is out, with a table, and how the lane protects project time for the other two. Then comes the signal that the lane is too much for one person and the fix. It ends with a week worked through with numbers, a war story, and a one-page operating sheet to copy.
One and a Half Tiers
The realistic tier structure for three people is one rotating first-line lane with everyone else behind it. First line, or L1, takes every ticket, resolves the known and the simple, and owns the relationship with the user. Second line, or L2, does the deeper diagnosis, has the system access, and takes the unknown-but-solvable. Third line, or L3, is specialists and vendors, and changes systems rather than fixing things inside them. On a big desk each of those is a group of people. On a three-person team, first line is a role one person holds at a time. Second line is the other two for their own areas. Third line is whoever you pay for support contracts.
The "half" is second line. It is not a queue and not a job. It is a promise. The two people who are not in the lane will not be interrupted by the queue unless the lane holder escalates to them, by name, with a note. Second line on a three-person team is mostly a form of protection, which is also what second line is for on a big desk. It is just easier to see at this size.
Why not three full tiers? A tier is a queue, a skill list, an access list and a time box. Three people cannot staff three queues without each queue being one person, which is a seating plan with extra steps. Why not none? Because the Monday above is what none looks like: three people reading one queue, and the queue read three times and worked zero. What Support Tiers Are Actually For is the longer argument. The short one is that the senior people need a lane between them and the password resets.
On a three-person team the specialist is also first line on Fridays. The lane does not change that. It changes it from a surprise into a schedule.
The Rotation: One Person Owns the Queue
One person owns the whole queue for a fixed period, and the other two are protected unless escalated to. That is the rotation, and the period matters more than it sounds. A daily rotation feels fair and is a mess. A ticket opened on Monday has been handled by three people by Wednesday, each one re-reading it from the top. The user has had three names. A weekly rotation gives the lane holder continuity. They see a ticket from open to close, they learn what the week's pattern is, and the user has one name.
I have run both. Days felt fair and were a mess. Weeks felt long and worked.
The handover is Friday at 16:00, fifteen minutes, and it is a list, not a conversation. It lists the open tickets, which ones are waiting on a user or a vendor, and anything promised for Monday. The order of rotation is fixed and visible on a calendar, and the queue tool's default assignee changes with it. So a ticket that arrives at 03:00 on Tuesday already belongs to the right person. The lane holder does no project work that week. That is the deal, and it is the part people try to renegotiate by Wednesday.
Without a rotation, the queue is owned by whoever feels guiltiest, which is usually the same person every week. They stop being the specialist in anything except guilt. With one, each person spends one week in three being interrupted and two weeks in three being left alone. That is a better ratio than most desks of any size manage.
What the Lane Resolves, and What It Hands On
The lane resolves the known-error list, resets and unlocks, access requests inside policy, and the ten ticket types that make up most of the volume. A known-error list is the running list of problems with a known cause and a written fix. On a three-person team it is a page, and the lane holder adds to it. Everything else escalates to the person who owns that area, by name, with the four-line handoff note. The note says what the user reported, what was tried, what was found, what is being asked. Escalation happens after at most thirty minutes of effort. Escalation Boundaries That Hold has the four lines and the time box in full.
| Ticket type | The lane does | Hands to | Note |
|---|---|---|---|
| Password reset, account unlock | Resolves after the identity check | Nobody | On the lane's list on day one |
| Anything on the known-error list | Applies the written fix | Nobody | Adds a count to the entry |
| Access inside policy | Grants it, records it | Nobody | Outside policy goes to the area owner |
| How-to and "where is" questions | Answers, writes the article if asked twice | Nobody | The top ten live here |
| Server, network, shared system faults | Up to thirty minutes of checks | Area owner, with four lines | Any system change goes at once |
| Business application faults | Up to thirty minutes of checks | Area owner, then vendor | The lane keeps the user updated |
| Hardware failure | Swap, loaner, or order | Vendor if under warranty | The lane owns the ticket throughout |
| Many users at once, security sign, lost data | Escalates within five minutes | Area owner, by voice | No time box |
The lane also owns the user, all week, even when the work is at second line. Every update to the user comes from the lane holder. That way, the user has one name and the specialist has no inbox full of "any news?" The acknowledgment and the "this is with Marcus, next update by 15:00" message are two predefined replies. The four lines go in an internal note. In QuerySolv, predefined replies and internal notes that are never mailed are both built in. That is the shape any tool should give you.
What happens when the lists are missing is that the lane holder escalates on mood. On a quiet day they keep everything; on a bad day they pass a reset to the network specialist. The two protected people are then interrupted anyway, and the rotation has bought nothing.
Who Covers What When Someone Is Out
The coverage table is written before anyone is out, because the morning someone is out is the morning nobody has time to decide. Three people, three kinds of absence, one line each. The rule underneath all of them is that the lane is never empty. Somebody owns the queue every working hour, even if that somebody also owns everything else that day.
| Who is out | Who takes the lane | Where their escalations go | What waits |
|---|---|---|---|
| The lane holder, unplanned, a day or two | Next person in the rotation | The third person covers both areas up to the time box, then the vendor | The covering person's project, for those days |
| The lane holder, planned leave | Swap lane weeks in advance; nobody does two in a row | Unchanged | Nothing, if the swap is on the calendar |
| A second-line person | Unchanged | Lane holder tries up to the time box, then vendor or wait, with the user told the date | Changes to that person's systems, unless it is an incident |
| Two people | The remaining person, and nothing else | Vendors are second line for the day | All project work; the escalate-now list still applies |
The table is the only document on the desk that gets read exclusively at 07:50 by someone with a cold. Keep it to one screen, keep it next to the rotation calendar, and update it when anyone's area changes. When two people are out the third is running a solo desk for the day. The One-Person IT Department series is the manual for that.
Protecting Project Time
The lane is the interrupt sponge, and the point of a sponge is that the other two stay dry. Give them mornings: from the start of the day until lunch, no queue and no chat pings about tickets. In that time, redirect walk-ups with one sentence, "Dana has the lane this week." After lunch they are reachable for escalations. The lane holder's name goes on the auto-reply, the chat status and the door. That way, users do not have to guess, and the specialist does not have to be the one saying no.
The reason is the cost of an interruption. It is not the two minutes it takes but the twenty minutes it takes to get back to where you were. Twenty interruptions a week is a day gone, and on a three-person team a day a week is a third of a person's project capacity. The rotation does not make the interruptions disappear. It puts them all on one person, who has agreed to it, for a week.
Without protected time, projects slip and the slip is invisible, because everyone is busy and busy looks like progress. The file server move from the opening scene is three weeks late by the time anyone notices. Nobody can point to the week it was lost, because it was lost in two-minute pieces.
Do not let the lane holder "just finish one small project thing" during their week. They will not, and neither will the queue.
When the Lane Is Too Much for One
The signal that the lane has outgrown one person is a queue that is still being acknowledged at 11:00. There are other signs. The lane holder escalates at minute five because there is no time to try anything. The known-error list stops growing because nobody has ten minutes to write. The oldest unacknowledged ticket is over an hour old every day, not just on Mondays. Somewhere around twenty-five to thirty tickets a day, one person resolving in full rather than routing runs out of hours. The number depends on what the tickets are, so treat it as a rough edge, not a rule.
The fix is a half-day split, not a fourth tier. The lane holder keeps mornings, when the volume arrives. A second person takes the lane from lunch, with the same lists and the same four lines. Nobody else's protection changes. The other fix is to cut the volume at the source. The top ten by count are the ones to write user-facing articles for and to automate where a form can replace a conversation. A lane holder is the right person to notice which ten.
Some three-person teams add an hour a day when all three work the queue together, in one chat channel, pulling tickets and asking each other in the open. That is swarming, and When Tierless Swarming Beats Tiers explains where it works and where it eats the week. As a bounded hour behind a lane, it is the hybrid most small teams end up with.
Remember: the lane is a role, not a person. If the same name is in it three weeks out of four, you have a dedicated first-line technician and two people who have stopped rotating.
A Week in the Lane at Acme
Acme's IT team is Dana, Marcus (servers and network) and Priya (business applications, including the finance system). Dana has the lane this week. Monday 08:30: nineteen tickets from the weekend. By 09:15 all nineteen have an acknowledgment with a next-update time, from one predefined reply. Eleven are on the lane's list: three resets, two access requests, four known errors, two how-to questions. By noon nine of those are closed. The finance director's "urgent" ticket, which was a locked account, was resolved at 09:22 because it was read eleventh but sorted first.
Over the week, fifty-four tickets arrive. Dana resolves forty-three in the lane, which is four in five. Eight go to second line with the four lines. Five go to Marcus (two switch ports, a backup alert, a VPN client, a printer that was a network problem). Three go to Priya (two finance-system errors and a report that would not run). Three go on to vendors through Marcus and Priya. Marcus is interrupted by the queue five times in the week. Before the rotation, by his own count, it was about twenty.
Thursday Dana is out with a cold. The coverage table says Priya takes the lane and Marcus is the escalation point for everything. Priya's project day is lost, the first-response time for Thursday is twenty-two minutes instead of fifteen, and nothing else changes. Friday at 16:00 Dana is back, and the handover list has six open tickets: four waiting on users, two with vendors. Marcus takes the lane on Monday. Priya's finance-system test plan, which she had carried for a month, is finished and sent.
A Short War Story: Meridian Parts
Tomas, Lena and Sam ran IT at Meridian Parts, and for a year the rule was that everyone took tickets. Lena, who was curious about why the warehouse scanner project kept slipping, counted one week. Lena found that Tomas had been pulled off it twenty-two times by tickets that any of them could have handled. They tried a weekly first-line lane, with a page listing what the lane resolved and a rule that the other two got mornings. In the first month, Tomas and Sam were each interrupted fewer than ten times a week, down from more than twenty. The median time to resolve a ticket fell from a day and a half to under four hours. That was because one person saw each ticket from open to close instead of three people seeing a third of it. The scanner project finished the following month. Nobody had worked harder; the work had stopped being passed around.
There is a surprise in that story, for them and for me when I first ran a lane. The queue got faster, not slower, when two people stopped looking at it.
The Three-Person Operating Sheet
The sheet below is one page, and it is the entire tier design for a team of three. Fill it in, pin it where the queue is visible, and review it when anyone joins, leaves, or changes area. The rotation and the coverage table are the parts that get read. The lists are the parts that get argued about, which is what they are for.
THREE-PERSON OPERATING SHEET Reviewed: ________ Owner: ________
PEOPLE AND AREAS
A: ____________ area: ______________________
B: ____________ area: ______________________
C: ____________ area: ______________________
THE LANE (first line; one person, one week; no project work that week)
Rotation: week 1 A, week 2 B, week 3 C, repeat. Calendar: ___________
Handover: Friday 16:00, fifteen minutes, open list only.
Default assignee in the tool changes with the lane.
The lane owns every user update, even when the work is at second line.
THE LANE RESOLVES THE LANE HANDS ON (four lines, within 30 min)
known-error list server/network faults -> area owner
resets and unlocks application faults -> area owner -> vendor
access inside policy any system change -> area owner, at once
the top ten: __________ many users / security / lost data -> by voice,
______________________ within five minutes
PROTECTED TIME (the two not in the lane)
Mornings, start to 12:00: no queue, no ticket pings, walk-ups redirected.
Afternoons: reachable for escalations from the lane holder only.
COVERAGE
Lane holder out, unplanned: next in rotation takes the lane; third
person covers both areas to the time box, then vendor.
Lane holder on leave: swap weeks in advance; never two in a row.
Second-line person out: lane holder tries to the time box, then vendor
or wait; user told the date. No changes to their systems.
Two out: the remaining person is the lane and nothing else.
THE LANE IS TOO MUCH WHEN: still acknowledging at 11:00; escalating at
minute five; known-error list not growing. Fix: half-day split.
Where This Stops Applying
With two people, the lane alternates weeks and there is no cover for cover. At that size, the sheet still works, with the coverage table reduced to one line that says "the other one." With one person, there is no rotation, and the problem is boundaries rather than tiers. The solo series linked above is written for that. With five or six people, a standing lane of two and a real second line start to make sense. The boundaries then need writing down properly, because at that size they stop fitting in anyone's head.
The lane cannot shield a person from the one thing only they can do. If Priya is the only one who understands the finance system, every finance ticket reaches Priya whichever week it is. The fix is not a tier. It is an afternoon with Priya and a document, until the lane can do the first thirty minutes of a finance ticket without her.
Next Monday, one person opens the queue. The other two open their project plans. It is a small change, and it is most of the difference.
Frequently Asked Questions
Should the lane rotate daily or weekly?
What does the lane holder do when the queue is quiet?
Who answers the phone and the walk-ups?
What if one person is much better at the lane than the others?
Does the lane holder do any project work during their week?
How do we handle a user who always goes straight to Marcus?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.