L1, L2 and L3 are tiers of application support. L1 is the first line that logs issues and fixes common problems using scripts and guides. L2 handles deeper technical analysis and configuration fixes. L3 involves developers who change code or architecture for root causes. Issues move up a tier only when the lower one cannot resolve them.
- Tiers keep simple issues cheap and fast while reserving experts for hard problems.
- A clear escalation path and defined response times prevent issues from bouncing around.
- Good documentation and a knowledge base let L1 resolve more without escalation.
- Agree what is covered, who is reachable when, and how issues are logged.
What do L1, L2 and L3 mean?
The tiers describe depth of expertise and where in the chain a problem gets handled. L1, sometimes called the service desk, receives the user's report, records it and resolves the straightforward cases. L2 consists of more technical engineers who investigate and fix issues L1 cannot. L3 is the specialist or development level, which can change the code or design.
The point of tiers is efficiency. Most issues are routine: a forgotten password, a missing permission, a report that needs a refresh. Having expensive developers handle those is wasteful, and having a junior desk struggle with a code defect wastes the user's time. Tiering routes each problem to the right level.
What does each tier typically handle?
L1 works from scripts and a knowledge base. It handles logins, access requests, basic how-to questions, known errors with documented fixes, and it gathers the details a deeper engineer will need: screenshots, steps, time and affected users. Good L1 also sets expectations with the user and keeps them updated.
L2 diagnoses issues using logs and system access, adjusts configurations, fixes data problems, manages integrations and performs routine maintenance. L3 handles defects that need code changes, performance tuning, design changes and vendor-level problems. Some organisations add an L0 self-service layer, such as a chatbot or help centre, ahead of L1.
- L1: logging, access, how-to help, known fixes, collecting details
- L2: log analysis, configuration, data corrections, integration problems
- L3: code fixes, architecture, performance, vendor escalations
- L0 (optional): self-service help pages or a chatbot
How does escalation work?
An issue is escalated when the current tier cannot resolve it within the agreed time or lacks the access or skill to do so. A proper escalation hands over everything: what was tried, evidence and the business impact. Without that, the next tier begins from zero and the user repeats the story.
Define severity levels. A system down for everyone is more urgent than a cosmetic issue for one user, and each level should carry a response time and a target resolution time. Escalation also works downward: when L3 finds the cause, it should leave a note so that L1 can handle the same case next time.
What should an agreement cover?
A support agreement should state which applications and environments are covered, the hours of support, the channels such as phone, email, WhatsApp or a ticket portal, and the severity definitions with response and resolution targets. It should clarify what is a support request versus a new feature, since enhancements are normally handled separately.
Also agree on reporting. Monthly summaries of tickets by category, time to resolve and repeated issues show where training or fixes are needed. Ask who holds access to your systems and data, how credentials are handled and what happens at the end of the contract.
- Scope: applications, users and environments covered
- Hours and channels of support
- Severity levels with response and resolution targets
- Treatment of enhancements versus fixes
- Reporting, access and handover terms
How do you decide what to keep in-house?
Small businesses often keep L1 internally, perhaps a trained staff member who knows the users, and buy L2 and L3 from the vendor or a partner. Others outsource all three for round-the-clock cover. The right split depends on how critical the system is, how much knowledge your staff have and how quickly you need responses.
Avoid single points of failure. If one internal person alone understands the system, their leave becomes a risk. Documentation, shared access and runbooks reduce that dependence regardless of who provides each tier.
How can you reduce the number of tickets over time?
Treat repeated tickets as signals. If the same question comes up weekly, improve the screen, add a help tip or write an article. If a data issue keeps recurring, fix its cause at L3 rather than correcting it each month. Track the top five ticket categories and aim to shrink them.
A Plus Solution provides sustenance and application support, and the healthiest arrangement is one where reports show falling repeat issues. Support that only reacts forever is a cost; support that feeds improvements back into the product is an investment.
Frequently asked questions
Do we need all three tiers?
Not necessarily. Smaller systems may combine tiers in one team. What matters is that each type of problem has a clear owner and path.
What is the difference between support and maintenance?
Support responds to user issues and incidents. Maintenance includes planned work such as updates, patching and performance upkeep. Many agreements bundle both.
What response time should we expect?
It depends on severity and the agreement. Critical issues normally have the fastest targets. Define them in writing rather than assuming.
Who should have access to our production data?
Only the people who need it, with logged access and clear confidentiality terms. Review access when staff or vendors change.
Need help with this? Ask us a question about it — we reply within one working day.
