What to Outsource at L1, L2 and L3 — and What to Keep In-House
Most companies don’t decide their L1/L2/L3 split — they inherit it. Someone outsourced the help desk three years ago because password resets were eating an engineer’s week, L2 grew organically around whoever knew the most about the internal systems, and L3 is whichever senior person hasn’t quit yet. Nobody sat down and drew the line on purpose. That’s usually fine, until the ticket volume triples or the person who is L3 for four different systems finally leaves.
This article is about drawing that line on purpose — what almost always belongs at L1, where L2 gets genuinely contentious, why L3 rarely moves to a partner, and what actually changes the answer for your specific setup, whether you handle it through an outsourced IT service desk or keep the whole structure in-house.
Key Insights
- Most companies outsource L1 and keep L3 — the real decision sits at L2. That middle tier is where application knowledge, production access and escalation ownership get genuinely contentious, and where the split most often gets drawn wrong.
- The average first-contact resolution rate for IT support organizations worldwide is about 84%, according to MetricNet’s benchmarking data — with top performers exceeding 90%. A weak L1 doesn’t just create slow tickets; it silently inflates everything above it.
- 91% of mid-size and large enterprises report that a single hour of downtime costs more than $300,000, per ITIC’s 2024 Hourly Cost of Downtime Report — which is exactly why companies that outsource everything else keep L3 in-house.
- The split that works at 200 users often breaks at 2,000 — not because the tiers change definition, but because ticket volume and the number of bespoke applications both grow the L2 workload faster than most companies plan for.
- Who owns the escalation clock matters more than who owns the ticket. A clear SLA-breach trigger between L1 and L2 prevents tickets from quietly sitting in a queue nobody is accountable for.
- Outsourcing L1 first, then adding L2 capacity once volume justifies it, is the most common sequencing — companies that outsource L2 before L1 usually did it because a single person was both, and burned out.
What Split Do Most Companies Start With — and Why Does It Stop Working at Scale?
Most companies start with a simple two-tier reality even if they call it three: a generalist handles everything that comes in, and a senior engineer gets pulled in when something is genuinely hard. That works fine under a few hundred users and a handful of applications, because one or two people can hold the whole system in their heads.
It stops working once ticket volume and application count both grow, because the informal L2 role — usually one specific person — becomes a bottleneck and a single point of failure at the same time. The table below is the reference most companies are missing when they try to formalize the split.
| Tier | Typical ticket | Knowledge required | Who usually owns it | What breaks if you outsource it badly |
|---|---|---|---|---|
| L1 | Password reset, account access, standard software request, basic how-to | Process knowledge, ticketing tool fluency, a good knowledge base | Nearly always outsourced or a shared service | Slow response times, poor first impressions — rarely a business risk |
| L2 | Application errors, integration issues, escalations that need investigation | Deep familiarity with specific internal systems and their quirks | Split — some outsourced, some kept in-house, and this is where it goes wrong | Tickets bounce between teams; nobody owns the fix; MTTR quietly doubles |
| L3 | Root-cause analysis, architecture-level fixes, vendor escalations, security-sensitive changes | System architecture knowledge, production access, institutional history | Almost always in-house, or the platform vendor’s own specialists | Production incidents stall; nobody with authority to make the call |
What Almost Always Belongs at L1?
L1 almost always covers password resets, account provisioning, standard software requests, basic connectivity issues and anything answerable from a well-maintained knowledge base — work that’s high-volume, low-risk, and doesn’t require institutional knowledge of your specific systems. This is exactly why it’s the tier outsourced most often and most successfully: the knowledge required is process knowledge, not company-specific history.
The quality bar still matters, though. MetricNet’s benchmarking data puts the average first-contact resolution rate for IT support organizations worldwide at about 84%, with the strongest performers resolving well over 90% of incidents without escalation. An L1 team stuck well below that average isn’t a minor inconvenience — every ticket that should have closed at L1 but didn’t becomes unnecessary load on L2, which is a much more expensive place for that work to land.
Where Does L2 Get Contentious?
L2 gets contentious over three things: how much application-specific knowledge the tier requires, whether the team has production access, and who owns the clock once a ticket needs to escalate. None of these are outsourcing questions on their own — they’re organizational design questions that outsourcing just makes explicit.
Application knowledge is the first fault line. A support engineer troubleshooting a heavily customized ERP or a bespoke internal tool needs context that takes months to build, which makes L2 for that specific system a poor candidate for a generic outsourced bench — but a strong candidate for a dedicated, embedded team that stays on the account long enough to build that context. Production access is the second: L2 engineers who can restart services, push config changes or touch customer data need a level of trust and auditability that has to be designed into the contract, not assumed. And the escalation clock — who is accountable for noticing an SLA breach and pushing a ticket to L3 — is the detail that determines whether “we have an L1/L2/L3 structure” actually functions under pressure or just looks good in a diagram. The distinction the ITSM field draws here, per the Consortium for Service Innovation’s definition of escalation, is between functional escalation — handing a ticket to someone with deeper technical skill — and hierarchical escalation, which pulls in more senior authority rather than more technical depth. Most L1-to-L2 handoffs are functional; most breaches that reach leadership are hierarchical, and conflating the two is a common source of confusion in poorly designed SLAs.
Why Is L3 Rarely Outsourced — and When Is It?
L3 is rarely outsourced because it requires the kind of institutional and architectural knowledge that’s expensive to transfer and risky to depend on externally — the person doing root-cause analysis on a production incident usually needs to understand not just the system, but the history of decisions that shaped it. Given that ITIC’s 2024 Hourly Cost of Downtime Report found that 91% of mid-size and large enterprises report downtime costing more than $300,000 an hour, it’s a rational default to keep the tier closest to production incidents in-house.
The exceptions are specific and consistent: L3 gets outsourced when the “vendor” and the “outsourcer” are effectively the same expertise — a certified platform specialist team for SAP, ServiceNow or a specific ERP, where the outsourcing partner’s engineers genuinely have deeper platform knowledge than most companies could build internally. It also gets outsourced, temporarily, when a company is bootstrapping a new IT function and has no internal L3 yet — with an explicit plan to build that capability in-house as the function matures, not as a permanent arrangement. This is one of the reasons nearshoring in Poland has grown well beyond L1 ticket volume alone: platform-certified specialists staffed through nearshore software development Poland providers increasingly cover this narrow L3 exception too, not just the routine tiers underneath it.
Ready to Find Your L1/L2 Split?
Tell us your ticket volume and application landscape — we’ll come back with a realistic tier structure, not a generic pitch.
What Changes the Answer?
Three factors change where the line sits: the number of users, the number of applications in active use, and how much of your environment is bespoke versus off-the-shelf. A 150-person company running mostly SaaS tools can often outsource L1 and most of L2, because there’s little proprietary knowledge to protect. A 3,000-person company running a dozen customized internal systems needs a much narrower L1 scope and a deliberately staffed L2, because the knowledge concentration risk is far higher.
- User count changes ticket volume, not tier definitions. More users means L1 needs to scale first — usually the easiest tier to scale, since it’s the most standardized.
- Application count changes L2 workload disproportionately. Each additional bespoke application adds a knowledge silo that either needs its own L2 specialist or a documented handoff process — there’s no shortcut around this.
- How much is bespoke changes what can leave the building. Standard, well-documented systems transfer to an outsourced team relatively cleanly. Deeply customized, undocumented systems don’t — no matter how good the outsourcing partner is, they can’t shortcut institutional knowledge that was never written down.
How Long Does It Take to Stand Up an Outsourced L1/L2 Team?
Most companies have an outsourced L1 team live within a few weeks of signing, with L2 capacity typically phased in once the L1 knowledge base and escalation process are proven to work — not bundled in from day one.
From Itelence delivery experience: on a flagship 3,500-user engagement for a US-headquartered international manufacturer, the client’s L1 ticket resolution rate doubled after Itelence took over the service desk and implemented a structured knowledge base — before any L2 scope was added. Across recent service desk engagements, Itelence has maintained 95%+ SLA adherence and a CSAT of 96–98%.
“The companies that get this wrong almost always outsource too much at once. Give a new L1 team six weeks to prove first-contact resolution before you hand them anything that touches production. The ones who skip that step end up blaming the outsourcing model for a sequencing mistake.”
— Szymon Stadnik, CEO, ITELENCEHow Is the Engagement Governed Once It’s Live?
An outsourced L1/L2 team is governed through SLAs on response and resolution time by ticket priority, a clearly defined escalation trigger between tiers, and regular KPI reporting — first-contact resolution, SLA adherence, ticket volume by tier and CSAT — reviewed against agreed targets rather than left informal. This is where the nearshore IT services Poland model tends to work well specifically: the team operates inside the client’s own ticketing platform, following the client’s own escalation policy, rather than running a parallel process that has to be reconciled after the fact. The same governance discipline underpins IT nearshoring Poland generally — daily standups, shared tooling, and a named delivery lead, the same structure that makes nearshore development Poland work for service desk teams as much as for engineering ones.
The governance detail companies skip most often is naming, explicitly, who owns the escalation clock — not which tier handles which ticket type, but who is accountable for noticing when an SLA is about to breach and pushing the ticket forward. Without that ownership, tickets drift between tiers even when the tier definitions themselves are correct.
When Should You Keep Everything In-House?
Keeping everything in-house makes sense for a small company with a handful of highly bespoke systems and low ticket volume, where the overhead of managing an external partner exceeds the benefit of offloading routine work — there isn’t enough L1 volume to make outsourcing meaningfully cheaper, and nearly everything that comes in needs institutional knowledge anyway. It also makes sense, at least temporarily, for a company mid-way through a major system migration, where the support knowledge itself is still being written and handing any of it externally would mean training a partner on something that’s about to change.
The wrong reason to keep everything in-house is inertia — “we’ve always done it this way” isn’t a data point. If your engineers are still resetting passwords and your L2 person is one resignation letter away from a crisis, the split described above is worth drawing on purpose, even if the honest answer ends up being to outsource less than you initially assumed.
Get the Right L1/L2/L3 Structure — Not a Generic Bundle
Itelence builds outsourced service desk teams that fit the split you actually need, not a one-size-fits-all package.
Frequently Asked Questions
Questions buyers ask most often once they’ve decided to formalize their L1/L2/L3 split.