Back in July I wrote about how AI’s shift to cost-per-outcome can mask the value of those outcomes.

Vendors shifting to per-resolution pricing can come across as pretty magnanimous. “Don’t pay us unless we fix it.” It sounds like a good deal, and in many ways it is. However, there’s an obvious catch: the vendor gets paid every time a problem is resolved, but not for making sure it doesn’t happen again.

So, if a fault hits 50 users, that’s potentially 50 billable resolutions. Fix the underlying fault and those 50 resolution actions go away, along with the revenue.

The vendor may be better placed than anyone to see what’s recurring, but the pricing model doesn’t reward it for acting on that knowledge.

How current AI pricing models treat prevention

I’ve looked at the pricing models emerging across AI services, and where they may be misaligned with preventing issues as well as resolving them. This isn’t a suggestion of bad faith by any vendor, simply an examination of potential structural disincentives. No pricing model is perfect.

As the table shows, most vendors are being thoughtful and pragmatic about what counts as a resolution, incorporating checks such as detection of whether customers return with the same problem. That’s touches on the concerns I expressed in my July blog, in terms of reducing potential double (or triple or more) counting of resolutions of the same issue, but it still doesn’t reward the removal of the underlying cause.

So why not pay vendors for prevention instead? “We saved you $5m in outages this year, and we’d like 1% of it, thanks.”. Prevention has greater economic impact, and hence this is a mutually beneficial goal: the customer sees much greater benefits if incidents don’t happen at all, and a vendor that can put a convincing case for differentiating on prevention would have a great sales pitch in a competitive market.

The obvious question is “how do you know?”

The trouble with things that didn’t happen

A prevented outage leaves no ticket, no bridge call and no post-incident review. Everything depends on establishing what would otherwise have happened.

New Relic’s 2025 survey puts the median cost of a high-impact outage at $2m per hour. That makes a $5m prevention claim sound quite reasonable, but tells us nothing about whether an outage would actually have happened, or whether the AI prevented it. And it’s a massive number to present to the accounts payable team.

Other industries have been wrestling with this for years. Energy performance contracts pay contractors from calculated savings, using agreed baselines rather than directly measured savings. They measure energy consumption before and after improvements, adjusting for factors such as weather, occupancy and operating hours so that the figures can be compared fairly. The International Performance Measurement and Verification Protocol emerged in the 1990s to standardise those calculations. Its training material is wonderfully blunt: “We do not ‘measure’ savings!”

Perhaps given that statement, it’s not surprisng that disputes over those baselines and payments have frequently ended up in court.

Healthcare provides plenty of other case studies of attempts to shift economics towards prevention. For example, US Medicare began penalising excessive 30-day hospital readmissions in 2012. Readmissions fell, but gaming was rife. Some research attributes much of the reported decline to changes in coding. There were serious concerns about hospitals delaying readmissions beyond day 30. Anyone who has managed an SLA will recognise that behaviour.

I’ve seen enough contract gaming in IT outsourcing to know that any measure driving payments needs independent scrutiny. Prevention makes that particularly difficult, because both parties must agree how much of an improvement can reasonably be attributed to an intervention.

Could we actually measure prevention?

Major outages are relatively rare, so I’d start with recurring incidents, where there’s enough volume to measure a trend.

There’s a useful UK precedent in the Peterborough social impact bond. Private investors funded support for people leaving prison, and the government agreed to pay them a return if reoffending fell sufficiently against a comparable group. Independent assessment found a 9% reduction, exceeding the agreed 7.5% payment threshold.

Why couldn’t IT do something similar? Choose a high-volume incident category, agree the baseline and comparison group in advance, and record what the AI intervention was intended to prevent. Then measure what actually changed, allowing for incident exposure and other contributing factors.

Service desks already have a rough measure in MetricNet’s tickets prevented, which compares tickets per user against a historical baseline. Adding a comparison group would strengthen the evidence.

LLM-as-judge could also help keep the cost of assessment manageable. Atlassian already uses the technique to judge billable resolutions. Similar methods could review routine incidents for prevention evidence, with disputed or high-value claims referred for human review.

Where FinOps comes in

Last week I wrote about Tokenomics and AI economics, and the need to connect AI costs with the value of the work performed. I suggested carrying a common workload reference through investigations, problem records, changes and subsequent service performance.

Clearly similar thinking is already emerging from the FinOps and Tokenomics communities. FOCUS is extending its cost and usage specification for AI, while the Tokenomics Foundation is developing methods for measuring realised value, including avoided costs and reduced risk.

On 5 November, Shawn Alpay published a proposal for an AI Value Data Layer, linking cost, telemetry, tasks, outcomes and value through common identifiers. It also recognises that completing a task isn’t necessarily the same as delivering a lasting outcome. That’s very close to the tracking I was discussing.

However, I think degrees of causality might be the next question in that discussion. Prevention introduces a complexity problem. In real service environments, outcomes emerge from the interaction of multiple changes, people and circumstances. The effects aren’t necessarily additive, and an intervention that looks decisive might have achieved little without several others. Linking tasks to an outcome is useful, but it doesn’t establish how much each contributed, or how much of the improvement would have happened anyway.

Perhaps prevention could be recorded as an explicit outcome, including what the AI intended to prevent, what subsequently changed, and how much of that change can reasonably be attributed to its contribution.

The emerging data models look capable of supporting much of this. Established AIOps techniques for assessing contributing causes of failures also offer a useful starting point for thinking about prevention.

Why both sides should want this

If we can solve this data challenge, this is beneficial to both vendors and their customers. The customer gets a better saving that stands up to finanical scrutiny. The vendor gets paid for removing a recurring fault, rather than losing revenue when the incidents stop. The first one that can answer “how do you know?” with compelling evidence will have something pretty special to sell.

I work for Helix, which does not charge per resolution at this point. I do not currently have any involvement in pricing or pricing models. The views here are strictly my own.

Full ALT text for table screenshot in artilce:
Table comparing six AI pricing models, their potential misalignment with prevention, and vendors whose models have some alignment with that model.

• Per resolution: Fewer incidents mean fewer billable resolutions. Vendors: Fin, Zendesk, Fini, Atlassian CSM.
• Per conversation: Preventing requests reduces billable conversations. Vendor: Salesforce Agentforce.
• Per action or credit: Less repeat work means lower consumption. Vendors: Salesforce, Atlassian Rovo, Datadog Bits, ServiceNow.
• Negotiated outcomes: Prevention may not count as a payable outcome. Vendor: Sierra.
• Subscription plus consumption: Prevention may reduce variable charges without affecting the subscription. Vendors: ServiceNow, Salesforce, Atlassian, Zendesk.
• Bring your own LLM (BYOLLM): No model-consumption revenue for the platform vendor, but no separate reward for prevention either. Vendor: Helix.

I was standing in a loading bay at Walmart’s corporate headquarters in Arkansas, helping one of their asset management team work through a pallet of boxed laptops that had recently been forklifted with a thump into the centre of the room.

Perhaps that’s not quite what everyone would expect a product manager to be doing on a customer visit. But product management is a funny job. Steven Haines called it “the accidental profession” in The Product Manager’s Desk Reference, and there isn’t really any rulebook for how to do the job.

Typically, being a product professional involves dividing your attention between customers, developers, designers, marketers and support teams. But some days, it involves rolling up your sleeves, metaphorically and literally, and climbing over pallets of laptops. And do you know what? Those are the best days.

Perhaps to the slight bemusement of the crew, I had invited myself there to understand how IT assets were received, registered, and deployed across an enormous organisation. Equipment was arriving in volume, being unpacked, tagged and provisioned.

The task relied on data being entered into a PC in a small room off the loading bay. Someone had sensibly positioned the computer beside a serving hatch, making it easier for people working outside to reach it. But I still watched people walking back and forth between the equipment and the screen.

A short time later, I saw something similar on a visit to a large bank’s data centre, where I spent an afternoon with a team installing new servers into racks. Again, there was a computer in the corner, separate from the work being done. The technicians would jot down details on paper as they worked, with the genuine intention of keying the equipment movements and changes into the asset management tool, at the end of the day.

But sometimes the physical work lasted until the end of the day. When it ran over, there wasn’t any time left to update the system before heading home.

Both situations created what I call data-entry debt, in the moment, or accumulating over a day. That’s my term for work completed but not recorded; admin tasks interrupting the productive flow, and details that might later be completed from memory… inaccurately or not at all.

These visits helped me to make the right decisions as I led our mobile app transformation. We worked to allow people to record changes where the work happened, rather than interrupting the task or catching up afterwards. The lesson was simple: design around how people actually work, but don’t assume you know until you’ve seen it.

And that brings me to something that’s been bothering me about the current enthusiasm for AI-generated software.

The trouble with making software easy

I’m an enthusiastic user of AI development tools. I’ve used Claude Code to build prototypes and testing systems that would previously have taken considerably more time and effort. The ability to turn an idea into functioning software so quickly is remarkable. It’s letting me innovate faster than ever, making a real difference to our product and marketing agility.

But building an application and designing a good product are different things.

Give an AI coding agent a description of an asset management workflow and it can produce convincing screens, forms, dashboards and automated tests. It can look at other tools, read user manuals, and synthesise a convincing looking app. But what it doesn’t know is how it feels to use that app while processing the fifth pallet of equipment that day.

We’re already becoming accustomed to outwardly polished AI applications that have a recognisable look. Claude Code can build something that grabs attention, but it has never seen the wheel tracks worn into a service desk carpet by newer team members pushing their chairs across to ask a more experienced colleague for help.

Get out and see the world!

The product leader who has most influenced my thinking is Punit Singh Soni. His work first caught my attention at Motorola, where his team visited countless customers as they built the Moto G, building essentially the first cheap Android phone that didn’t completely suck by making one that was really great (I still think they’re great. I own the latest one). Punit would get out there with his team members, building real stories. He’s the product professional I always aspire to be.

In 2015, as Flipkart’s Chief Product Officer, he spent six hours accompanying delivery workers around Bengaluru during the company’s Big Billion Days sales event. His article about that day, entitled And I thought my job was hard…, remains my favourite piece of product-craft writing.

Soni describes meeting an elderly woman who couldn’t read English but had learned to recognise the app’s Buy button by its colour. Changing that colour had made shopping difficult for her. At a construction site, a worker explained why he needed precise delivery windows: he spent much of his day underground without mobile reception. Soni had assumed scheduled deliveries were a premium convenience. For this customer, they were a necessity. And he learned about the delivery workers themselves, carrying packages through Bengaluru’s heat, navigating difficult locations and unexpected delays.

The responsibility behind the design

If you work on enterprise products, you should always remember that your output might touch millions of real human lives each day, even if it’s just in a small way. Your craft is part of their job. We’ve all watched someone struggle through an unnecessarily complicated user interface while trying to help us. Being the person who has to use it all day is another matter.

If you know your customer well, you will be better at making products that are nice for them to use, but it goes further. Your tools can help people achieve better outcomes and become better at what they do. Your empathy as a product professional shouldn’t end with making someone’s working day easier. Your work can help them develop their skills and advance their career.

A support technician given the right knowledge at the right moment will resolve a problem faster. That’s great. But they have also just learned something that they can apply next time there’s an opportunity to do so. What might have been a handoff of work just became a personal achievement, and those skills accumulate to build a more capable employee.

AI can make us better at understanding customers, too

Over my product career, I’ve documented more than 700 customer interactions, from roadmap discussions and workshops to workplace observations supported by photographs and video. That evidence is enormously valuable, but it’s a lot of data. It’s easier to remember the most memorable stories, like those that involve climbing stacks of boxes, than all of the more familiar stories of knowledge workers doing their best from their desks.

AI changes what’s practical. We can investigate recurring problems over time, trace how expectations have evolved and test our assumptions against the original observations. Are apparently unrelated complaints symptoms of the same issue? Which problems have persisted for years? How have those problems evolved through the mobile revolution, cloud transformation and into the AI era?

Watch. Listen. Ask questions. Take notes. More now than ever, it’s how you build your capital as a product professional, accumulating knowledge and understanding that stays with you throughout your career.

Build faster. Understand better.

Faster prototyping and cheaper experimentation should give us more opportunities to learn from customers, not fewer. But if software is becoming dramatically easier to build, those of us responsible for bringing products to market need to spend more time understanding the people who will use them.

That still means watching people work, understanding their constraints and ambitions, challenging our assumptions and using AI to make better use of what we learn.

The danger of vibe coding isn’t just that we’ll build bad software. It’s that we’ll become extraordinarily good at writing code without ever understanding the people it’s supposed to help.

Their “release candidate”, Classifying and Measuring Realized Value from AI, was subsequently launched in September. It considering more profound questions about AI economics than much of the simplistic earlier analysis out there — much of which focuses on automating routine current tasks, and cutting jobs. In comparison, Tokenomics looks at deeper, richer outcomes, such as better quality, reduced risk and the enablement and delivery of entirely new organisational capabilities.

An AI industry chasing instant gratification risks overlooking these benefits.

Two foundations, one missing connection

Tokenomics is one of several initiatives under the Linux Foundation banner aiming to harmonise how we think about and measure the economics of enterprise AI.

FOCUS, the FinOps Open Cost and Usage Specification, is a Linux Foundation project developed with the FinOps community and major technology providers. It standardises otherwise incompatible billing data. Crucially, it is already in production. FOCUS exports are supported, albeit with differing levels of implementation, by AWS, Azure, Google Cloud and others.

FOCUS 1.4 already defines EffectiveCost, BilledCost, ConsumedQuantity, ConsumedUnit, ServiceName, SkuId and charge periods. The 1.5 working draft adds AI-specific properties within SkuPriceDetails, including ModelDeveloper, ModelId, TokenDirection and TokenCacheAction. New columns such as PrincipalId, CredentialId and RequesterDetails identify who or what incurred a charge, but not necessarily who benefited.

Launched in August 2026, Tokenomics is tackling the value side. Its September release candidate introduces Outcome Categories including increased capacity, improved quality, reduced risk and the emergence of new capabilities. Step 4, Measurement and Conversion proposes a four-stage process:

Observe → Net → Convert → Book

Observe establishes a measurement baseline. Net accounts for improvements after deducting failures and rework. Convert translates the resulting benefit into meaningful units, while Book identifies where a defensible financial gain can be recognised.

In its final section, What comes next, the release candidate explicitly identifies an unfinished task: reconciling those business value claims against the Total Cost of AI (TCA).

These last two steps, recognising defensible business value and reconciling it against cost, are hugely interesting because of their potential alignment with mature operational disciplines such as IT service and operations management.

Unlocking the real value of AI

At a conference in 2015, someone asked me what percentage accuracy was good enough for an asset management system. My answer was that the percentage tells you little unless you understand what’s in the part you don’t know. We have to think the same way with AI. Much of the economic picture seems obvious, but the things we’re not yet correlating may be where the biggest value sits.

Suppose AI cuts a five-hour problem investigation to three hours. Across twenty investigations, that’s forty hours of potential capacity, or a quarter of a Digital FTE, provided that capacity is put to productive use.

Now suppose a more capable agent uses more tools, burns more tokens and takes longer, but investigates dependencies that previously went unexplored due to capacity constraints. It uncovers the cause of a recurring service failure, enabling a permanent fix.

I wrote in July about some of the risks of this thinking, such as tool vendors pricing for repetitve simplistic gains, rather than proactive permanent fixes. There’s little motivation for that vendor to actaully be instrumental in fixing the problem, becuase suddenly that’s (10000 tickets a year x $2) evaporating from their revenue.

Ideally, that model should at least coexist with more proactive pricing tiers: “We will charge by the routine value-add transaction, but also take a small percentage of the provable value when our AI tooling fixes your underlying problem”. That’s a more cooperative model, with genuine joint incentives — but it needs a way to quantify that proactive value. That’s what interests me about Tokenomics.

Connecting the parts

FOCUS and Tokenomics provide complementary foundations, with substantial industry backing.

Both are evolving. FOCUS 1.5 remains a working draft, and Tokenomics’ value framework is a release candidate with open questions. What follows is my best interpretation of the published work and how we might build on it to develop a more complete picture of business value against cost. Given how rapidly both initiatives are evolving, my thinking is necessarily provisional, intended to encourage discussion and exploration rather than prescribe a production-ready model.

Working this through with a simple example from ITSM: Imagine carrying a workload_id from an AI-assisted investigation into a problem record, through the resulting change, and into subsequent service-performance measurements. Enterprise architecture could provide the relationships between applications, dependencies and business services; ServiceOps could supply evidence of incident frequency, availability and business impact over time.

This still needs thinking about how to link the resulting actions and outcomes to business value — something that would likely be the domain of the practitioners and enterprise architects in each organisation. They might have to consider, for instance, where multiple different problem investigations and resolutions have contributed to one improvement. But the Tokenomics model would enable attribution of evidence and observation periods, and even a confidence model. This would be an excellent thing to aim for.

Accounting for AI’s moving target

As I explored in my article on agentic governance, the non-determinism of AI and the complexity of technology systems can produce emergent behaviour. Similar workloads can follow different execution paths, even in consecutive runs, consuming different resources and producing different outcomes. Their economics may therefore be better understood as distributions of costs and outcomes, informed by repeated testing and operational evidence, rather than a fixed cost per task.

This might be the next challenge for alignment of FinOps, ITAM and ServiceOps: consumption economics, contracts and lifecycle context, would need to become dynamic — not simply founded in fixed asset registers and documented business flows, but fundamentally underpinned by live dynamic sevice modelling and process mining.

Tokenomics seems to provide the useful combination of a common language, industry participation, and an emerging data-driven methodology for measuring and proving value. We can increasingly count what AI consumes. The more interesting work will be establishing what it actually does for us.

JSH

The table in the article is an embedded graphic. The text is as follows:

Cost and usage: FOCUS 1.4 already defines “EffectiveCost”, “BilledCost”, “ConsumedQuantity”, “ConsumedUnit”, and charge periods. Potential addition: attributing these costs, alongside wider TCA, to individual business workloads.

Workload evidence: Tokenomics’ Observe and Net stages propose structures to record the scope of AI work, along with baselines, quality thresholds, and instances of rework, along with provenance details for tracing and govenrance. Potential addition: a persistent workload_id, connected service records and versioned evidence of subsequent outcomes.

AI consumption: FOCUS 1.5 extends SkuPriceDetails with AI model identity and token classifications, building on SKU-based pricing and counting structures familiar from Software Asset Management. Potential addition: linking AI execution traces to the persistent workload_id, allowing model and token consumption to be attributed to the business activity it supports — and reconciled with FOCUS costs.

Requester attribution: FOCUS 1.5’s model proposes a set of identifiers: PrincipalId, CredentialId, RequesterDetails and AllocatedServiceName. Potential addition: connecting the identity incurring a charge to the actual work performed and the business service benefiting.

Value and ROI: Tokenomics defines value categories and financial treatment in its Convert and Book sections, with TCA reconciliation envisaged in a future Run stage. Potential addition: explicit relationships between contributing workloads, downstream outcomes, costs and value claims, preserving attribution uncertainty and linking multiple workloads to incidental or accumulative outcomes.)

The aviation industry is, let’s face it, wildly impressive. Every day, it throws millions of squishy vulnerable people through the upper atmosphere at almost the speed of sound, encased only in thin aluminum cans full of volatile liquids. Despite that, it hardly ever manages to kill any of them.

In fact, 2023 was the industry’s safest year on record: there was not a single fatality in any accident on any commercial jet flight, anywhere in the world. It’s not even the first time that specific measure has been achieved in a full year. Over 1 million people die globally on roads (about 1 in 60 of all deaths is a road death), but the aviation industry is capable sometimes of achieving annual zero passenger deaths. It’s remarkable.

However, 2023 was not devoid of serious incidents. One example: in May of that year, an Air France A350 suffered a sudden collapse of its nose cone at 30,000 feet, apparently the result of hidden damage from an earlier bird strike. The dramatic structural failure hugely disrupted the aeroplane’s critical sensors, resulting in wildly inconsistent readings on key measures such as airspeed.

However, the plane coped, and its crew coped, and everyone survived. The aircraft’s automated systems continually vetted the incoming data stream, rejecting suspect information, switching between alternative data sources and temporarily reducing flight-control protections as necessary. Normal operating modes were restored when the data was trustworthy. By the time the aircraft landed safely, the captain’s display had automatically been reconfigured thirteen times in response to the evolving situation.

This illustrates a fundamental principle of aviation engineering: imperfection is expected. Sensors fail, information becomes unreliable and systems disagree. Pilots bring expertise and judgement, but they also need to trust the aircraft to recognise its own limitations and respond predictably. That trust is essential to aviation safety, and it has to be earned through engineering.

What are we actually asking AI to do?

AI is dominating IT strategy, but once we move beyond “proofread my email”, what are organisations actually trying to achieve? Essentially: productivity through automation, better decision support, reduced uncertainty, and less drift and inconsistency.

Yet an orthodoxy has developed around enterprise AI: the inputs need to be fixed before AI can work. Anything that AI does with bad data is not its fault. You must clean up your knowledge base, reconcile your CMDB, eliminate inconsistencies, and only then can AI be trusted. When AI delivers a wrong answer, the foundations are seen as an excuse: What did you expect? Your underlying data wasn’t accurate.

Of course data quality matters, but realism matters too. In complex environments there’s always something we don’t know. There will always be unforeseen issues which cloud the picture. Some gaps and inconsistencies are obvious, others emerge only when stumbled upon. No amount of hand-wringing and wishful thinking can eliminate them entirely. We can continuously improve data, but simply insisting on perfection is not just wasteful, it’s dangerous.

The pilots of that A350 didn’t need their systems to deliver perfect information. They needed them to recognise what couldn’t be trusted, signal the limitations and respond accordingly, allowing the crew to apply their expertise. That’s what trust in AI should mean too: not expecting it to be infallible, but trusting it to recognise and communicate uncertainty. If users have to second-guess every confident answer, AI hasn’t reduced uncertainty. It’s transferred the uncertainty and cognitive burden to them.

Designing AI around the assumption that its underlying data will be complete, accurate and consistent is lazy thinking.

Designing AI for the real world

Our industry is often stuck in deterministic thinking, even as we implement probabilistic AI tooling. With LLMs, uncertainty is just as inevitable as the wide range of events that a global fleet of airliners will collectively encounter each year. Yet many AI tools are incapable of handling contradictory information, often because they are rushed out with stubborn adherence to false preconditions.

My view is this: AI tooling should generally be built to test the data it relies upon. Disagreement should be expected, inconsistencies investigated, and actions adjusted to the available evidence. An agent might know enough to suggest a probable cause, but not enough to authorise a disruptive remediation. And if it identifies outdated records, it should help correct them.

In the retrieval-augmented generative systems commonly underpinning enterprise AI tools, for example, retrieval should not too narrow. If the first plausible resource is gathered and acted upon, then the risk is that contradictory information is never even inspected. The AI should have the opportunity to consider conflicting evidence, question its findings and seek clarification. Additionally, continuous improvement should be driven by acceptance of imperfection: Better data should be an outcome of using AI, not a prerequisite for it.

So let’s test for this. Give an agent outdated records, missing information and contradictory sources. Does it notice, investigate and know when not to act? If not, it’s probably not going to work in a real enterprise.

We’ve spent decades grappling with complexity, inconsistency and drift in enterprise systems. Why are we suddenly expecting data administrators to solve those decades-old problems before AI can work, rather than expecting AI to understand that uncertainty and respond smartly to it?

Customer service AI tool vendors have been adopting cost-per-outcome pricing in their commercial models, and the service management sector seems to be starting to follow. I can see the appeal, and in many cases I think it is a useful move. But I also worry that if IT departments focus too heavily on cost of outcome, without thinking hard enough about value of outcome, they may be walking into a familiar kind of trouble.

The shift to transactional pricing is not surprising. The rise of LLMs has effectively reintroduced the old idea of paying per cycle of compute. It looks very different from mainframe days, but the old logic has returned in a new form: usage has a direct cost, and somebody has to absorb it. Vendors like cost-per-outcome because it pushes exposure to LLM costs into the customer’s commercial model, rather than leaving the vendor with potentially uncapped financial exposure to token costs. Customers like it because they can compare those directly billed costs against reasonably familiar models for the cost of running a human-crewed service desk.

In and of itself, cost-per-outcome is a fundamentally sound measure. For high-volume, low-complexity issues, the economics are pretty simple. There are lots of benchmarks that try to pin down the cost of a basic, human-assisted first-line resolution. Let’s use a recent major analyst estimate of $13.50. If an AI-driven resolution is priced at $2, that can be seen as close to a $3m annual saving for an enterprise handling 5,000 of those cases a week.

That is an easy value case. The work is repeatable, the unit economics are clear, and the comparison with the existing human support model is fairly direct. It also gives buyers a better conversation than some of the older measures we have tended to lean on in service management.

I have a long-held discomfort with “ticket deflection” being used as a headline measure, because avoiding a support channel is not really the goal. The goal is more like: we get people’s stuff fixed more quickly and cheaply, and they are happy with the experience. Deflection might be part of that story, but it is not the story by itself. Making everything objectively measurable sometimes takes away the nuance, and support is full of places where the easy measure is not quite the same as the real objective.

The thing I keep coming back to with cost-per-outcome is the difference between cost-of-outcome and value-of-outcome.

For routine work, those two ideas can sit quite close together. The issue is known, the resolution path is predictable, and the value is mostly in reducing the cost of execution while maintaining or improving the customer experience. If a password reset, access request, or simple how-to issue can be resolved safely and well at a much lower cost, then the commercial logic is strong.

For more complicated work, I think this becomes dangerously simplistic. AI’s value will often not come from making the work cheaper. In some cases, it may do the opposite.

Think about a hypothetical major incident where a multi-team response costs $10,000 without AI. The team gets the service running again, but only through a workaround. The business is relieved, the dashboards go green, the incident is closed, and everyone moves on. The problem is that the underlying issue has not really been resolved, and a month later the same weakness contributes to a much larger outage.

Now introduce AI into that same situation. It might actually increase the immediate response cost. Perhaps the tooling surfaces better causal insights, correlates signals that would otherwise have remained scattered, pries open deeper lines of investigation, and gives the response teams enough confidence to pursue a more substantial remedial fix rather than the quickest acceptable workaround. That can mean more time, more people, more change activity, and more cost in the immediate response.

On a narrow cost-per-outcome view, that can look like a failure. The response used to cost $10,000, and now it costs $20,000. The cost of outcome has doubled.

But has AI failed to deliver value? Absolutely not, if that extra $10,000 helped prevent a million-dollar outage a month later. In that scenario, AI has not created value by making the task cheaper. It has created value by improving the quality of execution. It has helped cure the illness rather than simply masking the symptoms.

This is the part I do not see discussed enough. Value-of-outcome is much harder to measure than cost-of-outcome, especially predictively. It is difficult to prove the outage that did not happen, the repeat incident that never reached the service desk, or the weakness that no longer fails under pressure because the fix was more resilient than the workaround would have been. It is even harder to turn those avoided failures into a clean commercial unit that can sit neatly in a supplier contract.

But difficulty of measurement does not make the value unimportant. In some parts of service management, it may be the most important part.

Enterprises, unfortunately, have a long track record of signing up to supplier and partner models which create problematic incentives. In several decades in ITSM, I have seen too many such situations. A classic and frequent example is the outsourced service desk contract billed by the call, giving the provider very little natural incentive to help the customer reduce call volumes through better self-service. The customer wanted fewer calls. The provider was being paid for more calls, and had no reason to change. These situations typically resulted in years of delay, or expensive contract changes.

My concern with the shift towards highly visible “cost-per-outcome” measures at the front-line is that enterprises will once again fail to predict the peverse incentives. Shifting legacy contracts towards cost-per-outcome as a mechanism to pushing the price down to AI levels will be tempting, the pennies per transaction will quickly accumulate into nice looking returns. For routine work, that may be fine, because it is simple, repeatable, has pretty stadard outcomes, and is very easy to compare against human handling cost.

For harder work, I hope the ITSM sector learns its lessons and acts with due caution. If the model rewards cheaper closure more clearly than better resolution, it may create exactly the behaviour we do not want: fast answers, low unit costs, and unresolved problems quietly carried forward.

I have started to see an old friend reappearing in LinkedIn posts!

Back in 2013, I wrote an article for The ITSM Review about a supposedly historical “VP of Electricity” job that, it was being asserted, was analogous to the modern CIO. With cloud technology and SaaS applications becoming donminant, and enterprise IT departments apparently heading into decline, the CIO role would disappear just as surely as job of the head of electricity vanished once power became a grid- supplied commodity.

Info-Tech Research Group were hinting at this in June 2013 (albeit coming to a credible conclusion about the need for the CIO role to evolve). The Chief Electricity Officer metaphor is catchy, which is probably why it has persisted into 2026. But the argument missed a really important point, and it remains wrong now when applied to the CAIO.

(CIOs, it should be noted, are still with us in 2026, and they’re being paid more than ever).

The apocryphal VP of Electricity had a specific and bounded job, which existed simply because the grid didn’t. Electricity was scarce, locally generated. But it was, of course, largely uniform. An electron given a shove by your own generator was not materially different to an electron pushed along by your competitor’s generator, so there was no strategic difference. Once mass connectivity arrived, local production became a backup, and management of electricity was divided between the procurement and business continuity teams.

For the comparison to apply to the Chief AI Officer, CAIOs would need to be hand-crafting large language models on hardware they assembled themselves, and every AI capability delivered to the business would need to be as uniform and interchangeable as three-phase AC current. Neither of those things are true, because AI services are an order of magnitude more complicated than electricity.

Electricity providers simply provide power. They compete largely on price, with some variation around service, resilience, procurement models, and sources of generation. If you choose one over another, it might be because they’re cheaper, or because they answer the phone on the first ring. There are edge cases like local solar, but they do not change the basic outcome. Electrons are electrons. The utility model depends on the underlying capability being standardised, fungible, and delivered through shared infrastructure.

AI is very, very different. Maybe LLMs are the dominant AI category now and in the future, but the capability of AI services is still growing rapidly across models, reasoning, memory, autonomy, interaction, orchestration, governance, security, recursion, and integration into real workflows. AI will never be plug-and-play in the same, simple way that an electricity feed is.

There is a second problem with the analogy. Even in the case of electricity, the valuable outcome was not only a steady supply. Electrification involved people managing generators, but it also involved people working out what to do with electricity once it was available. The value was never in merely having electricity. It was in redesigning work around it.

Henry Ford’s advantage was not that he had access to electricity. His competitors had access to electricity too, increasingly from the same standardised supply. The advantage came from redesigning production around the new capability. The factory did not become more productive because somebody installed a light switch. It became more productive because the organisation changed the way work flowed.

The same pattern has been visible throughout enterprise technology. MIT Sloan’s 2007 article on the “alignment trap” found that the small minority of companies achieving IT-enabled growth were not simply spending more on technology. They were better at turning technology into operational advantage. The differentiator was not access to infrastructure. It was the ability to connect technology investment to better operating models, better information flows, and better organisational execution.

A third problem with the claim that electricity and AI are equivalent is the matter of lock-in. Unlike electricity markets, AI platforms introduce structural dependencies. Customers are reporting pricing pressure and finding themselves tied to providers. As their use of AI tools grows, their intellectual properties and processes become increasingly captured by the platform in a way that is hard to unwind and migrate. That’s a looming and very serious issue which I wrote about recently. AI services are not interchangeable commodities in the same way that power providers are.

These points are why the “technology becomes a utility, therefore the role disappears” argument usually struggles. Fundamentally it is confusing supply and access with application. It assumes that once a capability is widely available, the hard work has been done. But Dun & Bradstreet’s 2026 AI Momentum Survey found that 97% of organisations reported active AI initiatives, but only 5% said their data was ready to support them. The new “supply line” of AI services does not change readiness or application, any more than a new feed of 3-phase AC made new machines and production lines spontaneously appear.

The VP of Electricity remains a good story because it has the satisfying flavour of historical inevitability. There’s a basic narrative arc: A strange old role existed, but then a new utility arrived and the job evaporated.

But the CAIO is not buying generators or hiring people to shovel coal into them. They are helping to redesign the production line. Their role is not to power-up the factory. They are there to steer the factory from old ways of working to new ones.

I am seeing a very common refrain from well-meaning industry commentators, and the same line recently appeared even on the keynote stage of a major recent SaaS vendor conference.

IT teams are being firmy told: AI will only deliver value if you sort out your underlying data.

This means fixing your CMDB, cleaning up your knowledge base, rationalising your processes, and collating all of your disparate data.

This extensive cleanup is frequently positioned as an immutable prerequisite for getting any return on AI investment. At that recent conference, one of the vendor’s major customers — a sophisticated technology organization — admitted it had taken two years of hard effort to fix their foundations. Meanwhile, one of the vendor’s executives quoted a Gartner stat that predicted 60% of AI projects will fail in 2026… specifically because of these foundational data issues.

Ahem, vendors: You are the underlying data.

I work for a vendor too, and I’m happy to say it’s a vendor that understands that AI is a solution to foundational data maintenance, not a reward that pops out when that data is finally under control. Like the rest of our peers in in the IT management space, we provide the tools where incidents are recorded, changes are approved, assets are discovered, services are mapped, knowledge is written, requests are fulfilled, work is coordinated, and operational history accumulates over years.

A good vendor employs plenty of good practitioners. They know how difficult it can be to get foundational data right. They know that usually it is not a lack of will or a lack of skill. Maintaining those foundations has always required sustained executive backing and commitment that is not always on offer. It has always needed decent tooling and automation.

Foundational data is a challenge that was tricky enough decades ago, when a typical IT service ran on metal boxes in cupboards with dymo-taped machine names like “Gandalf” or “Merlin”. Of course, it’s much much harder in modern, distributed hybrid-cloud environments. This is not news in 2026.

And now, as vendors, we sell AI. If are going to tell customers that AI needs decent foundational data, then our tools — especially those new AI components — should be focused on not just on the glitzy stuff, but also on resolving the decades-long difficulties of maintaining the data platform. I’m happy that my own employer, which has always been an assertive innovator in the discovery and CMDB space, continues to understand this.

It means, for example, that in addition to the showy stuff, there should be AI agents which can identify CMDB data issues, trace the root causes of those issues, and fix them on an ongoing basis. It means there should be agents that spot gaps in knowledge bases, while also eliminating duplicate or obsolete content.

AI is great at that… so why do so many vendors ignore its role in solving these long standing data problems, and instead push the blame onto their customers?

If your vendors are saying your data is the barrier to AI value, then ask them what their AI tools are doing to remove that barrier. When someone tells you that that AI will only amplify your bad data, ask them why the data in their tools is so bad in the first place.

Don’t accept a false choice between glamorous agentic outputs and foundational cleanup. Demand both.

Consistently, our most successful AI adopters have established genuine understanding of the people using these tools and the work they actually do, because that understanding is what creates the conditions to transform how individuals perform. Earn that trust, and the adoption that delivers the bigger outcomes follows.

This is very familiar to me after several decades as an ITSM toolset innovator: trust is critical to adoption. It’s the same kind that anyone who’s worked with CMDBs or knowledge bases will recognise. You can mandate usage and report on coverage, but you cannot assert trust into existence.
Service agents are judged on resolutions and throughput. They are disinclined to waste time on “value adds” that don’t actually add value.

Trust forms when people discover that the tool improves their own skills, their performance and their results. And when that happens, their satisfaction in their work improves with it. They become strong advocates, and that enthusiasm spreads to the colleagues around them.

Typically, the best adopters start with a limited audience, watch what the agent does with real work, build on what’s working well, and address the gaps before expanding further. Tracking the desire lines through or around the AI tools gives a strong understanding of where value is being created, or where prior focus has been ineffective.

A good example of this in practice is what happens with the knowledge base. The templates, metadata structures and formatting conventions used in traditional knowledge management were an overhead, designed to mitigate the challenges of article creation, organization and retrieval in an operational environment. Early adopters often find that AI agents don’t need such structures. This creates an opportunity to remove friction and costs, and AI adopters have learned to unlearn some of the norms of established practices.

(I wrote recently about how AI removes our dependency on those knowledge management compromises: https://jonstevenshall.medium.com/ai-doesnt-care-about-your-knowledge-article-templates-8baf7e885107).

I’ve seen occastional commentary about the “death” of UX practice in the AI era, but our customers’ experiences are showing that experiential analysis and design still hugely matters.

The organisations making the most progress are the ones who invest in that understanding as a primary strategy for AI success. Adoption and individual success follows as a natural and hugely positive consequence.

This creates the platform for the big financial and performance transformations sought by the CIO.

For twenty years, knowledge management has centered on building curated document repositories.

The headings, lifecycle states and metadata fields that knowledge teams have spent two decades refining exist for human search and human reading. They were sensible design choices for a world where people had to manually locate, interpret and combine documents in order to solve problems.

Editorial teams governed templates, hierarchies and quality standards. Organisations invested heavily in processes, hoping to turn operational experience into a comprehensive set of structured articles. It was essentially a digital recreation of the library and card index system, and for a long time it was the best solution anyone had.

However, it was always a compromise, with significant issues for both content creation and curation, and for those consuming the results.

On the creation side, capturing operational knowledge requires time, recall and the ability to articulate what was actually learned while solving real operational problems. What gets recorded therefore reflects a difficult balance.

Operational work generates an enormous volume of situational methods, investigative paths and workarounds. Attempting to curate and structure everything does not scale, so organisations either focus on a smaller set of carefully maintained knowledge articles or capture broadly with looser structure. The first improves quality but limits coverage. The second improves coverage but introduces noise and inconsistency.

Knowledge-Centered Service emerged partly as an attempt to manage this trade-off, encouraging broad capture while improving the quality of what practitioners actually use. In practice, however, few enterprises have ever fully resolved this tension, and comprehensive, consistently reliable knowledge bases remain relatively rare.

The consumption side is equally problematic. Practitioners searching for answers sift through multiple search results, manually eliminating outdated or irrelevant material and piecing together fragments from several sources before arriving at something usable. In practice the system only works because people compensate for its weaknesses.

When working with customers or product development teams on knowledge management, my go-to resource is the analysis of proposed by Martin Ihrig and Ian MacMillan in their brilliant 2015 Harvard Business Review article, Managing Your Mission-Critical Knowledge. Their work deliberately stepped back from tools and processes, deconstructing knowledge of all kinds and examining how it actually develops and moves in organisations. It remains one of the more impressive and thoughtful attempts to explain the mechanics of enterprise knowledge.

Rather than treating knowledge management as a single activity, they described it as four distinct movements:

• Structuring tacit knowledge
• Diffusing it internally
• Contextualising it for new situations
• Discovering new knowledge

Operational IT teams have been attempting all four for decades, even if they did not always recognise it, and the frustrations most organisations encounter map almost perfectly onto each one.

Movement 1: Structuring tacit knowledge

Much of the most valuable knowledge in an operational environment never makes it into the system. People accumulate years of experience about how systems actually behave. They learn which symptoms matter, which alerts are noise, and which configuration decisions quietly introduce risk. This knowledge is built solving real problems under time pressure, yet very little of it is written down.

Practitioners recognise the value well enough, but the problem is timing. During an incident they are focused on restoring service. Afterwards, the next issue is already waiting.

Knowledge-Centered Service was designed to address this by encouraging knowledge capture in the workflow itself rather than as a separate documentation exercise. It represented a genuine improvement on the traditional model, which required articles to meet a defined standard before they were considered usable. But it retains a critical limitation: the deeper and more complex the knowledge, the harder it is to capture in an article format without losing what made it useful.

Movement 2: Diffusing knowledge internally

Even when knowledge is successfully structured, spreading it across an organisation is surprisingly unreliable. The team that solved a complex integration issue six months ago and the team encountering the same problem today may exist in the same organisation and sometimes even the same department, yet there is often no dependable mechanism connecting their experience.

KCS partly addresses this through search-driven capture, but its effectiveness still depends on article quality. That returns the problem to one of knowledge management’s oldest tensions. It’s a tricky balance to get right, and while some companies have done so, many struggled: Set the bar for documentation high and coverage collapses. Lower it and noise overwhelms signal.

Both failure modes end in the same place: practitioners stop searching and ask colleagues instead, and the distrusted knowledge base collapses.

Movement 3: Contextualising knowledge

Finding a relevant article is only the beginning of the work. Applying documented knowledge to a specific situation requires judgement extending beyond the specifics of the article. Engineers must determine which parts of a solution transfer to their environment, which assumptions hold, and which steps need adaptation. This often requires them to piece together fragments of multiple documents.

Internal documentation is only one part of the knowledge landscape. Practitioners constantly draw on vendor documentation, certification training, frameworks such as ITIL and their own prior experience from different systems and organisations. They reconcile these sources continuously, translating general advice into concrete action. This contextualisation work is largely invisible, but it is where expertise actually lives.

Movement 4: Discovering new knowledge

The final movement is the most ambitious and the least well served. Operational systems generate enormous volumes of data. Within that data are patterns explaining recurring problems, subtle relationships between configuration decisions and incidents that appear months later, and signals pointing to systemic issues nobody has yet named.

Problem management was intended to uncover these patterns, but in practice the volume of information and the cognitive effort required to analyse it meant that this knowledge wasn’t consistently captured by every organization.

What AI changes on the creation side

Traditional knowledge management asked people to stop what they were doing, recall what they had just learned and convert that experience into a structured article. AI removes that requirement.

Instead of writing knowledge articles, practitioners can simply narrate their work as it happens. Work log notes, recorded conversations, chat discussions and step-by-step observations captured during an investigation all become useful signals. Structure matters far less because retrieval no longer depends on rigid formatting. What matters is that the traces of real operational work are captured in the moment.

AI can then analyse those traces, extract relevant knowledge and attach insights to tickets, incidents and service records without anyone needing to produce a carefully formatted document. The knowledge base becomes a byproduct of work rather than a parallel activity layered on top of it.

What AI changes on the consumption side

Retrieval changes just as fundamentally. Instead of returning lists of documents that practitioners must sift through and combine, AI can generate consolidated answers directly in the flow of work. These responses draw on the full operational record and adapt to the specific situation an engineer is facing.

Practitioners can interrogate those responses conversationally, exploring related signals or drilling into supporting detail. The knowledge article was the right format for a world where humans had to search and read. It is not the right format for a world where AI assembles and delivers knowledge dynamically.

What to stop doing

For years organisations have treated the knowledge article as the central unit of knowledge management. Processes, governance models and tools have all been built around producing and maintaining those documents. AI breaks that assumption. Knowledge can now be extracted directly from operational work and assembled dynamically at the point where it is needed.

Many organisations will find that difficult to unlearn. Knowledge programmes, governance structures and tooling have all been built around the document. Many vendors are constrained in the same way. Their platforms are designed around article structures and repositories, and they lack the broader ServiceOps context needed to align unstructured historical knowledge with a deep understanding of the current operational situation.

But the simple fact remains: in the AI era, the knowledge document — always a problematic compromise between the needs of creation and the realities of consumption — will soon longer need to be the mechanism of knowledge management.

But before we talk about that, I want to talk about how much I love riding my bike. Bear with me. It’s connected. I promise.

On a bike, I am not fast, but I can ride a very long way quite slowly, which means I occasionally dabble in the quirky world of Audax riders. Audaxing is a charming subculture built on spectacularly long, unhurried, informal endurance rides. Riding Audaxes has taught me that even a grey dad with no sporting pedigree whatsoever can cycle for hundreds of kilometres at a time. All it takes is careful pacing, stubbornness, and a steady supply of custard cream biscuits. Of course, you want a very comfortable saddle.

Brooks saddles are the signature seating choice among anglophone Audax riders. These esoteric bike seats are large, improbably heavy, and made of thick, functional leather that still unnervingly resembles the side elevation of the cow that supplied it. They are also notoriously demand scores of hours of painful sitting before they stop fighting back.

The first few with a Brooks saddle months are hell. But once the saddle is eventually broken in, it has become uniquely adapted to its rider. The leather has formed and flexed and softened to match the specific backside of the specific individual. At this stage, as any Audaxer will tell you, the intial period of torture is over, and your Brooks is the most comfortable saddle in the world.

Unfortunately, some years ago, long after my Brooks saddle had evolved from torture device to trusted friend, I cycled squarely into a badger.

I am speaking, by the way, about the European variety of badger. American badgers are cuddly little squirrels in comparison. The European brute is grumpy, much bigger than commonly drawn in children’s books. A European badger is probably the only thing on Earth that is less yielding than a fresh-out-of-the-box Brooks. It happened in the dark, on a small Kent country lane. Both the badger and I were surprised. I found myself lying in the road, fretting about being either run over by a car, or eaten by a large, pissed-off mammal. Both felt like a possibility, and in no particular order.

I was fortunate. The badger trotted off into the darkness, nonplussed but apparently unharmed. I was unscathed despite a spectacular somersault and a thumping landing. In fact, the main casualty was my Brooks saddle. The insurance claims handler listened patiently, and matter-of-factly informed me that he was going to categorise the claim as “other”. I was back to day one of the Brooks pain-then-eventual-comfort process.

An AI model is a bit like a Brooks saddle. Just bear with me on this. After lots of initial pain, dealing with hallucinations and cloying flattery, a transformation starts to occur. A good large language model tool gets better the more you work with it. This isn’t because the underlying model suddenly becomes more capable, but because it becomes more attuned to you: the topics you revisit, the way you frame problems, your particular writing and conversational preferences. It becomes easier to work with because it has quietly learned who you are.

Inside organisations, a similar dynamic is emerging, although with far broader impact. The systems that support enterprise workflows increasingly incorporate generative AI and LLMs. These models gradually absorb the organisation’s particular way of operating. They learn the architecture of an enterprise, its incident and decision patterns, the informal relationships between teams, the behavioural habits of users, the gradual evolution of systems, and the familiar troubleshooting paths taken by experienced practitioners.

The value does not appear all at once. It builds gradually, through months or years of exposure to real work. The model’s ever-increasing behavioural awareness of how the organisation functions is built up in the latent structure of a neural network. It becomes a valuable organisational resource that, unfortunately, tends to reside inside systems that the organisation does not control.

Often, as a result of choices by software vendors, it is stuck there, opaque and unportable.

Most companies engage multiple vendors to provide multiple business-critical systems, and each has its own AI model. The result is a connected body of behavioural knowledge that is emergent rather than designed, shaped by interactions between teams and tools, and larger than the sum of its parts because work constantly crosses system boundaries. The consequences of removing any part of it will be uncertain and often daunting for decision-makers.

Most organisations already understand that moving between major enterprise systems is difficult. A migration often takes longer than expected, introduces operational strain, and temporarily reduces confidence in the new setup. This difficulty becomes a disincentive to change. Incumbent vendors know this well. It is one reason renewal pricing can be surprisingly aggressive. The risk and effort of migration are quietly priced into the contract.

Many organisations make the jump anyway. I recently ran a webinar with a customer — the ITSM product owner of a global telco — who had recently led a full migration from an old on-premise product to the newer SaaS version of our platform. The process took time because the business is extremely complex, but the long-term benefits have been substantial. Subsequent upgrades now take around five percent of the time they used to. As she put it, upgrades are “no longer a project”.

But the behavioural knowledge embedded in LLMs does not travel in the same way. This is not just a logistical challenge; it is an outright loss. The internal representations stored in the neural network’s learned parameters cannot be exported in any meaningful form. The organisation receives its transactional data back, but with too many software products, the behavioural model stays with the vendor.

It doesn’t have to be like this. Most enterprises also maintain central agreements with major LLM providers such as Microsoft, Google, and OpenAI. They do this because their staff will inevitably use these tools, and governance requires providing secure, sanctioned access. If organisations already have these agreements in place, then why can’t their vendors align to the LLMs chosen by the customer, designing their systems to ensure that the customer’s IP remains portable?

This moment matters. AI is becoming deeply woven into enterprise workflows. The decisions made now will determine whether organisations remain in control of the intelligence they generate, or whether they unwittingly distribute it across a landscape of proprietary models that they cannot extract, cannot inspect, and cannot meaningfully influence.

If organisations do not recognise this shift, they may soon find that their most valuable operational knowledge lives in places they never intended, and that regaining control of it is even harder than breaking in a new Brooks saddle after an ill-advised encounter with a badger.