On Monday I argued that enterprise intelligence — intelligence built from an organization's own history — is the work that hasn't started. Today I want to look at who already holds the largest stores of that history, and why they aren't using it.
ITIL and ITSM were never meant to be revenue models. Their purpose was to help IT services deliver the outcomes a business needs, in service of what the business exists to do. ITIL 4 says it plainly: a service exists to co-create value by facilitating the outcomes customers want.
Somewhere over the last three decades, the commercial models drifted. Products came to be priced by licenses and seats, and services by FTEs and ticket volumes. Now agentic AI has added a new unit: the agent invocation. ServiceNow's newly launched Flow is a timely example. A resolver fixes an issue, the fix becomes an automation, and every repeat is a metered event. The meter keeps running on problems that, in many cases, should not exist at all.
This is not a ServiceNow problem. It is an industry pattern, and the remedy is already sitting inside the companies best placed to break it.
The asset nobody is pricing
Take Cisco. Its routers and switches have run enterprise networks for more than three decades. Think about what that history holds: TAC cases, bug records, configuration patterns, failure signatures and upgrade outcomes. All of it can be correlated against business domains, architectures and scale profiles across nearly every industry.
That is historical intelligence. It can tell an enterprise planning a rearchitecture which configurations fail under its traffic patterns, which upgrade paths carry risk in its domain, and which designs quietly create years of operational toil.
Cisco is not unique. Operating system, database, application and development platform vendors have all been around long enough to hold some form of this intelligence. Even when the data is imperfect, even if it is only a partial clue, it is enough to start labeling, correlating and building intelligence that existing and new customers can use.
Today most of this intelligence is either unused or sold in slices: premium support tiers, health checks, assessments. It is almost never offered as what it could be, the foundation for outcome-based pricing.
The bigger, overlooked opportunity: service providers
Most of this conversation focuses on product vendors. The larger opportunity may sit with service providers.
MSPs that have run customer operations on ITSM platforms for years hold a remarkable dataset: tickets, incidents, changes, problems and resolutions across many enterprises, industries and technology stacks. And they don't need anything proprietary to their customers to use it. The infrastructure, application and data-layer patterns alone carry enormous intelligence. That includes which configurations generate recurring incidents, which application landscapes produce the same ticket categories year after year, and which data integrations break at which points.
This is a multi-million-dollar opportunity already sitting in providers' own operational history. Today it is being spent instead of used.
New customers. Consider how providers onboard today. Due diligence, then knowledge transfer, then months of shadowing and reverse shadowing, then a steady state that often reproduces the customer's existing problems under a new contract. The process is slow, repetitive and dependent on people, and every provider repeats it with every customer. Intelligence-led onboarding is different. The provider arrives with a disposition largely drafted from patterns it has already seen many times. It knows what to eliminate, what users can resolve themselves, what genuinely needs agentic automation, and where the operational risk sits. KT becomes validation rather than discovery.
Existing customers. Too many “transformations” are technology-driven: a new tool, a new platform, a new AI layer, laid over the same constraints. The result is the same problems with better dashboards. Transformation driven by historical intelligence starts somewhere else. It asks what the history says is actually constraining business performance, whether that's a process, a technology or an operating model. Then it decides whether to eliminate the constraint or redesign around it.
The sequence that matters
From my experience building and taking an AI-native shared services platform into production, the order is not optional.
Historical intelligence first. Build current-state understanding from what has actually happened, not from interviews and assumptions.
Eliminate what shouldn't exist. A large share of operational work is a design problem, not a resolution problem. In our platform work we saw 60–80% of work eliminated.
Empower users and automate the residual. Let users self-resolve where they can, and reserve agents for what genuinely remains.
Lead with change management. Intelligence only creates value when it drives actionable changes to the operating model, through transformation and transition.
Skip the first two steps and you are licensing, monitoring and paying for automation of work that should have disappeared. Eventually you also pay for managed services to keep those agents available and performing.
Why this hasn't happened yet
The objections are real, and they deserve a direct answer.
Cannibalization. Intelligence that eliminates work reduces the units vendors and providers bill for: licenses, seats, FTEs, invocations. This is the core conflict, and it's why incumbents hesitate.
Attribution. Business outcomes span multi-vendor stacks and the customer's own changes, so any single vendor will ask whose outcome it is. Historical intelligence is what makes attribution measurable. Without it, outcome pricing is guesswork. With it, the baseline, the intervention and the result are all visible.
Revenue predictability. Public companies are valued on recurring license and subscription revenue. Outcome pricing looks riskier on an earnings call, even when it is more defensible over a customer lifetime.
Data rights. Even non-proprietary operational metadata is usually governed by contract terms. Vendors and providers need explicit rights to anonymize and use cross-customer patterns, and that has to be designed into agreements, not assumed. It is solvable, but it has to be addressed openly.
The path to outcome-based pricing
None of these objections is a reason not to move. Each one is a reason to move deliberately: start with the intelligence, prove the elimination, measure the outcome, then price on it.
Whoever moves first will redefine the commercial model for their segment, whether that's a product vendor, an MSP or an outcome-aligned intermediary. We have seen this before. Cloud reset how infrastructure was bought, and the holdouts eventually followed on someone else's terms.
The intelligence already exists. It has been accumulating for decades in support databases, ticket histories and operational records. The question is whether its owners will keep spending it to sell more units, or use it to deliver what ITIL and ITSM were always meant to deliver: peak business performance.
Part of the enterprise intelligence series: building intelligence into every application, process, data layer and infrastructure discipline so it drives peak business performance.