Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 9 of Season 1. Stay with it.
The phrase of the year in service management is “the end of tier 1.”
Vendors now promise 55 to 85% of requests resolved with no human involved. One large platform vendor has said publicly that it intends to automate its own first-line roles. Conference agendas have moved from “should L1 go” to “how fast.”
I think the tier is going too. I also think most of the people saying so have the mechanism wrong, and the mechanism is the whole difference between an operating model that works and a headcount cut with a press release.
My claim: L1 and L2 converge into one exception layer because the boundary between them was always a context boundary, not a skill boundary. When context travels with the work, the reason to have two tiers dissolves. The people do not. They re-sort into two roles, and the order in which you do it decides whether you get convergence or collapse.
Converge after coverage, not before.
The Tier Boundary Was Where the Context Ran Out
Ask what an escalation from L1 to L2 actually means and strip the process language away. It means one of three things. I do not have the information. I do not have the access. I do not have the authority.
None of those is a statement about skill. They are statements about context and permission. L2 was the place where the device history, the change record, the dependency map, and the elevated credentials lived, and the ticket traveled there because the context could not travel to the ticket.
Work only shifts left as far as context does, and that is exactly why so many shift-left programs stalled. They moved the work to L1 and left the context at L2, then read the resulting escalation rate as an L1 skills problem and bought training.
Change the architecture, and the escalation reasons start to vanish one by one. The end user has become the first resolver with the context underneath. The agent on the queue holds the change record and the dependency map. Governed execution carries the access and the low-risk authority. What reaches a human from any of those paths is the same thing: an exception the system declared it could not carry.
Once L1 and L2 are both receiving exceptions, they are no longer two tiers. They are one layer with two kinds of work in it.
Two Roles, Not Two Tiers
Here is the shape I expect that layer to take, stated as a destination rather than a report.
The first role is human-channel work. Someone still has to talk to a person whose problem does not fit a category, whose request is ambiguous, who is senior enough that nobody wants to route them to a chat window, or who is distressed because payroll runs in an hour. This work is relational and interpretive, and it is harder than the ticket count suggests.
The second role is technical exception work. The engineer who validates what the system proposes on a hard case, handles the request it declared it had no precedent for, decides the medium-risk action that needs a human, and feeds the correction back so the next occurrence is covered. This is the residual I described when I wrote that the service desk gets harder before it gets smaller.
Neither role escalates to the other. That is the test of whether you have converged or merely renamed. In a converged layer, the two roles pull each other in, the way a bridge pulls in a specialist, rather than handing a ticket up a ladder and waiting.
Swarming, the model that has argued against tiers for over a decade, had this instinct right and arrived too early. It asked people to collaborate across tiers while the context still lived in individual heads, so it scaled exactly as far as those heads did. Converge the context first, and the collaboration model that was always correct becomes possible.
The Concession: Converge After Coverage, and Not Everywhere
Now the hard part, and the part I have to own. This is a destination. No estate I work in has completed it, and some never will.
Regulated estates will keep separations for reasons that have nothing to do with context: segregation of duties, dedicated-team requirements, audit boundaries written into contracts. Converging the layer there means converging the work while keeping the walls, which is slower and less tidy than the diagram.
And the sequence is not optional. Convergence follows coverage, queue by queue, after the system has proven on each one that it carries the convergent demand and declares what it cannot. Reverse that order, announce the tier cut first and let the coverage catch up, and you have removed the exception handlers before the exceptions have shrunk. The queue backs up, the residual gets mishandled, and the program is canceled for failing to deliver the thing it was never going to deliver on day one.
I have watched the cost-first version proposed more than once. The pitch is usually the same: the vendor says 70%, so cut 70%. The honest answer is that the vendor’s number is a ceiling measured somewhere else, and your coverage on your queues is the only number that can tell you when a tier boundary is safe to remove.
What This Changes
First, stop reading escalation rate as a first-line failure. In a converging layer the useful question is why the system escalated, not whether the human did. Measure exceptions by cause: no precedent, decision not delegated, access not granted. Each cause has a different owner and a different fix.
Second, redesign the job families before you redesign the org chart. Human-channel and technical exception are different careers with different hiring profiles. Writing them down now, while the tiers still exist, is what makes the convergence a transfer rather than a layoff.
Third, make coverage the gate. Publish, internally, the coverage state per queue and the rule that a tier boundary is removed only where coverage has held for a defined period. That turns a frightening announcement into a boring, auditable process, which is what you want.
The Question for IT Leaders
Look at your last month of L1 to L2 escalations and sort them by the real reason: information, access, or authority. If skill was the reason for fewer than you expected, your tiers are separated by context, and context is a thing you can build.
So my question: if the coverage data told you a tier boundary was safe to remove in one queue next quarter, is your organization designed to do it one queue at a time, or only all at once?
Next week: lean L3, the team whose product is demand reduction rather than resolution, and the team that owns the predictions.
Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.
