Stop Buying Ticket-Closing. Buy Demand-Destruction

In early 2026, Uber ran out of AI budget. Not at year-end. Four months in. The company had set its 2026 budget for AI coding tools the year before, watched roughly 95% of its 5,000 engineers pick up Claude Code and Cursor, and burned through the money by spring. The fix was a cap: $1,500 a month, per tool, per engineer. Around the same time, SAP told its own investors that AI now assists every one of its internal support cases and resolves 20% of them with no human involved. Twenty percent, from the company that writes the software, on its own tickets.

Two numbers, one question. When an AI agent "does the ticket," how does the cost per ticket change? The Uber story already hints at the answer: per task, agents are cheap enough that five thousand engineers could run them all day. The cost question was never the tokens. I have spent years around SAP application management, on the side that runs the queues and the side that pays for them, and the numbers that follow are from that seam.

This post is the first of three. This one is about tickets, and how dynamics change. The second is about the business change once they are gone. The third is about the margin, and who might end up capturing it.

The agentic AI capability is real

METR has been measuring the length of task an AI agent can finish on its own, and the curve is steep: the task length it clears at 50% reliability has doubled roughly every seven months, and lately closer to every four. By April 2026 METR was publishing evidence of agents completing coding work that takes humans weeks. You can, of course, argue about benchmark accuracy, about reward hacking, about code quality and elegance, but consider this: a SAP support ticket is nothing like a week of work. It is a bounded change: a field that needs a default, a pricing condition that misfires, a role missing one authorization object, a background job that failed overnight. Fifteen minutes to a couple of hours, guardrailed, no drama and no code elegance needed. Those are exactly the tasks agents can handle.

The 60-minute ticket that takes two days

The reason a SAP application management ticket takes two days is almost never that the work takes two days. Most of what fills the queue is break/fix: incidents, something that worked yesterday and does not today. The contract grades them from P1, an outage, to P4, a cosmetic flaw, and attaches a service level to each. A medium-priority ticket sits in a queue because the service level lets it. The contract says two business days for a P3, so it waits two business days, and the real touch time is the 15 to 60 minutes someone spends once it reaches the top of the stack. That someone is usually an offshore engineer working against defined guardrails, on a rate around €15 an hour. Add 2 or 3 euros of tooling and platform overhead and a margin of 20 to 40 percent, and a 15-minute ticket bills at somewhere between 7 and 9 euros.

Take an example: a pricing condition in SAP misfires, and a customer is billed at list price because a discount condition record expired or was scoped to the wrong sales organization. The work is small and bounded: read the ticket, pull the order, trace the condition in the pricing analysis, correct or extend the condition record, and confirm the order reprices. Twenty or thirty minutes for someone who has seen it before. Everything else is waiting time. The ticket waits a day in the P3 queue because nothing says it cannot. The engineer asks the user through ServiceNow which orders are affected and loses half a day waiting for the answer. The change is built in DEV, moved to QA, tested, and transported to PRD on the next release window, and a business user signs off that the price is right. The fix is 30 minutes. The ticket is two days.

That is the situation the AI agent is competing against. Not an expensive specialist, not two person-days of labor, but a cheap, guardrailed task that has already been priced close to the floor and is mostly waiting. The AI agent's pitch against it is two words: faster and cheaper.

Faster, but for whom?

Speed is only worth money where the waiting was costing someone money. The AI agent picks up the ticket the moment it lands, triages it, asks the user a clarifying question back through ServiceNow when information is missing, and escalates when it hits something it cannot safely resolve. Elapsed time collapses from two days to minutes. It is genuinely impressive, and my read is that on the majority of tickets it is close to worthless, because a P3 ticket is P3 for a reason. Nobody was blocked. Providers cannot bill more for beating a service level no one needed to beat. The SLAs in RFPs are mostly written to protect the customer from a sluggish provider.

In product-flow economics, queues are invisible and still expensive: every day a piece of work waits, it carries a cost of delay. Don Reinertsen, whose The Principles of Product Development Flow is the standard text, reports that only 15% of product developers know theirs. For a P1 outage that cost is real and large, and speed is worth a premium. For the mispriced order above it is a credit note and an annoyed customer: real, but small. For a P4 cosmetic fix it rounds to zero.

Racing a floor we have already hit

Cheaper is the claim that sounds obvious and turns out to be the weak. Check the numbers on inference and they look small. An agentic coding run burns tokens by the million once you count the retries and self-correction loops. On a cheap model like DeepSeek's V4, at about 80 cents per million output tokens, that is peanuts. On a frontier model it is a few euros. Either way, the token bill is not the part that matters, because the expensive parts do not change. Providers would rarely push an unreviewed change into a regulated SAP transport landscape, so a human still reviews it. The path from DEV to QA to PRD does not disappear. The platform and integration costs sit on top, amortized across every ticket.

But a real version of cheaper exists. Offshore cost scales with human minutes, so a 60-minute ticket costs four times a 15-minute one. AI agent cost scales with tokens and iterations, which stay roughly flat as the task gets longer. The crossover favors the AI agent on the longer well-bounded tickets and works against it on the cheapest small ones. The 15-minute tickets everyone assumes AI will eliminate are those where the economics are most questionable. One might argue that inference will keep falling until none of this matters. But it changes nothing, because it lowers the part that was already cheap. Supervision and transport governance are where the real cost sits, and they do not fall with the token price.

So, bottom line, the 15-minute tickets will get cheaper, but not much. The impact on the longer, more complex tickets or small changes will be more significant.

The best strategy: destroy the demand

One strategy step-changes these economics. Every incident is a missing test. If the agent, in the same run that fixes the ticket, also writes the regression test for it, the unit of value changes underneath you. SAP customers already have the tool for this: Tricentis, resold by SAP as SAP Enterprise Continuous Testing. The work stops being cost-cutting, which is linear and competes to zero, and becomes asset-building, which compounds. Repeated incidents are reduced. Test coverage increases. The customer ends up with a regression suite they would never have funded as a standalone project.

Design it as a self-improving loop rather than a one-off. Each incident yields a test, a line of documentation, and a training example, and together those become the corpus: the legible model of your estate, the record of how it actually works. The system watches its own output, analyzes what recurs, and works toward fewer of the same incidents next quarter. Every turn adds momentum: coverage climbs, and the queue spins down instead of refilling. This is the gap MIT's NANDA study identified in the 95% of generative-AI pilots that returned nothing: systems that do not retain feedback, adapt to context, or improve over time. That failure is organizational rather than technical, an argument I made in an earlier post on enterprise AI adoption.

The second-order consequence: the rest of the ticket queue gets more expensive

Automate the easy tickets and the ones left are harder and more expensive. The agent does not skim evenly. It closes the clean, well-specified tickets and escalates the messy ones. SAP describes its own AI agents doing this in its Autonomous Enterprise pitch. Whether you buy that stack or assemble your own is the build-or-buy decision I walked you through earlier; either way, the second-order effect is the same. On the human side is a queue of nothing but hard tickets. Average cost per ticket temporarily goes up, not down.

What to actually contract for: a self-improving loop and your own corpus

If you are the person owning the contract, the argument comes down to two points. The first point is a service level on the self-improving loop, not just on response time. Usually SLAs reward queue mechanics and CSAT, and create no incentive to kill a root cause. This pathology is older than AI. Repenning and Sterman documented it in 2001, under a title that says it all: "Nobody Ever Gets Credit for Fixing Problems that Never Happened". Organizations reward the hero who saves the burning project and never the engineer who made the fire impossible, until firefighting hardens into standard operating procedure and the shop is stuck in what they call the capability trap. A queue mechanics SLA is a manifestation of this. So invert the SLA and measure the improvement instead:

• test coverage growth per quarter,
• a ceiling on incident recurrence,
• ticket volume declining year over year,
• a target half-life for the backlog.

That is a service level on the provider's ability to drive a continuous improvement cycle, and a provider that bills per ticket cannot realistically sign it without reworking its business model from time-and-materials to an outcome. That is the point of it.

The second point is ownership of that corpus. Whoever holds the tests, the documentation, and the training examples holds the account. Put ownership in the contract, or it turns into lock-in. The agents will get better at closing tickets whether you pay for that or not. The only decision left is what you buy. Stop buying ticket-closing. Buy demand-destruction.

If you are putting together an AI-for-SAP-support business case, or writing the service level that goes underneath it, I am glad to compare notes, on LinkedIn or by email.