L1, L2 and L3 Support Levels Explained: Who Does What and How Tickets Move Between Them

The short version: L1 (level 1, tier 1) support is the first line: it logs the ticket, identifies the problem and fixes the routine ones. L2 handles issues that need deeper technical work or access L1 does not have. L3 is the specialist level that deals with the hardest faults, often alongside vendors or engineers. A good tiered model has clear entry rules, written handover notes and defined time limits, so a ticket moves up quickly instead of bouncing around.

If you have ever raised an IT ticket and then watched it pass between people with different names for the same job, you have met tiered support. The labels L1, L2 and L3 (or tier 1, tier 2, tier 3) are one of the oldest ideas in IT service management, and they are still how most service desks describe who does what. The labels are simple. The practice is not, because the real work is in the handovers: what does each level promise to do before it escalates, and what does it pass on?

This guide explains what each level does, how a ticket moves from one level to the next, and how organisations that outsource part of their IT support usually divide the tiers between themselves and a provider. Where we describe the standard model we cite public sources and the date we read them. Where we describe what to ask a provider, we say so, because the way tiers are staffed differs from one provider to another and is not something we can claim for others.

What do L1, L2 and L3 mean in IT support?

They are three levels of technical depth. A user problem enters at the lowest level that can reasonably solve it and is passed up only when that level cannot.

Wikipedia's article on technical support, which we read on 28 October 2026, describes the three-tier model this way. Tier I (level 1, abbreviated T1 or L1) is the first technical support level. Its first job is to gather the customer's information and work out the underlying problem. Tier II (level 2) is more in-depth than tier I, and costs more because the technicians are more experienced. Tier III (level 3) is the highest level in a three-tiered model, responsible for the most difficult or advanced problems, staffed by subject-matter experts who support the lower tiers and help develop solutions for new or unresolved issues.

Different organisations use different names for the same layers. You will also see "first line, second line and third line", "frontline, back-end and expert", or "service desk, desktop support and engineering". The names matter less than the rules for moving between them.

Some organisations add layers at either end:

1. Level 0 (self-service): a knowledge base, a password reset portal, an automated assistant. Users solve routine problems without a human.
2. Level 4 (vendor or product engineering): the software or hardware maker, or an in-house development team, who can change the product itself.

What does L1 support do?

L1 is the front door. It is the first person or system a user reaches, and its job is breadth, not depth.

Typical L1 responsibilities:

1. Receive and log every contact, whether by phone, email, chat or portal, so that each one becomes a ticket with a number.
2. Identify the user and the service affected, and capture the symptoms in the user's own words and with any error message or screenshot.
3. Set the priority, using the agreed impact and urgency rules. If you want to see how that works, read our guide to severity vs priority in IT incidents.
4. Fix the known and routine problems from a script or knowledge-base article: password resets and account unlocks, mailbox and printer issues, basic connectivity checks, standard software installs, and how-to questions.
5. Check whether the issue is already known, for example an ongoing outage, so that duplicates are linked instead of worked separately.
6. Keep the user informed at agreed intervals.
7. Escalate with a good handover when the issue is outside L1's scope or time limit.

The skill that matters most at L1 is not deep technical knowledge but diagnosis and communication: asking the right questions, recognising patterns, and writing a ticket that the next person can act on without calling the user back.

What does L2 support do?

L2 takes the tickets that L1 cannot close. It has deeper technical knowledge, wider access and more time per ticket.

Typical L2 responsibilities:

1. Review the L1 notes first, so the user is not asked the same questions twice.
2. Troubleshoot beyond the script: server and network issues, application faults, group policy and device management problems, permissions, and problems that need remote access to the user's device or to a back-end system.
3. Make changes within approved limits, such as configuration changes covered by an existing standard change.
4. Handle on-site or hands-on work, or dispatch field engineers, when remote methods are not enough.
5. Identify patterns across tickets, and raise a problem record when several incidents share a cause.
6. Update the knowledge base, so that what L2 learns today becomes an L1 fix tomorrow.
7. Escalate to L3 when the fault needs deep product, architecture or code knowledge.

Wikipedia's description notes that L2 is also responsible for assisting L1 staff with basic technical problems, which is why many teams run a short "help me" channel between the two levels.

What does L3 support do?

L3 is the expert level. These are the engineers, architects or specialists who understand a platform in depth and who are expected to solve problems nobody has solved before in that environment.

Typical L3 responsibilities:

1. Analyse root cause of complex, recurring or high-impact incidents.
2. Design and apply fixes that need changes to architecture, code, integration or security controls.
3. Work with vendors and manufacturers, including opening and managing cases at the highest support tier the vendor offers.
4. Support L1 and L2 with advice and with new procedures for issues that have no known fix.
5. Take part in major incidents as technical leads. For how that process works, see our guide to major incident management.
6. Feed lessons into the knowledge base and into change planning, so that the same fault is not rediscovered next year.

L3 time is the most expensive time in the model. A healthy tiered system is therefore built to keep L3 available for work that only L3 can do.

How should a ticket be handed from one level to the next?

Most failures in tiered support are failures of handover. A ticket that arrives at L2 with the note "user cannot log in, please check" has lost the work L1 already did. A good handover follows a fixed shape.

Every escalation note should contain:

1. Who is affected: the user, their location and device, and how many others are affected.
2. What the symptom is: in the user's words, with the exact error text and the time it started.
3. What has been tried: each step taken, with the result, so nobody repeats it.
4. What the priority is and why: the impact and urgency chosen.
5. What is needed from the next level: a specific question or action, not a general "please look".
6. Where the user is up to: what the user has been told and when the next update is due.

Handover rules that keep tickets moving:

1. Escalate on skill: if the issue is not in the L1 script or knowledge base, escalate rather than guess.
2. Escalate on time: set a limit for each priority after which an unresolved ticket moves up automatically. A P1 might have minutes, a P4 might have days.
3. Escalate on risk: any sign of a security incident, data loss or wider outage goes up immediately, whatever the time limit.
4. Keep ownership visible: the ticket remains with a named person or team at all times, and the user always has one contact.
5. Allow a hand-back: if L2 finds the issue was a user-access or process issue, it can be sent back to L1 with a note, which is how the knowledge base grows.

The time limits come from the SLA. Brocent publishes its response targets by priority level on its SLA page, which we checked on 28 October 2026: P1 and P2 have a 15-minute first response, P3 has 30 minutes, and P4 and P5 have 60 minutes. Those are first-response targets under the standard 8x5 or premium 24x7 service window, and the page notes they are subject to contract terms. For a plain-language explanation of each level, read P1 to P4 priority levels in an IT support SLA. Our P1 response time is public, and you can see it on the managed IT support plans and per-user pricing too.

The rules above are for moving up the tiers. For the contacts, time limits and notification steps beyond L3, such as who is told when a P1 is not resolved after a set time, read the companion guide to the IT escalation matrix template.

How do you split L1, L2 and L3 when you outsource?

Outsourcing does not have to be all or nothing. Organisations usually choose one of a few common splits. The right one depends on how much IT knowledge you keep in-house.

Option 1: Outsource L1 only

1. The provider handles: logging, triage, routine fixes, and escalation to your internal team.
2. Your team handles: L2 and L3, the systems it knows best.
3. Suits: a company with a capable internal IT team that is spending too much time on password resets and how-to questions.
4. Watch for: poor handover notes, and an internal team that is interrupted by escalations that L1 should have solved.

Option 2: Outsource L1 and L2, keep L3 internal or with vendors

1. The provider handles: the whole service desk and the desktop, network and server work behind it.
2. Your team handles: architecture decisions, business applications and vendor relationships.
3. Suits: a company that wants day-to-day IT run for it but keeps a small team or a single technology lead.
4. Watch for: unclear boundaries on who may change what, and slow hand-offs for applications the provider does not know.

Option 3: Outsource L1 to L3 for the standard estate

1. The provider handles: all three levels for the infrastructure and tools it manages, with vendor escalation.
2. Your team handles: business-specific applications and the relationship with the provider.
3. Suits: organisations with no in-house IT staff.
4. Watch for: applications outside the agreed scope, which should be named in the contract so they do not fall between the two parties.

What to write down in whichever model you choose

1. A one-page scope list of systems and services, and which level of which party owns each.
2. The hours in which each level is available, because a 24x7 service desk may have L2 and L3 on call only.
3. The escalation path in both directions, including your own contacts for the provider's L3.
4. Who may make changes, and who must approve them.
5. The reports you will receive: tickets by level, time to resolve, how many were solved at L1, and how many bounced between levels.

For an outline of how a provider's service desk works around the clock, see our overview of 24x7 help desk IT support. If you want to talk through which split suits you, you can contact us.

Which level would handle which kind of ticket?

The examples below are illustrative. Your own scope list decides the real boundaries, but they show how the levels differ in practice.

1. A user forgot a password: L1, from the reset procedure, in one contact.
2. A laptop will not join the Wi-Fi network in one office: L1 checks the basics and the user's settings; L2 takes it if the problem is the access point, the network policy or the device configuration.
3. Shared mailbox permissions are wrong for a whole team: L2, because it needs administrator rights and an understanding of how the groups are set up.
4. A business application fails after a vendor update: L2 gathers logs and tests, and L3 works with the vendor if the cause is in the product.
5. Several sites lose a cloud service for an hour: L1 links the tickets and tells users; L2 and L3 join as technical leads, and the major incident process takes over.
6. A request for a new starter's laptop and accounts: a service request, not a fault, handled by L1 or L2 under the onboarding procedure.

If most escalated tickets end up with the same one or two people, treat it as a sign that L2 is under-resourced, not as proof that those people are doing well.

How do you measure whether the tiers are working?

Four measures tell you most of what you need. None needs special tooling.

1. First-contact resolution: the share of tickets resolved at the first contact, whichever level resolves them. A low figure suggests that L1 lacks scripts, access or training. We cover how to calculate it in our guide to first call resolution.
2. Escalation rate by level: the share of tickets that move up. A very high rate from L1 to L2 means L1 is passing on work it should keep. A very low rate may mean L1 is holding tickets too long.
3. Time to resolve by level: how long tickets spend at each level. Delays often hide at the handover point, not inside a level.
4. Reopen and bounce rate: tickets that return to an earlier level, or are reopened after closing. These show weak handover notes or fixes that did not hold. For related measures, see MTTR, MTBF and MTTA.

Review them monthly and ask the same question each time: what could L1 have fixed if it had a better article, more access or a clearer rule?

What are the common mistakes in tiered support?

1. Escalating too late, because L1 is afraid of "failing". Time limits and risk triggers take the judgement out of it.
2. Escalating too early, because L1 has no access or scripts. This shows up as a high escalation rate for simple faults.
3. Treating L1 as a call centre only. L1 should also own knowledge articles and spot patterns.
4. Starving L3 of context. L3 should hear about patterns and plans, not only emergencies.
5. Making the user repeat themselves. Every repeat question signals a handover gap.
6. Letting one hero absorb everything. If one person is the unofficial L2 and L3, the model has a single point of failure.

Frequently asked questions

What is L1 support?

L1, or level 1 or tier 1 support, is the first line of IT support. It logs tickets, identifies the problem, fixes routine issues from scripts and knowledge articles, and escalates what it cannot solve.

What is the difference between L1, L2 and L3?

The difference is depth. L1 handles routine problems and triage, L2 handles issues that need deeper technical work or wider access, and L3 handles the most complex faults with specialists and vendors.

Is tier 1 the same as level 1?

Yes. Tier 1, level 1, T1, L1 and "first line" all describe the same first layer. Organisations differ in the words they use, so check the definitions in your own documents.

Should a small company have all three levels?

Not necessarily as separate teams. A small IT team may cover several levels. What matters is that the tasks, the handover and the time limits are defined, even if the same person does more than one level.

What can be outsourced?

Any level can. Many companies start by outsourcing L1, then add L2 once the handover works. The contract should state who owns which systems at which level.

How does escalation relate to SLAs?

The SLA sets response and resolution targets per priority, and the escalation rules use those targets as triggers. If a ticket is close to breaching a target, it moves up.

What is the difference between escalating and re-assigning a ticket?

Escalating moves it to a more skilled or senior level because the current level cannot resolve it. Re-assigning moves it sideways to a team that owns the system. A good record keeps the two apart.

Where to go next

Read how priority is set in severity vs priority in IT incidents, then the IT escalation matrix template for contacts and time limits. For the contract wording, see what an SLA means in IT support.

*Sources checked 28 October 2026: Wikipedia, "Technical support" (en.wikipedia.org/wiki/Technical_support); Brocent SLA page (brocent.com/sla).*

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.