Nobody Owns Whether Demand Should Exist

Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 2 of Season 1. Stay with it.

Sit in any quarterly service review. Mean time to resolution (MTTR) is down. Service-level agreement (SLA) attainment is green. First-contact resolution (FCR) is up. The backlog is cleared. Now ask one question and watch the room: Is there less demand than there was a year ago?

In most operations, nobody can answer that. More telling, nobody in the room is responsible for the answer.

My claim: Every metric on the standard operations scorecard measures how well you process demand. None measures whether the demand should have existed. And because demand reduction appears nowhere in the operating model, it has no owner, no budget, and no career attached to it. That is an org design failure before it is a technology failure.

The Scorecard Measures the Queue, Not the Cause

MTTR, first-contact resolution, SLA attainment, backlog age. Every one of them measures the speed and quality of demand processing. An operation can improve all of them, year after year, while the underlying failure rate stays flat. It can win an award for it.

The incentive stack makes it worse. Headcount is sized by ticket volume. Vendor contracts are priced by it. Budgets are defended with it. Nobody measures demand, and everybody depends on it: The commercial structure of operations assumes demand will persist.

Look at what a ticket actually is. Every ticket is the enterprise telling you something failed, was unclear, or was not self-serviceable. That is a demand signal. But operations teams are measured on clearing the queue, so the signal gets treated as workload. The envelope is processed, and the message is thrown away.

The clearest evidence is how predictable failures are handled. Certificate expiry. Capacity exhaustion. Patch-driven regressions. Configuration drift. None of these are surprises. All of them are routinely handled as incidents, after impact, by people paid to respond quickly. An enormous share of unplanned work is planned work that nobody planned.

And here is the uncomfortable part: handling that work fast counts as success. The scorecard rewards the operation for absorbing demand it should have removed.

The Market Found the Diagnosis and Stopped Halfway

Credit where due: This year, vendor content started saying it out loud. MTTR measures how gracefully you fail. Several platforms now promise ticket volumes approaching zero. The diagnosis is correct, and it is the same one I am making.

The cure on offer is not. In every version I have read, the answer is a product: deploy the agent, and demand melts away. No one addresses who in the customer’s organization is accountable when it does not.

Watch what happens to the deflection rate, the metric these promises get measured on. Deflection is the most gameable number in service management, because a system that quietly stops people from getting help scores beautifully on it. A deflected ticket and a prevented failure look identical on that chart. They are not the same thing.

Prevention has the same trap. A prediction with no automated preventive action and no accountable owner is not prevention. It is a more anxious dashboard.

Fig 1: The job nobody has.

Alt text: Organization chart titled The job nobody has. IT Operations has owners for MTTR, SLA, the queue, and uptime, plus one vacant dashed box labeled Owns removing demand, noted as vacant in most operating models.

What Ownership Actually Looks Like

Demand reduction becomes real when a named function owns it: measured on ticket and incident demand against the operation’s own baseline, with authority over the things that generate predictable demand. Problem management, capacity, certificates, patch quality, and drift.

The nearest thing most organizations have is problem management, and that is where good intentions go to be deprioritized. It owns root cause analysis but not the patch calendar, the capacity plan, or the budget. Accountability without authority is how this work has not been done for 20 years.

That function needs a different scorecard. Put ticket and incident demand next to MTTR on the board pack and expect a strange thing to happen if the strategy works: MTTR stops improving.

In our stage model, MTTR improvement plateaus at roughly 60% once prevention takes hold, while demand reduction climbs past 40%. Both ranges are conservative, customer-wide, and cumulative against the customer’s own baseline; final commitments require customer-specific baselining. The plateau is not a failure. It is proof that the lever changed: The incidents that remain are the hard, novel ones, and they always were.

Now, the concession, because this argument gets oversold in the opposite direction, too. Demand does not go to zero. The removable share is the predictable share: capacity, certificates, patch-driven failures, drift, and known degradation patterns. Novel failure still arrives, and the residual incidents still need fast, well-run resolution. The claim is not zero tickets. The claim is that a large share of demand is removable, and that today nobody in the standard operating model is assigned to remove it.

The Question for IT Leaders

Here is the test. Ask who in your organization is better off next year if ticket volume falls. Not who would celebrate it. Who is measured on it, budgeted for it, and promoted because of it.

If the answer is your service desk lead, look again: Their budget is volume-based, and demand reduction shrinks it. If the answer is nobody, you have found a vacancy that matters more than any tooling decision on your roadmap.

The lever in IT operations is shifting from resolving demand faster to removing demand itself. The tools for that shift are arriving. Accountability for it does not yet exist in most operating models.

So, the question is: in your operation, who owns the queue that gets structurally shorter? I am asking because in most estates I walk into, the honest answer is no one, and I would like to hear from anyone who has solved it.

Next week: We stopped estimating automation potential and started measuring it against real ticket estates. The number came back lower and more useful.

Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.