What Support Tiers Are Actually For

It is 09:04 and Marcus is resetting a password. Marcus built the virtualization cluster and understands the backup chain. He is the only person at Meridian Parts who knows why the finance server has two network cards. He is doing the reset carefully and well. Across the room, nobody is looking at the alert about the data volume on files.example.com. The volume has crossed ninety percent and is climbing a point an hour. Nobody is looking at that alert because everybody is looking at the queue. The queue is thirty-one tickets deep, sorted by arrival, and visible to all four people on the desk. Whoever is free takes the next one. Marcus was free.

Nobody designed that. A desk with one queue and no tiers routes every ticket to everyone. That means the most expensive hour in the building is spent on whatever arrived most recently. This is the first article in our Support Tiers series. And it is about what tiers are for, which is not what the diagrams suggest. A support tier is a lane that a ticket is routed into according to what it needs. The lane is staffed by people who can give it that. L1, the first line, takes every ticket, resolves the known and the simple, and owns the relationship with the user. L2, the second line, does deeper diagnosis with system access and takes the unknown-but-solvable. L3, the third line, is the specialists, engineers and vendors who change systems rather than fix things inside them.

This article covers the three jobs tiers do and the four costs they bring. It explains why a tier is a routing decision and not a rank, and the four parts every tier is built from. Then come the signs you need tiers and the signs you have too many, and the alternative, in one paragraph. We cover what happened when Northgate Retail finally built an L1 lane, then the arithmetic to run before you draw a line. A worksheet settles the question for your own desk, with a score.

The Three Jobs Tiers Do

The first job of a tier is to protect expensive time. Every desk has a few people whose hour is worth more to the organization than anyone else's. That is not because of pay but because of what only they can do: rebuild the cluster, recover the database, answer the auditor. A password reset costs the same ten minutes whoever performs it, but the ten minutes are not the whole bill. Pulling a specialist off a deep problem costs the ten minutes plus the twenty it takes to get back into the problem. And the queue will do it again at 09:40.

The second job is to match skill to problem. Most tickets are known: they have been seen before. The answer is written down or in somebody's hands, and they want fifteen minutes of calm attention. A smaller number are unknown but solvable with access and time. A few need a change to a system rather than a fix inside it. One queue treats those three kinds as one kind. So the known ticket waits behind the hard one. And the hard one gets fifteen minutes from someone who needed a day.

The third job is to give junior people a lane to grow in. Consider an L1 lane with a written list of what it resolves. There, a new technician can be competent on the first Monday and good by the third. Without it, the junior person is handed the same queue as everyone else and picks a ticket. They find out halfway through that it needs a right they do not hold, and hand it on. They learn to pass things. That is a skill, but not the one anyone wanted them to learn.

Put the three jobs together and a tier is a filter. It keeps predictable work with the people who can do it fast and unpredictable work with the people who can do it at all. The diagram with seven levels and a vendor stack in the corner is describing something else. Nobody has ever needed seven.

The Costs Tiers Introduce

Tiers cost handoffs, and a handoff is the moment a ticket changes hands and loses something. The user told L1 what happened; L1 wrote down part of it; L2 reads the part and asks the user again. Each hop adds a wait, a re-read, and a chance for the ticket to arrive with the note "see above", where above is empty.

Tiers cost waiting. A ticket escalated at 11:00 into a queue nobody opens until 14:00 has spent three hours doing nothing. The user does not know which tier it is sitting in. They know it is Tuesday and the thing is still broken. One queue has no such gap, which is the honest argument for having no tiers at all.

Tiers create the "not my tier" reflex. Once a boundary exists, a ticket that lands on the wrong side of it belongs to somebody else. Then the fastest thing to do with it is move it. A desk can get very good at moving tickets. I have watched one visit four queues in a day, collect four assignees and no notes, and return to the first queue slightly older. It had not been worked on. It had been toured.

Tiers lose information at every step unless the handoff carries it on purpose. What the user reported, what was tried, what was found, what is being asked: four lines, and the higher tier starts where the lower one stopped. Without them the higher tier starts from the beginning, and the user explains the problem a third time. The deeper tier then spends its first twenty minutes repeating the shallow work. The content of that handoff has its own article, Escalation Boundaries That Hold. The point here is that every cost of tiers is a cost of the boundary, and every one of them shrinks when the boundary is written down.

Tiers Are a Routing Decision, Not a Rank

A tier is a routing decision: this kind of ticket goes to this lane. It is not a ladder of seniority, though it is usually drawn as one, and the drawing does damage. When tiers are read as rank, L1 becomes the place you start and leave. In that reading, L3 becomes the place you arrive and stay. Escalation then becomes a request for permission to speak to the important people.

Read as routing, the same structure says something calmer. L1 is where known problems go because they resolve fastest there. L3 is where system changes go because changes need a window, a plan and a way back. Neither lane is above the other; they sit side by side, joined by a handoff. A senior administrator can take the L1 lane for a week and lose nothing but interruptions. (The project they were failing to finish will notice the difference.)

The rank reading produces "kick it upstairs", which is escalation as a sport. The ticket goes up because up is where responsibility ends, not because the next tier can do anything the current one cannot. The routing reading cuts that off at the root. If the ticket does not need what the next lane has, it does not go to the next lane. What the next lane has is an access right, a skill or a change window. It does not matter how tired of the ticket the current lane is. The sport has no winner. The ticket does accumulate air miles.

What a Tier Is Made Of

A tier is made of four things, and if one is missing the tier is a name. The first is a queue: a place in the ticket tool where this tier's tickets live. Someone owns it and opens it on a schedule. A tier that shares a queue with the tier above it is a label on a column, and labels do not route anything.

The second is a skill list: a written statement of what this tier resolves without escalating. "Password resets, account unlocks, the twenty entries on the known-error list, and printer or drive-mapping problems on the standard build" is a skill list. "First-line support" is a hope.

The third is an access list: the accounts and rights the people in the lane hold, and therefore what they can physically do. A tier's skill list may include resetting passwords while its access list does not include the right to reset them. That tier will escalate every reset. And the tier above will wonder why. Make the access list real in the ticket tool as well as in the directory. That way, the lane can do in the tool exactly what its list says. QuerySolv does this with twelve granular per-agent permissions and four presets from Trainee to Senior. Whatever your tool offers, the principle is that the lane's rights and the lane's list match.

The fourth is a time box: how long this tier works a ticket before it must resolve it or escalate it. Thirty minutes of L1 effort is a common number; "any ticket that needs a change to a server" is a common boundary. The time box stops two failures at once. One is the ticket escalated after four minutes because it looked hard. The other is the ticket held for three days because it looked close.

The Signs You Need Tiers

The sign that you need tiers is a pattern, not a feeling. And the pattern is always one of two: expensive time spent on cheap problems, or cheap problems waiting behind expensive ones. The table lists the symptoms as they show up on a small desk, with what is happening underneath and the tier that would fix it. Two of these is enough to start drawing a line.

Read the right-hand column and notice that the fix is nearly always one lane, not three. Most small desks need an L1 boundary and nothing else. In that setup, L2 is everyone who is not on the lane. L3 is the vendor plus the one person allowed to touch the firewall. That is a tiered desk. It is allowed to be that small.

The Signs You Have Too Many

You have too many tiers when one exists with no queue, no list, no access and no time box of its own. In other words, you have too many when a tier is a word. The classic is the three-person team with four tiers, one of them called L2.5. It is staffed by the same person who is L1 on Fridays and L3 whenever the vendor calls back. Each extra boundary adds a handoff and a wait without adding a capability, because the same hands do the work on both sides of it.

The test is capability. Ask of every boundary: what can the lane on the far side do that the lane on the near side cannot? If the answer is "nothing, but it is a different person", the boundary is an org chart, not a tier. In that case, the ticket is paying the handoff cost for no return. Merge the lanes and keep the one boundary that marks a real change in access or skill.

A three-person desk's honest answer is usually one and a half tiers: an L1 lane that rotates, everyone else as L2, and vendors as L3. That version is drawn out in Tiers for a Three-Person Team. I have run a desk with no tiers and a desk with four. The second was worse, and it took longer to notice, because it had a diagram.

The Alternative, in One Paragraph

The alternative to tiers is swarming. Whoever is available pulls the ticket, keeps it, and asks for help in the open, usually in one chat channel, rather than passing it up. Swarming removes the handoff entirely, and with it the waiting and the lost information. It works well on a small team with broad skills and a habit of asking. It fails at volume, with narrow specialists, and whenever "everyone helps" turns into the senior engineer being interrupted forty times a day. That happens unless somebody writes a rule. Where swarming wins, where it loses, and the hybrid most small teams end up with are in When Tierless Swarming Beats Tiers. The rest of this article assumes you are at least considering a lane.

A War Story: Two Years at Northgate Retail

Northgate Retail ran the desk for forty stores with two senior administrators, Tomas and Priya, and one queue. For two years they took every ticket between them, because both could resolve anything and that seemed faster than explaining. In the same two years the server patching cycle slipped six months behind. That was not from neglect but because every planned patch window turned into the afternoon a store's till failed. When Sam joined as a junior technician they wrote a one-page L1 list. They gave him the queue and the rights to work it. They told him to escalate anything not on the page after thirty minutes. Within a quarter the hours the two of them spent on tickets had fallen by two thirds. The patching caught up in eight weeks, and store tickets resolved faster. That was because Sam was watching the queue while they were watching a server. Nobody had done anything wrong for two years; the queue had been routing everything to everyone, and they had let it.

I keep that story because of the patching. Nothing in the queue ever said "six months behind". The queue only ever says "next".

The Arithmetic of One Lane

Before you draw the line, count. Dana runs the desk at Meridian Parts, sixty people and three on the desk. One Friday afternoon she exported a month of closed tickets and sorted them by what each had turned out to need. The numbers are hers. The shape is everybody's.

Of 214 tickets, 139 had needed nothing but a known answer. There were 41 password resets and unlocks, 33 access requests, 28 printer and drive-mapping problems, and 37 how-do-I questions with an article already written. Another 58 had needed real diagnosis with administrative access, and 17 had needed a change to a server, a firewall rule or a vendor case. The 139 known tickets had been resolved by whoever picked them up. That meant 61 of them had been resolved by Marcus, the one person on the desk who could rebuild the cluster.

Dana costed the 61 at twelve minutes each, which is a little over twelve hours of Marcus's month. Then she added the part the ticket tool does not show. There were 61 interruptions, each followed by a climb back into whatever deep work he had been doing. At twenty minutes a climb, that was another twenty hours. Thirty-two hours a month, about four working days, spent by the most specialized person on the desk doing the most routine work on the desk. She drew the L1 line the following Monday, with the lane owning the four known categories and a thirty-minute time box. A month later Marcus had resolved nine known tickets, all of them during the two afternoons he had taken the lane on purpose.

Your numbers will differ, and the method is the same. Take one month, three buckets (known, unknown-but-solvable, needs-a-change), and the name on each ticket in the known bucket. If the expensive names show up there more than a handful of times, you have found your first tier. If they do not, you may not need one yet, and the worksheet below will say so.

The "Do We Need Tiers?" Worksheet

The worksheet is eight yes-or-no questions, one point for each yes. Score it with the people on the desk rather than about them; the answers are about the queue, and the queue has no feelings. Count the points and read the key beneath the table.

Here is the key. Zero to two points means no tiers yet. Keep one queue, write the known-error list anyway, and score again in a quarter. Three to five points means one L1 lane with a queue, a list, matching rights and a thirty-minute time box. In that case, everyone else is L2 and the vendor is L3. Six to eight points means the L1 lane plus a written L3 boundary for changes to systems. That way, fixes and changes stop sharing an afternoon. Nothing on the key says four tiers, because nothing on a small desk ever does.

Marcus is still resetting the password at 09:04, in the sense that every desk without a lane has a Marcus and a volume at ninety percent. The lane does not make the reset disappear. It sends the reset to the person who was going to be looking at the queue anyway, and lets the other one look at the disk. That is the whole of what tiers are for, and it fits on one page. The next article in the series takes the three lanes one at a time. It sends a single ticket through all of them, with the clock running.

Frequently Asked Questions