L1, L2 and L3 Support

Tiering is a design decision, not a hierarchy

Support tiers exist to put the right level of skill against the right level of problem, so that expensive specialists are not resetting passwords and inexperienced agents are not guessing at architecture.

The tiers themselves are easy to describe and hard to place. Almost every struggling technical support operation has tiers; what it lacks is well-drawn boundaries between them. That boundary is the whole design, and it is what we agree with you before anything else.

What each tier does

Level 1 is first contact. It owns the customer relationship for the duration of the case: gathering the symptom, establishing the environment, checking the known-issue register, applying documented resolutions and workarounds, and escalating with a complete package when the answer is not documented. A good L1 resolves the majority of contacts because the majority of contacts are recognised rather than novel.

Level 2 handles what is not documented. Deeper diagnosis, log analysis, configuration investigation, reproduction of reported faults, and resolution of problems that require product knowledge beyond the runbook. L2 also owns the known-issue register - when they solve something new, it becomes something L1 can recognise next time.

Level 3 is specialist or engineering-adjacent: root-cause analysis on genuine defects, complex integration and environment problems, and the interface into your engineering or infrastructure teams. L3 is deliberately small, and its throughput is protected by the two tiers in front of it.

The two ways tiering fails

Both are common and each has a distinct signature in the numbers.

The switchboard L1. The first tier escalates almost everything, because its remit is too narrow, its knowledge base is thin, or it has no authority to act. Signature: high escalation rate, low L1 resolution, and an L2 queue full of things that were straightforward. The customer explains the problem twice and waits longer for an answer L1 could have given. This is the more common failure, and it usually comes from over-caution during design.

The bottleneck L2. The first tier escalates too little - often because escalation is treated as failure - so cases sit at L1 being worked by people without the depth to resolve them. Signature: long L1 resolution times, high reopen rate, and customers escalating through complaint channels instead of support ones. Fixes that do not hold are the tell.

Both are visible in reporting within weeks if you are looking at the right numbers, which is why we report escalation rate and reopen rate together rather than separately.

Drawing the boundary

We set the L1/L2 line by contact type rather than by difficulty, because "difficult" is not a category an agent can apply consistently at speed. For each significant contact reason we agree explicitly: does L1 resolve this, progress it, or log and escalate it?

Two rules make that hold in practice. First, escalation is not failure - an L1 escalating correctly to protect resolution quality has done their job, and the scorecard reflects that in both directions, penalising a case escalated that L1 should have resolved and a case held that should have moved. Second, the boundary is revisited. As the knowledge base grows, work should move down a tier. A boundary set at launch and never reviewed leaves L2 permanently doing what L1 could now handle.

Handoff quality

A tier model is only as good as what crosses between tiers. An escalation that arrives as a forwarded thread makes L2 start from the beginning, which removes most of the value tiering was supposed to create.

We define the escalation package per contact type: symptom, environment, version and configuration, steps already taken and their results, known-issue checks performed, and reproduction status. It is scored on the scorecard as its own criterion. Handoffs go to a named owner rather than to a queue, and the customer keeps a single point of contact so they are not managing your internal structure on your behalf.

Who owns the customer

Worth deciding explicitly. In most arrangements L1 retains ownership through escalation - they update the customer, chase the tier holding it, and close the loop. The alternative, where ownership transfers with the case, is defensible but requires L2 and L3 to be resourced for customer communication, which they usually are not.

We recommend L1 ownership by default. The customer gets one contact who knows their case, and the specialist tiers stay focused on solving rather than reporting.

Staffing the shape

Tier ratios follow from your contact mix rather than a formula, but the shape is consistent: L1 is the largest tier by a wide margin, L2 is a fraction of it, and L3 is small. If your L2 is nearly as large as your L1, the boundary is almost certainly in the wrong place.

We hire differently per tier. L1 is hired for communication, composure and procedural discipline; L2 for diagnostic reasoning and depth; L3 for specialist knowledge. Internal progression from L1 to L2 works well and we plan for it - an L2 who has done L1 writes better runbooks, because they remember what was unclear.

Coverage, systems and reporting

Tiers do not need identical coverage. A common pattern is L1 across extended or continuous hours with L2 on business hours plus an on-call arrangement, and L3 on business hours only. Coverage is built from shift units - see 24/7 support where continuous L1 is needed.

Agents work in your help desk and issue tracker so the case record is continuous across tiers - see technology. Reporting covers resolution rate and time per tier, escalation rate and accuracy, reopen rate, escalation package completeness, and backlog by tier. Per-tier reporting is the point: a blended figure cannot tell you whether your boundary is wrong. See the measures we report. Figures published elsewhere on this site are historical or representative and campaign-dependent.

Getting started, and what it costs

Priced per dedicated agent per month with a five-agent minimum, with rates differing by tier because the recruitment profiles differ - published rates and what moves them.

Bring your contact volume by reason, current escalation rate, reopen rate, and resolution time split by tier if you have it. Those four usually show immediately which of the two failure modes you have. Related: technical support outsourcing, IT help desk, software support. Talk to us.