The Lost Art of Technical Support

Something strange has happened to technical support.

A user reports that something is not working. L1 confirms that it is not working. L2 reviews the ticket and confirms that L1 correctly established that it is not working. The ticket reaches L3, where somebody reads several paragraphs documenting the continued state of not-working and begins the actual troubleshooting.

We call this tiered support.

It isn't.

It is a forwarding chain with progressively more expensive recipients.

That distinction matters because support tiers were never supposed to be several groups taking turns looking at the same unexplained symptom. They were supposed to represent increasing technical capability.

L1 should make the problem clearer. L2 should make the problem smaller. L3 should determine why it exists and engineer the solution. L4 should correct the underlying product or platform when the problem finally crosses that boundary.

Instead, many organizations have built a system in which uncertainty simply travels upward. The user transfers uncertainty to L1, L1 transfers it to L2, L2 transfers it to L3, and L3 finally begins converting uncertainty into knowledge.

That is not a mature support model.

It is an expensive way of discovering that much of the supposed support chain has quietly become routing.

There is no universal technical-support constitution defining exactly what L1, L2, L3, and L4 must mean. Organizations use the labels differently, and several modern support models reject rigid tiers altogether.

That is fine.

I am not interested in defending the numbering system. I am interested in defending the progression of technical responsibility.

The operating contract I use is simple:

L1 qualifies the problem. What exactly is failing?

L2 isolates the problem. Where is it failing?

L3 engineers the solution. Why is it failing, and what must change?

L4 corrects the underlying product or platform when required. What defect or capability now requires authoritative correction?

Those are capability boundaries, not necessarily organizational teams. An MSP might provide L1 and L2. An internal engineering organization might provide L3. Microsoft, AWS, SAP, ServiceNow, a hardware manufacturer, an internal product team, or some other authoritative owner might effectively provide L4 for a particular dependency.

ServiceNow and other current industry descriptions use somewhat different wording, but the broad progression is familiar: initial support and basic troubleshooting give way to deeper specialist expertise and, eventually, authoritative product or platform support.

The company name is almost irrelevant.

The useful question is:

What value did each capability add before handing the problem to the next one?

That is where support either becomes technical work or reveals itself as ticket movement.

Traditional tiered support is not sacred. In some environments, it is probably the wrong architecture.

Models such as Intelligent Swarming deliberately replace sequential escalation with collaborative problem solving. Rather than marching a ticket through several queues, the person working the issue can retain ownership while pulling in the expertise required to solve it.

That can be a much better model.

But it does not change the underlying obligation.

A swarm that reduces uncertainty is support. A tier that reduces uncertainty is support. A queue transfer that merely relocates uncertainty is routing.

The organizational topology can change.

The diagnostic obligation should not.

Whether the organization uses tiers, swarming, a hybrid model, automation, or something we have not named yet, the problem should become better understood as technical capability is applied to it.

Otherwise we are changing organizational diagrams while preserving the same failure.

L1 does not need to understand kernel internals, reverse-engineer applications, or diagnose every obscure infrastructure defect. That would be absurd, and it would defeat the purpose of specialized support.

But L1 should be capable of structured technical triage.

What failed? Who is affected? When did it begin? Can it be reproduced? Is this one user or many? One machine or many? One location or many? One application or the entire endpoint? Did something change? What exact error appears? Is the system reachable? Is there a known outage? Can the same user reproduce the problem somewhere else? Can another user reproduce it on the affected device?

These are not advanced engineering questions.

They are the beginning of diagnosis.

A good L1 interaction should be able to transform this:

It doesn't work.

into something more useful:

This application fails for this user on this workstation. The same user succeeds from another workstation. Another user succeeds on the affected workstation. General connectivity is healthy. The failure currently appears specific to the interaction between this identity and this endpoint.

L1 did not solve the problem.

That is okay.

The problem is now smaller.

L1 added value.

L2 is where the standard rises considerably because L2 should be able to troubleshoot.

Not engineer every platform. Not understand every application. Not possess every privileged tool. But troubleshoot.

That means taking the qualified problem from L1 and reducing the remaining fault domain. Does the failure follow the user, the endpoint, the application, the network, the location, the identity, a security control, or a backend dependency? What differs between the working and failing states? What changed? What evidence supports the current hypothesis, and what possibilities have already been eliminated?

The deeper mechanics belong in The Lost Discipline of Fault Isolation. Here, the organizational point is simpler:

A technician does not need to know the final answer to add value. They need to reduce the number of possible answers.

If a problem initially could exist in ten different fault domains and L2 reduces that to two, L2 has performed real technical work even when the final correction requires engineering.

If the ticket reaches L3 with all ten possibilities still intact, L2 has not really performed L2 work.

It has performed ticket transportation.

This may be the most damaging misunderstanding in the entire model.

L3 is often treated as the place where difficult tickets go. That definition is almost useless.

L3 should be where support crosses into engineering.

This is where deep platform knowledge, architecture, automation, operating-system engineering, configuration design, security-control engineering, complex interoperability, systemic root-cause analysis, permanent corrective action, and novel defects belong.

The questions should change as the problem moves upward.

L1 asks: What exactly is failing?

L2 asks: Where is it failing?

L3 asks: Why is it failing, and what must change?

Those are different jobs.

An engineer should not routinely receive a ticket and spend the first hour discovering whether the machine is online, whether the user can log in, whether anyone else is affected, whether an error message exists, whether anybody inspected the logs, or whether the dependency being blamed is even involved.

When that happens repeatedly, something important has inverted.

The enterprise is paying its most specialized technical people to perform work that should have happened several layers earlier.

That is labor arbitrage in reverse.

L4 is the authoritative owner capable of changing something the organization below cannot.

That might be an external software vendor, a hardware manufacturer, a cloud provider, a SaaS provider, an internal product-development team, or another engineering organization with authority over the underlying component.

The exact label matters less than the boundary.

By the time an issue reaches that capability, the escalation should resemble a technical case file: the symptom, scope, reproduction conditions, relevant telemetry, known-good comparison, tested hypotheses, eliminated causes, suspected failing component, business impact, and specific help required.

Not:

We think this is a Microsoft issue. Please investigate.

We have spent decades building logs, traces, telemetry, configuration snapshots, and diagnostic tooling.

It would be nice to use some of it before asking another company to start our investigation for us.

Escalation should not mean:

I have reached the limit of what I personally know.

Nobody knows everything. That is precisely why escalation exists.

The better question is:

Have I reduced this problem as far as my capability reasonably allows before asking the next capability to take it?

That is the Escalation Readiness Contract.

A normal escalation should carry eight things:

1. Observed Failure

What actually happened?

1. Scope

Who or what is affected?

1. Reproduction

Can the failure be reproduced, and under what conditions?

1. Evidence

Logs, telemetry, timestamps, identifiers, configuration, relevant screenshots, known-good comparisons, and recent changes.

1. Tests Performed

What meaningful diagnostic actions were actually taken, and what happened?

1. Eliminated Causes

Which plausible explanations no longer require investigation?

1. Remaining Fault Domain

Where does the evidence currently point?

1. Reason the Next Capability Is Required

What expertise, access, authority, ownership, source code, or engineering capability does the receiving group possess that is now necessary?

That contract is intentionally practical.

It is not designed to produce a larger ticket.

It is designed to produce a smaller problem.

Google Cloud's current support guidance asks for many of the same kinds of evidence: expected versus observed behavior, precise timestamps, affected resources, identifiers, diagnostic artifacts, reproduction details, current hypotheses, and the tests being used to evaluate them.

The governing question is:

What do we know now that we did not know when this problem arrived?

If the answer is essentially nothing, the problem was transferred but not meaningfully supported.

The entire support model can be reduced to one rule:

Escalation should transfer a smaller problem than the one originally received.

If uncertainty when the problem arrives is Uin, useful support should produce:

Uout < Uin

L1 reduces uncertainty about the symptom and scope. L2 reduces uncertainty about the fault domain. L3 reduces uncertainty about cause and engineering remediation. L4 resolves the remaining product or platform uncertainty when that boundary is reached.

The equation is conceptual.

The direction is everything.

A ticket can be beautifully documented and diagnostically useless. It can contain screenshots, comments, timestamps, attachments, and enough prose to qualify as a minor novella while preserving exactly the same uncertainty the user reported three days earlier.

Documentation is not automatically diagnosis.

The measure is not how much information was added. The measure is how much uncertainty was removed.

None of this means escalation is bad. Escalation is necessary because no support organization possesses infinite expertise, access, authority, or time.

The failure is escalation without reduction.

A useful escalation says:

Here is the failure. Here is the affected scope. Here is how we reproduced it. Here is the evidence. Here is what we tested. Here is what we eliminated. Here is the remaining suspected fault domain. Here is why your capability is now required.

A poor escalation says:

We couldn't fix it.

One transfers knowledge.

The other transfers uncertainty.

None of this dysfunction requires incompetent people.

In fact, that is what makes it dangerous.

Perfectly capable technicians can work inside a perfectly rational contract and collectively produce a terrible support outcome. Once ticket movement, resolver boundaries, and SLA behavior become the dominant measures of success, escalation without diagnosis stops looking like a failure.

It starts looking like compliance.

Managed services deserve particular attention here, not because managed service providers are uniquely bad at technical support. They are not. Internal organizations create the same dysfunction with impressive consistency.

The particular risk in managed services is that a dysfunctional support model can become contractually efficient.

Imagine a familiar arrangement. A provider owns L1 and L2. The enterprise retains L3 engineering. On paper, that can make perfect sense. Routine support stays with a scalable service layer, while specialized engineering remains with the people who design and govern the technology.

The model can work extremely well.

But only if L1 and L2 are genuinely expected to perform L1 and L2 work.

Trouble begins when the incentives reward something else: call duration, first response, queue age, ticket closure, SLA compliance, resolver-group boundaries, and contractual scope adherence.

None of those measures is inherently wrong. Most organizations need some version of them.

But a system eventually becomes efficient at producing what it rewards.

If ticket movement improves the scorecard faster than diagnosis does, the rational behavior is obvious.

Move the ticket.

Now something peculiar happens.

The service dashboard is green.

Engineering says the support model is failing.

Both statements can be completely true.

The provider may be meeting every metric it was given while L3 receives a steady stream of cases that have barely been investigated.

That is the dangerous part.

The measurements are not necessarily false.

They are measuring the wrong thing.

The provider optimized ticket flow.

The enterprise needed problem reduction.

Those are not the same service.

The Consortium for Service Innovation has made a related argument in its support methodologies, warning against treating transaction activity as a substitute for value creation. The details of any contract will vary, but the operating risk is universal: people optimize the system they are actually measured against.

This distinction disappears constantly in large organizations.

Suppose a provider owns endpoint support but not endpoint engineering.

Reasonable.

That does not mean every endpoint problem outside a documented fix belongs immediately to endpoint engineering.

The provider may not own the final solution. It still owns the diagnosis expected at its capability level.

"We don't own Group Policy."

Correct. Can you establish whether Group Policy is actually implicated?

"We don't own networking."

Correct. Can you establish whether the relevant network path is functioning?

"We don't own the application."

Correct. Can you determine whether the failure follows the application, user, endpoint, location, or backend?

"We don't own identity."

Correct. Can you determine whether authentication succeeded?

A support model in which every dependency boundary terminates diagnostic responsibility is almost guaranteed to produce escalation storms.

Modern enterprise systems are dependency graphs. No support team owns the entire graph.

Somebody still has to reason across it.

That is troubleshooting.

This is one of the more destructive patterns I see in large organizations.

Every individual service tower can be correctly scoped.

Network owns network. Identity owns identity. Endpoint engineering owns endpoints. Application teams own applications. Cloud teams own cloud platforms. Security owns security controls. Vendors own their products.

Everybody owns something.

And somehow nobody owns figuring out which thing is actually broken.

So the problem eventually lands with the people who have the deepest technical capability.

Not because evidence points to their platform.

Because they are the people most capable of navigating ambiguity.

L3 becomes the integration layer for organizational confusion.

At first, this can feel flattering. The engineering team is trusted. They solve difficult problems. People know they can help.

Competence attracts work.

But uncontrolled competence attracts everybody else's unfinished work.

Six months later, those same engineers are spending enormous amounts of time diagnosing systems they do not own because unresolved problems have learned the same migration path.

That is not a compliment anymore.

It is an operating-model failure.

Organizations often behave as though escalation is free.

It isn't.

Every unnecessary escalation consumes more specialized labor, but that direct cost is only the beginning. The larger cost is what engineering is not doing while it reconstructs basic incident context.

Every hour an L3 engineer spends repeating lower-level diagnosis is an hour not spent automating recurring work, improving observability, removing technical debt, increasing resilience, modernizing architecture, engineering permanent fixes, strengthening security, or eliminating the conditions that create future tickets.

The organization therefore pays twice.

First, it pays engineering rates for lower-tier diagnostic work.

Then it loses the engineering work that could have reduced future support demand.

That second cost compounds.

This is why throwing more engineers at an overloaded L3 queue can temporarily improve throughput while making the underlying system worse. The organization hires another expensive person to compensate for a diagnostic failure elsewhere.

Everyone feels busy.

The feedback loop survives.

There is another side effect.

If engineering continually rescues lower support capabilities, those capabilities can actually become weaker.

The ticket moves upward, engineering diagnoses and fixes the problem, the incident closes, and everyone moves on.

But unless the reasoning moves back down, the support system has learned almost nothing.

The next occurrence follows exactly the same path.

Organizations often respond by publishing a knowledge article containing the final fix:

Run this command.

That may be useful.

But the more valuable knowledge is often:

Here is how to determine whether this is actually the problem in the first place.

One teaches a recipe.

The other transfers diagnostic capability.

Knowledge-Centered Service formalizes a similar idea by treating knowledge capture and reuse as part of the resolution workflow rather than an administrative activity that happens after the interesting work is over.

A mature knowledge system should capture both the fix and the reasoning that established when the fix applies.

Otherwise engineering becomes not only the place where problems are solved, but also the place where organizational learning goes to die.

This is not an argument for building a fortress around engineering.

L3 should help. It should teach, improve observability, create diagnostic tools, improve runbooks, automate repetitive checks, build safer remediation, and accept ownership when the evidence points to an engineering problem.

The relationship between L2 and L3 should be reciprocal.

L2 owes L3 a narrowed problem.

L3 owes L2 improved capability.

When L3 discovers something reusable, it should move downward: a query, a telemetry view, a script, a decision tree, a known-good baseline, a runbook improvement, an automated remediation, or simply an explanation of how the problem was isolated.

That creates a healthy feedback loop:

better diagnosis → better escalation → faster engineering → reusable knowledge and tooling → stronger support capability → fewer unnecessary escalations

The unhealthy loop is equally powerful:

weak diagnosis → excessive escalation → overloaded engineering → less automation and knowledge transfer → weaker support → more escalation

Organizations are always building one of those loops.

Sometimes the dashboard remains green through the entire process.

A major outage is an obvious exception to sequential escalation.

When a critical service is failing, relevant engineering teams should engage immediately and work in parallel. Nobody should wait while L1 completes a perfect diagnostic package before raising the alarm.

But urgency changes the sequence of engagement, not the underlying discipline.

Urgency suspends sequential escalation. It does not suspend technical reasoning.

The deeper mechanics belong in The Lost Discipline of Fault Isolation. For the support model, the important point is that emergency engagement is an exception to sequential tier progression, not an excuse to abandon evidence, hypotheses, controlled changes, or technical ownership.

Twenty people asking questions simultaneously is still not a diagnostic method.

Traditional service metrics still matter. Response time matters. Resolution time matters. Availability matters. Customer impact matters. Service commitments matter.

But those measures do not tell you whether the technical organization is becoming better at diagnosis.

I would also want to know:

Escalation acceptance. Can the receiving capability begin meaningful work immediately?

Diagnostic duplication. How often does L3 repeat checks that were already performed, or reasonably should have been?

Resolver bounce. How many organizational transfers occur before the fault domain becomes clear?

Engineering displacement. How much specialist engineering capacity is being spent on basic qualification and isolation?

Reproduction quality. Does the escalation contain a reproducible case or a clear explanation of why reproduction is impossible?

Evidence preservation. Were logs, timestamps, identifiers, and relevant state captured while the failure still existed?

Fault-domain reduction. Did the support interaction actually reduce the plausible search space?

Knowledge conversion. When a new problem was solved, did the organization turn the diagnosis into reusable capability?

These are not sacred industry metrics.

That is not the point.

The point is to measure whether the support system is learning, not merely whether tickets are moving.

It would be easy to read all of this and conclude that traditional tiering is the problem.

It isn't.

A badly operated tiered model becomes ticket ping-pong. A badly operated swarming model becomes twenty people speculating simultaneously.

Neither architecture manufactures diagnostic discipline.

The deeper questions are more important.

Who owns the problem? Who owns the reasoning? How quickly can relevant expertise be engaged? Does knowledge remain with the people who encountered the issue? Does each interaction leave the organization more capable?

And above everything else:

Is uncertainty actually decreasing?

Use tiers. Use swarming. Use a hybrid. Automate known cases entirely. Use AI to connect incidents with expertise and previous evidence.

The topology can evolve.

The objective should remain stable.

Convert uncertainty into understanding as efficiently as possible.

By this point the pattern should be clear. What looks like a technician problem at the bottom of the organization may actually be an operating-model problem designed several layers above them.

That matters because the easiest response is also the least useful one: tell the support team to try harder.

If the organization does not change the expectations, tools, access, training, measures, and boundaries surrounding the work, individual improvement will eventually be absorbed by the system around it.

Leadership owns this failure whether support is provided by employees, contractors, or managed service providers.

Execution can be outsourced.

Accountability for the operating model cannot.

If L3 is drowning in poorly qualified escalations while the provider dashboard remains green, leadership has a measurement problem. If engineering repeatedly has to rediscover information that L1 or L2 could reasonably have collected, leadership has a capability problem. If tickets bounce between resolver groups because nobody is accountable for cross-domain diagnosis, leadership has an operating-model problem. If teams are rewarded for movement rather than understanding, leadership has an incentive problem.

Those are management failures before they are technician failures.

The answer cannot simply be, "Tell L1 to do better."

Does L1 have the training, access, tools, knowledge, time, authority, contractual expectation, and performance incentives required to do better?

Does L2?

People operate inside systems.

Fix the people while preserving the system, and the system will usually win.

This is not really an article about L1.

It is not really an article about MSPs.

It is not even primarily about protecting L3.

It is about whether technical support remains a technical discipline.

If L1 merely records symptoms, ask why. If L2 routinely escalates problems without narrowing them, ask why. If L3 spends enormous amounts of time repeating basic troubleshooting, measure it. If external providers routinely ask for evidence your own escalation chain could reasonably have collected, examine the chain.

And if every service metric is green while engineering insists the support system is failing, believe both signals long enough to understand the contradiction.

You may discover that the organization is performing exactly as designed.

It is simply designed to move work rather than reduce uncertainty.

Technical support should do something more valuable than move a problem toward somebody with a more expensive job title. Each capability should leave the problem better understood. Each handoff should carry evidence. Each escalation should reduce the remaining search space. And when a problem finally reaches deep engineering, there should be an intelligible technical reason why deep engineering is required.

The practitioner side of that responsibility is fault isolation.

The organizational side is the support model.

The practitioner must learn to narrow the problem.

The organization must build a system that expects the problem to be narrowed.

Otherwise, call the operating model what it really is:

One level of technical support surrounded by three levels of routing.

The companion essay, The Lost Discipline of Fault Isolation, covers the technical discipline underneath this operating model: how to define the symptom, establish boundaries, form testable hypotheses, eliminate possibilities, and progressively turn uncertainty into knowledge.

A support organization cannot demand good diagnosis if the people inside it have forgotten how diagnosis works.