L1, L2 and L3 Support Explained: What Each Level Does and What to Outsource

If you have ever read a support contract, you have probably seen the terms L1, L2 and L3. They are used everywhere, but they are not always explained, and different vendors sometimes use them to mean slightly different things. That can make it hard to compare proposals or decide what to keep in-house.

This article explains each support level in plain English, with examples, shows how tickets move between levels and offers a practical way to decide which levels to outsource.

What L1, L2 and L3 support mean

Support levels describe how deep the knowledge and access needed to resolve an issue are. Each level handles problems the previous level cannot.

L1 support: first contact

L1 is the first point of contact for users. The team logs the issue, gathers information, resolves common problems using known procedures and passes anything more complex to the next level.

Typical L1 tasks include:

• Password resets and account unlocks
• Answering how to questions about using the application
• Checking whether a reported problem is a known issue
• Collecting details, screenshots and steps to reproduce a problem
• Routing tickets to the right team

L1 staff need good communication skills, clear procedures and access to a knowledge base. They do not usually change the system itself.

L2 support: deeper investigation

L2 handles issues that need technical investigation. The team has a deeper understanding of the application, its configuration and its data, and can diagnose problems that do not have a scripted answer.

Typical L2 tasks include:

• Investigating errors using logs and monitoring tools
• Correcting data problems and configuration issues
• Reproducing reported bugs and confirming the cause
• Applying known workarounds
• Writing up confirmed defects for L3 with clear evidence

L2 staff need technical skills and controlled access to systems, but usually do not change the code.

L3 support: code and architecture

L3 is the expert level. The team can change the application's code, fix defects at the root, resolve complex integration problems and improve the architecture to prevent repeat incidents.

Typical L3 tasks include:

• Fixing bugs in the application code
• Resolving performance problems
• Investigating complex failures across several systems
• Releasing patches and hotfixes
• Removing the root cause of recurring incidents

L3 staff are usually experienced engineers with deep knowledge of the codebase.

Picture a subscriber who cannot sign in to a telecom self service portal. L1 verifies the subscriber's identity using the approved procedure, checks for an account lock and guides them through a password reset. The reset succeeds, but the portal still rejects the login. L2 reviews the authentication logs and reproduces the failure when an account has recently changed subscription type. The evidence points to a recurring defect rather than a forgotten password. L3 corrects the code that maps the subscriber's account permissions, tests the affected journey and releases the fix through the agreed change process. L1 then confirms access with the subscriber.

A simple comparison

Some organisations also refer to L0, meaning self service such as help articles, and L4, meaning third party vendors such as a software provider whose product you use. The core model, though, is L1 to L3.

How tickets move between levels

A ticket normally starts at L1. If L1 cannot resolve it using known procedures, it is escalated to L2 with all the information gathered so far. If L2 confirms a defect in the code, or the problem needs a change to the system, it moves to L3.

Good escalation depends on a few things.

• Clear criteria. Everyone should know when a ticket must move up, so problems are neither stuck at a lower level nor escalated too early.
• Complete handoffs. Each level passes on what it has found, so the next level does not start from scratch.
• Feedback loops. When L3 fixes a problem, the solution is documented so L1 and L2 can handle similar issues faster next time.
• One owner per ticket. Someone remains accountable for keeping the user informed, whichever level is working on it.

When escalation works well, users get faster answers and the expensive L3 team spends its time on the problems only they can solve. When it works badly, tickets bounce between teams and nobody owns the result. This is one of the first things we review when we take on application support.

If you are changing providers, agree these handoffs before cutover. Our guide to taking over application support from another vendor without disruption explains how to transfer access, knowledge and escalation ownership safely.

What companies typically keep in-house and what they outsource

There is no single right answer, but common patterns exist.

Keep L1 in-house when

• Your users need someone who knows your business, people and processes closely
• Support is mainly about how to use internal workflows
• You already have a service desk with spare capacity

Outsource L1 when

• You need coverage outside your working hours
• Volumes vary a lot and are hard to staff for
• Users are spread across several time zones

Outsource L2 and L3 when

• The application was built by a vendor who is no longer involved
• You do not have engineers with the right skills in-house
• Your internal team should focus on new development rather than support
• You need guaranteed coverage and service levels rather than best effort

Many organisations keep a small internal team close to the business and outsource L2 and L3 to a partner with the depth to fix problems properly. Others outsource all three levels to one partner, which simplifies accountability.

Consider a fintech platform whose service desk and application engineers belong to separate suppliers. A customer reports that a payment remains pending. L1 collects the transaction reference and symptoms, but the ticket reaches L2 without the relevant timestamps or integration response. L2 investigates the payment callback and finds that the application is not acknowledging it correctly. The engineering supplier initially treats the report as a configuration issue, leaving ownership unclear. A shared escalation checklist, controlled access to diagnostic evidence and a named ticket owner allow L2 to demonstrate the defect to L3. Engineering can then fix and test the callback handler while the service desk keeps the customer informed.

How to decide

Work through these questions.

• Where does your knowledge sit? If nobody in-house understands the code, L3 effectively has to be outsourced.
• What hours do you need covered? If you need cover beyond your working day, building that internally can be expensive.
• How many vendors do you want to manage? Splitting levels between suppliers creates handoffs and gaps in accountability.
• What service levels do you need? Define response and resolution expectations first, then choose the model that can meet them.
• What should your internal team be doing? Time spent firefighting is time not spent improving the business.

Whatever you choose, make sure there is one party clearly accountable for the overall service, not just for individual tickets.

To see how levels, coverage and service levels fit together in practice, visit our application support and managed services page.

How TechBridge helps

TechBridge provides contract based L1, L2 and L3 application support, either for all levels or alongside your internal team. We agree escalation criteria, service levels and coverage hours in each contract, from business hours to full 24/7. Our engineers fix root causes, not just symptoms, and feed solutions back into documentation so the service improves over time. Delivery may include vetted partners, but TechBridge remains accountable for every service level.