Last fall, we argued that per-seat pricing wasn't dead (see the Bain Brief “Per-Seat Software Pricing Isn’t Dead, but New Models Are Gaining Steam”). The market data since then reinforces that view.

About one in five AI-native software companies still relies mostly on per-seat licensing, often supplemented with usage entitlements. Even among companies expanding beyond seat-based pricing, most are layering new meters on top of seats rather than replacing them outright.

The bigger story is not whether software is moving beyond seat licensing. It's how companies should think about pricing AI—and the market conversation is missing some critical nuances.

Terms like usage-based, consumption-based, and outcome-based pricing mask key distinctions. In practice, most usage-based pricing is capacity-based pricing with overages, and some outcome-based pricing is actually tied to workflow outputs rather than business outcomes.

Software leaders will need to consider whether AI is dramatically shifting the way in which customers derive value from their products or adding significant marginal costs. If either (or both) of these is true, pricing likely needs to change. Understanding the full range of potential meters and models in the market, and the trade-offs between them, is important to getting that change right.

Three pricing models, not one

Much of the confusion starts with the language: Three distinct approaches are often grouped together under the umbrella of usage- and outcome-based AI pricing.

• Effort-based pricing charges for the resources that AI consumes to perform work, such as tokens, compute, or agent hours.
• Output-based pricing charges for what AI produces, such as summaries and drafts generated, records updated, or leads recommended.
• Outcome-based pricing charges for a business result, such as a customer issue resolved, fraud recovered, or revenue collected, ideally tied to a tangible financial outcome.

The distinction between output and outcome is particularly important. A recommended lead is an output, but a qualified lead is an outcome. An updated record is an output, while a completed business process is an outcome.

The simplest test is who carries the quality risk. Under an output model, the vendor gets paid regardless of whether the output creates value. Under an outcome model, payment depends on business results.

That difference has major implications for pricing strategy, operations, and the balance of risk.

A second dimension matters as well. Any of these meters can be sold either as direct usage (paying only for what is consumed) or as capacity, where customers pay for a fixed amount and don’t get refunded if they use less. The mechanics of selling and the customer experience differ sharply between these two models.

Under an output model, the vendor gets paid regardless of whether the output creates value. Under an outcome model, payment depends on business results.

Effort and output: The market is split

Among AI-native companies and seat-based software-as-a-service (SaaS) companies introducing a hybrid AI meter, only about 10% rely on outcome-based meters. The rest rely on meters based on effort (about 35%) and output (about 55%). We don’t see a significant difference between AI-native and seat-based SaaS companies.

Both approaches can work, but the choice depends on AI breadth and where the product sits in the customer's workflow.

Effort-based pricing is often more effective for broad AI portfolios and infrastructure products because it creates a common unit across many use cases. Customers can manage consumption through a single currency, whether that currency is tokens, credits, or a direct monetary unit such as dollars.

Output-based pricing tends to work better when delivering focused use cases, especially when the AI produces a more visible business product. Customers can directly connect the charge to the work delivered.

The same pattern appears across the technology stack. Infrastructure providers typically charge for effort because customers are buying technical resources. Higher-level applications often charge for output because customers are buying completed work.

Outcome-based pricing has a real, but limited, role

Outcome-based pricing has found a real home in one category: customer support, where a resolved conversation is observable, attributable, and contractible. Sierra and Fin both meter this way. Decagon does, too, while also offering an output-based option.

Beyond customer support, the picture is messier. Some vendors are experimenting with outcome-aligned models in other spaces, but there’s less evidence of entire market segments shifting. For example, Riskified guarantees approved transactions against chargebacks, taking a percentage of approved orders as the fee for that guarantee. HighRadius is testing pricing tied to outcomes in accounts receivable automation. But these are individual bets, not category trends, and whether they'll succeed at scale isn't yet clear.

Outcome-based pricing works when three conditions exist:

• The outcome is observable.
• The outcome is uniquely attributable to the AI.
• The outcome is contractible between buyer and seller.

Customer support agents often meet those requirements, but most workflows don’t. Marketing attribution is often disputed. HR decisions span across systems and people. Software engineering productivity remains difficult to measure consistently. Even when requirements are met, many vendors are finding outcome-based deals complex and time-consuming to negotiate, and difficult to bill at scale.

As a result, outcome-based pricing is likely to remain compelling but relatively narrow in scope over the next several years.

Outcome-based pricing has found a real home in one category: customer support, where a resolved conversation is observable, attributable, and contractible.

Most usage-based pricing is actually capacity pricing

The more important divide in today's market may not be effort vs. output vs. outcomes. It may be direct usage vs. capacity.

About four out of every five vendors introducing AI pricing are choosing capacity models. Customers commit to a fixed amount of capacity, up to a set level. They don’t get to roll over unused capacity or receive a refund, extending the economics of traditional seat licensing, where a significant share of purchased capacity often goes unused. Examples include Atlassian Rovo credits, ServiceNow Now Assist entitlements, and Adobe Firefly credits. While these models are often described as usage-based pricing, they are structurally capacity models. The distinction matters: Unlike true consumption pricing, vendors capture revenue even when customers do not fully use the capacity they have purchased.

For vendors, capacity models preserve many of the economic advantages that historically existed under seat-based pricing. Revenue comes from committed entitlement rather than pure consumption—and there’s often a significant difference.

For customers, capacity models create budget predictability. Procurement teams and CFOs can approve a defined commitment more easily than an open-ended variable spending model.

Direct usage pricing will continue to play an important role, particularly in infrastructure software and technical buyer segments. But for most enterprise applications, capacity is the favored model.

The meter is the strategy

AI pricing terminology will continue to evolve. The underlying economics will change more slowly. Choose a meter that aligns with how customers experience value, how costs are incurred, and how outcomes can realistically be measured.

In AI pricing, “outcome-based” or “usage-based” are the headlines. The specific meter is the strategy.