IT Support Tiers: Who Handles What On A Small Team

IT support tiers sort tickets by who can fix them. Tier 0 is self-service, tier 1 applies written fixes, and tier 2 diagnoses and fixes within approved limits. Tier 3 takes work that needs specialist skill or changes beyond those limits. One person can hold several tiers.

If you want a tool for the routing below, there's SherpaDesk: a helpdesk and PSA (professional services automation) a small IT team can run alone.

What Are IT Support Tiers?

Tiers are levels of a support team, sorted by how complex an issue is. A simple issue stays low. A harder one moves up to someone with more skill, more access, or the authority to change more.

Ontario's government incident standard, GO-ITS 37, is a public example. Its service desk is tier 1 and tries to fix the issue at first contact with diagnostic scripts. Tier 2 and above are support groups with "progressively greater technical expertise."

You'll also see levels instead of tiers: L1 for tier 1, L2 for tier 2, and so on. Below tier 1 sits tier 0, self-service, which needs no agent at all. Above tier 3, a tier 4 covers vendors and sits outside your organization.

There's no single standard. Some teams run only tiers 0 through 3, and others fold self-service into tier 1. So this guide uses one working model. Tier 2 works within approved scope, access, and authority. Tier 3 takes what needs specialist expertise or changes beyond those limits. If you're still deciding what kind of desk you run, our guide to helpdesk vs service desk covers that first.

Why Tiers Matter On A Small Team

Tiers decide who touches a ticket first, and that decides what each ticket costs you. Tier 0 is the least expensive way to resolve an issue, and solving most of the volume at cheap tiers lowers the cost per ticket.

On a small team the cost shows up as time. Without tiers, your most senior person resets passwords between server jobs. Your newest tech sits on a ticket they can't fix because nobody said when to let go.

Tiers don't require one person per tier. Use separate tiers where the responsibilities really differ. Combine them when one person does both jobs, and arrange outside help for the gaps you can't cover safely.

Practitioners draw the lines in different ways. In one r/ITCareerQuestions thread, a former MSP tech defined tier 1 this way. It's when "there is a documented process for the issue, and T1 has access to complete it." That definition works for a team of two, because it's about the ticket, not the org chart.

What Each Tier Handles

Each tier owns a kind of work and needs a matching level of access and approval. The table is the short version of our working model, and the sections below give the detail.

What is tier 0 support?

Tier 0 is self-service: articles, a portal, and automated resets. It needs no agent at all. Good tier 0 content covers the requests you answer the same way every week.

Someone still owns tier 0, though. On a small team, the tech who closes a repeat ticket writes the article. Our guide to the IT self-service portal covers how to build one.

What is tier 1 support?

Tier 1 is the first human contact point. Tier 1 techs work from scripts, macros, and knowledgebase articles. Their job is to apply the written fixes they're allowed to apply and to log everything else well.

At Ontario's service desk, tier 1 creates the record with the user's contact details, the classification, and the symptoms. That record is what the next tier reads. Classes set at intake decide where a ticket goes next, and our ticket triage guide covers how to set them up.

What is tier 2 support?

Tier 2 support takes the tickets tier 1 can't close. Tier 2 techs carry deeper product knowledge and broader system access. CompTIA's description of the job starts with resolving complex issues "requiring detailed systems and applications knowledge that have been escalated from Tier I."

In our model, tier 2 diagnoses and fixes anything inside the scope, access, and authority you've approved. Tier 2 also trains users and tier 1 technicians, by CompTIA's description. A documented fix becomes tier 1 work only when tier 1 has the skill, access, and approval to apply it. Otherwise, document the checks and the escalation route.

What is tier 3 support?

Tier 3 takes the work that needs specialist expertise, or a change beyond what tier 2 is approved to make. Sometimes no change follows: reading packet captures on an intermittent outage is tier 3 work too. In product companies, tier 3 is often staffed by engineers who split time between support and development. On a small team, you can assign tier 3 to the owner, the IT manager, or a contracted specialist.

The line between tier 2 and tier 3 is yours to draw. A small team might let tier 2 restart a shared service but keep firewall and tenant-wide changes for tier 3. Write the list down.

Tier 4: product and service vendors

Tier 4 sits outside the organization. In this model it means the product or service vendor you need to clear a dependency: the software maker, the hardware maker under warranty, or the internet provider. A contracted MSP or specialist who works your systems is your tier 3, not tier 4.

On a small team, whoever holds tier 3 usually opens the vendor case. Close the incident once the user's service is verified, and keep the vendor follow-up on a linked record with a named owner.

The Skills Each Tier Needs

Each tier has skills you can see in the ticket notes, so widen access on proof, not on tenure. Assess four things at each tier: diagnosis, documentation, communication, and judgment about changes. The US Bureau of Labor Statistics lists what support specialists do. They document the user's description of the problem, guide them through the steps, and tell managers about major or recurring problems.

The qualities BLS names are communication, customer service, listening, and problem solving. All four matter at tier 1, where most users meet IT.

CompTIA describes tier I techs as usually entry-level, with tier II managing and training them. On a small team, that training happens in the ticket, one handoff at a time.

Tier 1 Vs Tier 2 Vs Tier 3: Where The Lines Fall

Put a ticket at the lowest tier whose technician has the skill, the access, and the approval to fix it. A written fix belongs at tier 1 only when tier 1 has all three. Ask four questions in order.

1. Is there a written fix tier 1 has the access and approval to apply? Then it's tier 1, whoever holds tier 1 today.
2. Can it be diagnosed and fixed inside tier 2's approved scope? Then it's tier 2.
3. Does it need specialist expertise or a change beyond those limits? Then it's tier 3.
4. Does the fix depend on a vendor's product or service? Then tier 2 or 3 opens a tier 4 case.

Impact can skip the order. An office-wide outage or a security incident goes straight to whoever can act on it. Risk counts too: route a high-risk change to its approved owner even when the written steps look simple.

So the difference between tier 1 and tier 2 is the written fix and the approved scope. Documentation, access, and approval decide the handoff. Other teams draw the lines by layer. One r/msp member put it this way: "L1 tends to be problems at the user level, L2 for the System, and L3 is the design of systems."

Time is a test too, as long as you write it down. Set each tier's time limit per ticket type, against the restore or resolution target. Another r/msp member wrote that tier 1 "shouldn't be spending anymore than 30 minutes on a ticket without escalating it."

Titles drift from the work. The r/msp thread above started from a member whose desk has T1, T2, and T3/project engineers. They wrote: "I personally feel like my T2's are expected to be Jr. Engineers at this point."

Who Covers Which Tier On A Small Team

On a team of one to five, tiers are hats. The work at each tier still exists, so plan which tiers each person combines and who backs them up.

For who owns the queue, vacations, and projects on a team this size, see our guide to IT department structure. Here are the tier rules that matter when one person holds two tiers.

Log the hop, even when you hand it to yourself. Move the ticket to the next level when the work changes kind. Later you'll see how much of your week was tier 3 work.

Protect a block for tier 2 and 3 work. Constant tier 1 interruptions leave little time for root-cause work. A morning block off the queue, with a callback promise, is one way to start.

Name outside help before you need it. If nobody on the team can safely do a piece of work, name an external specialist now. During an outage is the wrong time to find one.

Swarm instead of passing a ticket around. Teams with low volume but complex cases often do better with swarming. The Consortium for Service Innovation says its Intelligent Swarming method removes tiers of support. It argues traditional tiers "cannot keep up with the demand of complex work in knowledge-intensive environments."

On a three-person team, swarming can be as plain as a ten-minute call on the hard ticket. One r/ITCareerQuestions member described their small team this way: "It's not true escalation for us we all work together as it's a small IT team."

Keep projects out of the tier 3 queue. One r/msp member warned that a tier 3 who is also the project engineer "is a recipe for disaster for you and the client." If the same person must do both, put project days on the calendar and route tier 3 tickets to the deputy on those days.

Handoff Rules Between Tiers

A ticket crosses a tier line by rule, carries its story, and keeps one named contact for the user. The steps below are the path a ticket takes when it moves up.

1. Create the ticket at intake

   For routine work, log the ticket before troubleshooting. For urgent incidents, start recovery and create the ticket in parallel. Ontario's standard requires a logged incident before any tier 2 staff get involved.

   Common mistake: logging the ticket after the fix, from memory, when the details are gone.

2. Try an approved fix when it fits

   For routine tickets, try the relevant approved fix and record the result. For urgent or specialist cases, route the ticket at once and document in parallel.

3. Check the routing rule

   Use the four questions above and the time limit for the ticket type. If none applies, keep working it.

   Common mistake: escalating because the user is impatient. A complaint can call for a manager, but it doesn't make a ticket harder.

4. Hand off with the note your team agreed on

   Use one handoff note for every hop, so the receiver knows where to look. Our escalation matrix template has one you can copy, plus owner and backup fields per ticket type.

5. Keep one named contact for the user

   By default, whoever logged the ticket stays the user's contact until it closes. The contact changes only when the ticket says so.

6. Send the fix back down

   When tier 2 or 3 solves a repeat issue, write it up. It becomes a tier 1 article only if tier 1 has the skill, access, and approval for the steps; otherwise the article is a routing note. The same former MSP tech described tier 2 as "responsible for creating documents/checklists so that more issues become Tier 1 over time."

The four questions decide when a ticket moves. The table covers what changes hands at each boundary.

Urgent work comes first, notes come in parallel. For an outage or a security incident, the receiver accepts at once and asks for missing details while working.

Otherwise, send it back when the story is missing. A routine ticket that arrives with "doesn't work" and nothing else goes back with one question. One r/ITCareerQuestions member described the minimum they expect from tier 1. "I do expect 1's to at least ask questions, get screenshots and say great we'll pass this on to an expert."

How Tiers Work At An MSP Vs Internal IT

The tiers are the same. What changes is who approves the work and where the targets come from.

For an MSP, the tier lines are a promise to a client. An MSP is a third party that manages a customer's IT remotely, and its SLA spells out the metrics that govern the relationship. Meet the initial-response target on its own. Then set each tier's time limit against the restore or resolution target in the contract.

In internal IT, define the same scope and ownership against your organization's service commitments. A school district with two techs might keep tiers 1 and 2 in-house and contract an MSP as its tier 3 for network work.

Some internal teams do the reverse and send tier 1 overflow to an MSP in busy weeks. Either way, keep one named contact per ticket.

Example: A Printer Ticket Through The Tiers

Say you run a three-person MSP. A junior tech holds tier 1, a senior tech holds tier 2, and the owner holds tier 3. At this MSP, changes to a client's shared server are tier 3 work. A client's accounting team calls in at 9:05 a.m.

Each hop was a note on the same ticket, and the junior tech stayed the client's contact. Tier 1 gained a clearer routing note; the server repair stayed with tier 3.

Common Mistakes With IT Support Tiers

1. Using tiers as pay grades

   When "tier 2" means a raise and not a scope, nobody knows where a ticket belongs. Keep titles if you need them for pay, but route by the written scope.

2. Giving tier 1 no access

   A tier 1 tech who can't reset a locked account escalates everything. Grant the access each written fix needs, and log who used it.

3. Letting the best tech take every hard ticket

   Your strongest person becomes the queue. Rotate tier 2 work so a second tech learns it, and keep the senior tech for the cases that need them.

4. Never reviewing the hops

   Repeated escalations, long waits between tiers, and tickets reopened after a hop show where training, routing, or capacity falls short. Repeated tier 1 escalations may call for a tested article; growing tier 3 waits may call for backup capacity.

Run Your Tiers In SherpaDesk

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.

All Articles