Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 10 of Season 1. Stay with it.
A vendor shipped an agent this month that writes the problem record for you. It explains what recurs and how often, weighs candidate root causes with the evidence for each, separates today’s workaround from the permanent fix, and names the owning team.
That is competent work on the wrong artifact.
I have read excellent problem records attached to problems that went on recurring for another year. The record was never the constraint. The constraint is that in a standard operating model, nobody’s performance depends on the ticket not arriving next quarter.
My claim: L3 does not disappear when the easy work drains out of the queue. It gets smaller, and it gets a product. The product is demand reduction rather than resolution, which makes it the first function in IT operations whose output is work that did not happen, and the only credible owner of the predictions.
Figure 1: Demand reduction is a product. Somebody has to ship it.
Prevention Is Already an Activity. It Is Not Yet a Product.
An industry survey published this year found 66% of IT professionals reporting more time spent on proactive issue prevention, and 27% reporting a meaningful reduction in alert volume.
Read those two numbers together. Effort moved. Demand did not.
That is the signature of prevention run as an activity: capable people doing preventive work in the margins of a queue measured on resolution speed, so the organization pays for the effort and collects none of the structural return.
Problem management has lived in that gap for more than 30 years, and practitioners still describe it as the most neglected practice in service management. The reason is not conceptual. Problem work draws on the same engineers as incident work, and incident work always wins, because incident work has a clock on it and demand reduction does not.
So the first design decision is unglamorous. Separate the capacity. If demand reduction shares a queue with escalations, you will get escalations.
What the Job Is When the Product Changes
Lean L3 ships four things, and none of them is a resolved ticket.
A removed cause. A recurring class of demand traced to a fault, a configuration, a license model or a process step, and then changed so the class stops generating tickets. Not documented. Changed.
A converted archetype. A class the system could not carry, turned into one it can: the missing runbook written as executable steps, the missing context wired in, the decision boundary agreed with its owner so that governed execution is allowed to act.
A covered gap. Every case where the system declared it had no precedent is an input to this team, not a complaint about the system. Coverage grows where somebody works the no-precedent list.
A preempted class. The predictable failures: capacity, certificates, patch-driven regressions, configuration drift, known degradation curves. Each one gets a signal, an automated preventive action, and a named owner.
Notice what selects that work. Volume tells you where the effort is. Convergence tells you where the automation is. Lean L3 lives on the intersection of those two lists, which is why it needs measurement discipline more than it needs headcount.
Somebody Has to Own the Predictions
Preventive operations is where this function matters most, and it is also where most programs will fail, for a reason that has nothing to do with model quality.
A prediction with no automated preventive action and no accountable owner is a more anxious dashboard. It tells an operations team that something will break, adds that to their cognitive load, and changes nothing about whether it breaks.
The scope has to stay honest. We preempt the predictable: capacity, certificates, patch-driven failures, drift, known degradation. We do not claim to predict novel failure, and anyone claiming otherwise is describing a demo rather than an operation.
Lean L3 is the right owner because it is the only team whose definition of success is work that did not arrive. Give the predictions to a team measured on resolution and they become one more alert stream.
Poolable, and the Line Where That Stops
Here is the consequence that reaches the budget. When resolution context lives in a shared context foundation rather than inside individual engineers, a demand-reduction function stops being customer-specific in the way an incident team is.
The patterns repeat across estates. Certificate processes fail in the same few ways. Patch windows break the same classes of applications. A team that works removed causes can work them for several estates, because what the work needs is the context graph, not 10 years of tenure in one building.
That is a real economic argument, and it has a hard boundary. Regulated estates with dedicated-team requirements do not pool, and nobody should sell them as though they do.
The Concession
Two things I have to own.
First, lean is a consequence, not a method. L3 gets smaller because the resolution load drained out from underneath it, not because a plan cut it. Reverse that order, and you remove the engineers who were going to build the coverage, which is the same sequencing error I described when I wrote that L1 and L2 converge into one exception layer only after coverage is proven.
Second, this product is harder to measure than the one it replaces. A resolved ticket is a countable object. A ticket that did not arrive is a comparison against a baseline, and baselines move when the business moves. We measure it per class, against that class’s own prior rate, with the date of the change recorded. That is weaker evidence than a resolution count, and I would rather say so than pretend the metric is clean.
What This Changes
First, give demand reduction its own capacity and its own budget line, and make it unavailable to incident work. Borrowing from it is the failure mode, and it will be proposed in the first bad week.
Second, change what the team reports. Not MTTR on escalations. A backlog of causes removed, with the before and after demand rate for each class and the date the change landed.
Third, name the owner for each predictable class before you buy anything that predicts. If no name fits a class, prediction on that class is not yet useful to you.
The Question for IT Leaders
Look at your last four quarters. Find a class of ticket that recurred every month, and ask who was accountable for it still arriving. Not for resolving it quickly. For it still arriving.
If no name comes back, that is the job this article describes, and you do not have it yet.
So my question: would your organization fund a team whose best quarter looks like a shorter queue and very few closed tickets?
Next week: the automation ceiling is structural, not a data problem, and what happened when we tested that on an estate with unusually clean data.
Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.
