Measuring AI ROI: Usage-Based Pricing vs Seat Licenses

Every enterprise AI sponsor eventually gets the same question from the finance team: what are we getting for this? Measuring AI ROI sounds like a spreadsheet exercise, yet most organizations struggle to answer it with confidence. The tools are real, the demos are impressive, and the invoices are very concrete. The returns, by contrast, are scattered across hundreds of small moments in the working day, which is exactly why they are so easy to miss.

This guide is written for the person who has to defend the budget. It explains why measuring AI ROI is difficult, which numbers to watch early and which to wait for, how to count time saved and cost avoided without fooling yourself, and why the pricing model you choose changes the arithmetic more than most buyers expect. It also includes a worked model, clearly labelled as illustrative, so you can swap in your own figures. Along the way you will see where Higgins, the federated AI layer from higgins.ai, fits, and where its usage-based cost structure helps.

Key takeaways

• Most enterprise AI programs still struggle to show returns: IBM found only 25% of AI initiatives met expected returns, and Deloitte found typical payback takes two to four years.
• Measure in two layers. Leading indicators (active usage, tasks completed, time to first value) tell you within weeks whether you are on track. Lagging indicators (cost, cycle time, revenue, quality) confirm it later.
• Count time saved only after you decide what happens to the time. Hours that are not redeployed or removed from a budget are capacity, not savings.
• Seat licenses charge for potential. Usage-based pricing charges for activity, which keeps cost and value moving together and exposes shelfware instead of hiding it.
• Build a total cost of ownership view that includes integration, data preparation, training and governance, not just the license line.
• Treat every model, including the one below, as a range of scenarios. No vendor can honestly guarantee an ROI figure.

Why measuring AI ROI is so hard

Traditional software investments have a clear shape. You buy a system, a process changes, and a metric moves. A new accounts payable tool reduces invoice cycle time, and the controller can see it in a report. Enterprise AI assistants behave differently. They are horizontal: the same assistant answers a quality question in the morning, drafts a customer reply at lunch and summarizes a meeting in the afternoon. No single process owns the benefit, so no single metric captures it.

The evidence that this difficulty is widespread is consistent across independent sources. The IBM Institute for Business Value surveyed 2,000 CEOs in 33 countries between February and April 2025 and reported that only 25% of AI initiatives had delivered expected returns, and 16% had been scaled across the enterprise. McKinsey's 2025 global survey of 1,993 respondents found that 88% of organizations use AI in at least one function, yet only 39% attribute any level of EBIT impact to it, and most of those say the impact is under 5% of EBIT. MIT's NANDA initiative went further in its 2025 report, describing a 95% failure rate for enterprise generative AI solutions in its dataset, a figure widely reported by Fortune. That figure should be read as a statement about the measured P&L impact of pilots, not about every deployment, but the direction is clear.

The measurement gap in enterprise AI

There are three structural reasons the measurement problem persists.

First, benefits are diffuse. Ten minutes saved per person per day is invisible in any one workflow and significant across a company. Nobody files a ticket when a search takes thirty seconds instead of twenty minutes.

Second, baselines are missing. Few teams recorded how long tasks took before the assistant arrived. Without a baseline, every claimed improvement is an anecdote.

Third, costs and benefits arrive on different clocks. Licenses, integration work and training hit the first quarter. Habit change, process redesign and compounding benefits take far longer. Deloitte's 2025 survey of 1,854 senior executives found that most respondents expect satisfactory returns on a typical AI use case within two to four years, compared with the seven to twelve months they expect for other technology investments.

None of this means ROI cannot be measured. It means you need a method that suits diffuse, early-stage and partly qualitative benefits, rather than forcing a single metric to carry the whole case.

Leading versus lagging indicators

The most useful distinction in AI measurement is the one finance teams already use elsewhere: leading indicators predict outcomes, lagging indicators confirm them. In a typical enterprise AI rollout, you want both, and you want to know which conversation each belongs in.

Leading indicators: are people actually using it?

Leading indicators move within days or weeks and tell you whether the conditions for value exist. Useful examples include:

• Active users as a share of eligible users, measured weekly rather than as a one-time activation count.
• Frequency and depth of use, such as sessions per active user and tasks completed per session, rather than raw log-ins.
• Time to first value, the number of days between a person receiving access and completing a real work task with it.
• Task completion and acceptance rates, meaning how often an answer or draft was used rather than discarded. Leading indicators are cheap to collect because the platform generates them. Their weakness is that they measure activity, not outcomes. High usage of a poor tool is still a poor tool, which is why they should never be presented alone to a CFO.

Lagging indicators: did the business change?

Lagging indicators take a quarter or more to move and carry the weight in a business case:

• Cycle time for defined processes, such as time to produce a regulatory response, close a support ticket or prepare a customer proposal.
• Rework and error rates, such as documents returned for correction or audit findings.
• Cost per transaction in functions where you can count transactions.
• Capacity redeployed, meaning hours that moved from administrative work to revenue-generating or quality work.
• Revenue effects such as pipeline conversion or faster quote turnaround, where attribution can be tested.

Connecting the two

The practical discipline is to write down, before launch, the chain you expect: usage leads to time saved on named tasks, which leads to redeployed capacity, which leads to a measurable business outcome. Then you watch each link. If usage is high but cycle times are flat, the chain is broken between link two and three, and you know where to investigate. If usage is low, you do not need to wait a year to learn that the case is at risk.

A measurement chain you can audit

1. UsageActive users, tasks completed, time to first value
2. Time savedMinutes per task against a recorded baseline
3. Capacity redeployedHours moved to higher-value work or removed from a budget
4. Business outcomeCycle time, quality, cost per transaction, revenue
5. ReviewQuarterly comparison with the business case

Time saved, cost avoided and what finance will accept

Time saved is the most common AI benefit claim and the most commonly challenged one. The challenge is fair. A person who saves an hour and spends it browsing the internet has produced no return. The honest approach is to separate three categories and apply a different standard of proof to each.

Productive capacity (soft savings)

When an assistant retrieves a procedure in seconds, drafts a first version of a report or produces meeting minutes automatically, people gain time. This is real, but it is capacity, not cash. Present it as hours returned, valued at a loaded hourly cost, and then apply a realization factor that reflects how much of that time is actually redirected to useful work. A realization factor of 30% to 60% is a reasonable range to test, and showing the factor explicitly builds trust far better than assuming 100%.

Cost avoided (cost avoidance)

Cost avoidance is spending that would otherwise have happened. Examples include not hiring a contractor to clear a documentation backlog, avoiding an outside service for routine translation or summarization, or preventing a repeat of a quality escape because a lesson learned surfaced at the right time. Finance teams accept avoidance when it is tied to a specific plan or budget line that was credible before the AI program existed. They are skeptical of avoidance claims that were never part of any plan.

Hard savings, such as a cancelled contract or reduced overtime, are the strongest evidence, and revenue effects need a comparison group to be credible. A good rule: put time saved in the business case at a discount, put cost avoided in at its documented value, and put hard savings and revenue in only when you can point to a ledger or a comparison. This is slower than a headline number, but it survives scrutiny, and it protects the program when budgets tighten.

Seat-license shelfware versus usage-based pricing

The pricing model shapes ROI more than most evaluation spreadsheets acknowledge, because it determines how cost behaves when adoption is uneven. And adoption is almost always uneven.

Under a seat-license model, you pay a fixed fee per named user per year, regardless of whether that person uses the product. The vendor's revenue is predictable. Your cost is fixed at the moment of signing, while your benefit depends on adoption you cannot guarantee. When a quarter of the licensed population never logs in, those seats become shelfware: paid for, installed, unused.

Shelfware is a well-documented phenomenon in enterprise software generally. A Nexthink report from 2023, covered by TechRepublic, found that almost half of installed software and licensed SaaS applications went unused, amounting to roughly $44.7 million per month across the 30-plus tools it analysed. That study was about software broadly, not AI specifically, and you should not assume AI seats behave identically. But the mechanism is the same, and AI tools have the added problem that value depends on a behavior change, which is precisely what some seat holders never make.

What usage-based pricing changes

Under usage-based pricing, cost follows activity. If a team uses the assistant heavily, you pay for that use, and you should see the corresponding benefit. If a team ignores it, you do not subsidize their seats. Three consequences follow for measurement:

1. Cost per outcome becomes visible. Because cost and usage are linked, you can compute cost per task or cost per active user directly from the bill.
2. Shelfware cannot hide. Low adoption shows up as low cost, a clear signal that something needs attention, rather than as a fixed expense that obscures the problem.
3. The vendor shares your incentive. A provider whose revenue grows when the product is used has reason to make it useful, not just to make it signed.

Usage-based models are not free of trade-offs. Budgets are less predictable than flat fees unless you agree on ranges, thresholds or caps, and heavy adoption means a larger bill. The key is that a larger bill should accompany a larger benefit, and you should insist on the reporting that proves it.

Adoption is the gap that decides ROI

View chart data

Item	Value
Organizations using AI in at least one function (McKinsey)	88%
Attribute any EBIT impact to AI (McKinsey)	39%
Have begun scaling AI programs (McKinsey, approx.)	33%
AI initiatives that met expected returns (IBM)	25%
AI initiatives scaled enterprise-wide (IBM)	16%

Building a total cost of ownership view

ROI is a ratio, and most AI business cases get the denominator wrong. The license or usage fee is the visible part. A credible total cost of ownership (TCO) model for an enterprise AI assistant includes several other layers, and leaving them out flatters the result until the first budget review.

Platform and usage fees. Either seats or consumption, plus any charges for environments such as sandbox, pilot and production.

Integration and data preparation. Connecting to SharePoint, a PLM system, a CRM or a ticketing platform takes engineering and security review. Poor data quality is one of the most frequently cited causes of AI project failure, so budget for cleansing and for deciding which source is authoritative. Our guide to data readiness and a single source of truth covers this in detail.

Security, privacy and compliance work. Risk assessments, security and API testing, and mapping controls to the regimes that apply to you. See AI governance, security and compliance for what to expect.

Training and change management. The most underestimated line. People need to learn what to ask, what to trust and where the boundaries are. Programs with structured onboarding outperform those that simply send a link.

A useful discipline is to present TCO per active user per year alongside total spend. That single number makes seat and usage models comparable, and it forces the adoption assumption into the open.

A worked illustrative model

The following model is illustrative. It uses round, hypothetical numbers to show the mechanics of the calculation, not results from any customer and not Higgins pricing. Replace every input with your own data before drawing any conclusion.

Assumptions

• A company has 1,000 eligible associates.
• Under a seat-license model, it buys 1,000 seats at a hypothetical $30 per user per month, which is $360,000 per year.
• Under a usage-based model, it pays a hypothetical $180,000 in the year, reflecting actual activity. This figure is assumed for the exercise and is held constant even in the weak-adoption case, which is conservative because real usage fees would normally fall as usage falls.
• Both models carry the same $200,000 in first-year integration, security review, training and internal time.
• In the base case, 400 associates become active users and each saves 1.5 hours per week over 46 working weeks.
• A loaded cost of $60 per hour, and a realization factor of 40%, meaning only 40% of the saved time converts into value that finance would recognize.

Calculation

Hours returned in the base case are 400 users × 1.5 hours × 46 weeks, which is 27,600 hours. At $60 an hour that is $1,656,000 of capacity. Applying the 40% realization factor gives $662,400 of recognized value.

Seat model total cost: $360,000 + $200,000 = $560,000. Net value: $662,400 − $560,000 = $102,400, an ROI of about 18%.

Usage model total cost: $180,000 + $200,000 = $380,000. Net value: $662,400 − $380,000 = $282,400, an ROI of about 74%.

Stress test: weak adoption

The model shows that pricing structure changes the downside more than the upside, and that adoption and realization dominate everything else. It does not show that any product will deliver these hours.

Now assume savings are only 0.75 hours per week per active user. Hours returned fall to 13,800, capacity to $828,000, and recognized value to $331,200. The seat model then shows a net of −$228,800 (about −41%), and the usage model a net of −$48,800 (about −13%). Neither case is attractive, but the fixed commitment is far more painful, because it cannot flex with the disappointing result.

Year-one net value by pricing model and adoption scenario

View chart data

Item	Value
Seat license, base case	$K102
Usage-based, base case	$K282
Seat license, weak adoption	$K-229
Usage-based, weak adoption	$K-49

How to run a measurement program in practice

A measurement program does not need to be elaborate, but it does need to be deliberate. A pattern that works for most enterprises has five steps.

1. Pick three to five target use cases before launch. Choose tasks that are frequent, administrative and measurable, such as retrieving procedures, summarizing email, producing meeting minutes or drafting recurring reports. Avoid trying to measure everything.

2. Record baselines. For each use case, capture the current time, volume and error rate with a small time study or a self-reported sample. Even a rough baseline from twenty people is far better than none.

3. Instrument the leading indicators from day one. Weekly active users, tasks completed and retrieval success should appear on a simple dashboard that the sponsor and the finance partner can both see.

4. Run the pilot against a comparison group where possible. A team that has the assistant and a similar team that does not will tell you more in eight weeks than a company-wide estimate will in a year. Where a comparison group is not possible, use before-and-after windows and note the confounders.

5. Review monthly, decide quarterly. Monthly reviews catch adoption problems early. Quarterly reviews compare lagging indicators against the business case and decide whether to expand, fix or stop.

If you are earlier in the journey, our article on why enterprise AI pilots fail explains the patterns that keep programs from reaching this stage.

How Higgins supports measurable, usage-based AI

Higgins (higgins.ai) is a federated AI layer that sits in front of your existing enterprise applications and gives every associate one assistant for retrieving information, standard procedures, forms and reports, summarizing email, taking meeting minutes and action items, and automating administrative work. Several design choices bear directly on how you measure ROI.

Usage-based cost structure

Higgins' maintenance and usage cost is based on usage, not on the number of users or on annual seat fees. The reasoning is simple: associates use Higgins only if it makes them more efficient, so higher usage means greater return. Usage fees are set by data accessibility and by the company's AI optimization needs, and integrating an existing company AI or application into Higgins is designed to be seamless and to reduce usage costs. The practical effect for a buyer is the one described above: cost and activity move together, and low adoption is visible instead of buried in a fixed contract. As with any vendor, you should not read this as a promise of a particular return. Outcomes depend on your data, your processes and how well the tool is adopted.

Phased deliverables that create early evidence

Higgins is implemented in phases, with Listening Sessions at each one so the biggest challenges are tackled first, and every phase ships a deliverable that makes an impact. That structure suits leading-indicator measurement.

• Phase I introduces Best Practices AI that is not connected to company data, and can start immediately. It gives you early adoption data and a baseline of how associates use discipline-specific AI.
• Phase II adds a junior-level assistant connected to limited company data through validated connections to common repositories such as SharePoint, Teams, Notes and ServiceNow, focused on associates' top-of-mind project and product work.
• Phase III adds a senior-level assistant connected to some company software through APIs, for example Polarion, Veeva, Tableau or a PLM such as Siemens Teamcenter, combining unstructured data with structured PLM data for deeper insight.

The rollout path moves from sandbox to pilot trial to beta launch, with approval through your IT process along the way. Each stage is a natural measurement checkpoint, and our enterprise implementation page describes the approach in more detail.

Security that reduces hidden cost

Higgins integrates with the applications you already run rather than replacing them, which keeps the integration line in your TCO smaller (see the integrations overview).

Company data and intellectual property are not permitted to leave the company's environment, and permissions and usage are governed centrally. Higgins is designed to be approved through your IT process, including risk assessments, security testing and API security testing, and is designed to support regimes such as HIPAA, GDPR, SOC 2 and 21 CFR Part 11. Customers should confirm scope with Higgins for their own deployment. Fewer security surprises means fewer delays, which is a cost avoided in its own right. Details are on the security and compliance page.

Onboarding that drives the leading indicators

A seven-day program, Getting to Know Higgins, walks associates from generating their profile through bringing one and then a second work AI into their daily routine and saving favorite work operations. Structured onboarding is one of the cheapest ways to move time to first value in the right direction. If you want to understand how other people describe their experience, the testimonials page collects feedback, and the about page explains the background of the platform and its founder, Dr. Malik Hakim.

Frequently asked questions

Next steps

Measuring AI ROI is less about finding the perfect metric and more about building an honest chain from usage to outcome, pricing the program in a way that makes weak adoption visible, and giving finance the evidence in the form it can accept. If you would like to see how a usage-based, phased approach could work in your environment, explore the Higgins Enterprise overview, review the implementation approach, or contact the team at enterprise@higgins.ai to discuss your use cases and how you would measure them. For leaders building a broader adoption plan, the Masterclass offers structured learning, and our article on how AI accelerates enterprise growth looks at the revenue side of the equation.