Pull every escalation from first line to second line for the last quarter. Classify each one into three buckets. The exercise takes an afternoon, requires no new tooling, and routinely reshapes an entire support budget conversation.
The three buckets
Genuine escalations. The issue required access, permission or expertise that first line does not have and should not have. This is the system working as designed, and the only bucket that justifies headcount at the higher tier.
Access escalations. The agent knew the answer and could not execute it — no permission to issue the credit, reset the configuration, or push the change. The knowledge was present; the authority was not.
Knowledge escalations. The agent had the authority and not the information. Better documentation, better tooling or a working search experience would have closed it at first contact.
In a typical operation the second and third buckets together account for a substantial share of the total. Every one of them is a contact handled twice, a customer sitting through a handoff, and an expensive engineer doing work a properly equipped first line could have finished. Neither bucket is fixed by hiring. Run the classification before scoping offshore technical support services, because it tells you which tier you are actually short of rather than which one feels busiest.
Why the buckets fill up
Because most tiering models define tiers by seniority rather than by capability, and those produce very different operations.
A better definition states, for each tier, what it may decide, what it can access, and what it must escalate. First line then handles anything with a documented resolution path, holding enough authority to execute it — account changes, configuration resets, credits within a ceiling, standard troubleshooting through a defined sequence. The constraint is that the path exists and is documented, not that the issue is easy. Second line handles anything requiring diagnosis rather than procedure: reproducing a fault, reading logs, correlating across systems, judging whether behavior is a defect or a misconfiguration. Third line handles anything requiring code, infrastructure change, or a decision about the product itself.
Written this way, tiers stop being a hierarchy of people and become a description of work. An experienced first-line agent with good tooling resolves issues a poorly-equipped second line would escalate — which is the right result and unreachable under a seniority-based model.
The offshore version of the same problem
First and second line both transfer well, and the binding constraint is access rather than geography.
A second-line function that cannot read production logs, cannot reproduce a fault in a test environment, and cannot see deployment history is not doing second-line work. It is doing first-line work with a longer queue in front of it. This is the most common failure in offshore technical support and it is an access-provisioning decision made during implementation, not a capability gap. Give the offshore tier the same tooling the onshore one had; where security or regulatory constraints genuinely prevent that, say so and reclassify the tier rather than pretending.
Then there is the handoff itself, which is where support actually fails in the customer’s experience. A customer who explains their problem twice has had a bad experience regardless of how it eventually resolved. Specify what the escalating agent must record — what was attempted and ruled out, the customer’s environment, the actual question as distinct from the reported symptom — and enforce it in quality review. Count the escalations arriving without it. That rate is a direct measure of whether your handoff standard is real or aspirational.
What automation did to the shape
The tiering model assumed a wide base, and the base is narrowing. Password resets, status questions, known-issue lookups and standard configuration changes increasingly resolve without a person. Reporting on the senior-skewing shift in offshore support services describes the resulting composition change: fewer people, harder work, more experience required per head.
Two consequences follow. The pyramid is becoming a diamond, as first line shrinks and what remains in it looks a great deal like what used to be second line. And the career path that fed second line has thinned, because first line was where people learned the product well enough to become useful higher up. Automate most of it and the apprenticeship disappears while the requirement stays — which is why operations that have noticed are rebuilding it deliberately through supervised work on constructed cases and rotation through automated-output review.
Four numbers to watch afterward
First-contact resolution is the standard measure and tiering distorts it, because an organization can improve the figure by escalating faster.
Track instead: resolution at journey level, counting one issue across every contact and tier it touched; escalation rate by bucket, using the three-way classification above so the fixable ones stay visible; reopen rate within a defined window, which catches the closure that was not a resolution; and, for any operation with an automated layer, the proportion of system-to-human escalations that open with the customer restating what the system already captured. That last number is almost never reported and almost always higher than anyone expects.
Run the classification first, though. Most of what gets escalated in a typical support organization is escalated for want of a permission or a document rather than for want of expertise, and you cannot size a team sensibly until you know which.