AI pricing is changing but subscription economics persist

AI pricing is changing, but subscription economics persist

AI is changing how software companies charge customers. Yet the shift away from per-seat licenses has produced a surprising result: approximately 80% of software vendors introducing AI pricing are choosing capacity arrangements, where customers purchase a defined allowance regardless of how much they eventually use. Meanwhile, about 20% of AI-native software companies still rely primarily on traditional seat licenses.

These findings come from Bain & Company’s June 2026 analysis of publicly available pricing across approximately 200 B2B SaaS companies. They challenge the expectation that software pricing will move steadily from seats to consumption and eventually to business outcomes. Vendors are increasingly measuring the resources AI consumes, the work it completes, and the business results it delivers. But many still sell those capabilities through familiar enterprise commitments.

In its Bain Brief, “AI Pricing: A Reality Check on Effort, Usage, and Outcomes,” the firm examines two decisions that are often treated as one: what generates a charge and how customers commit to paying it. The first determines the pricing meter. A vendor can charge for computational resources, completed work, or measurable business results. The second determines the purchasing structure: customers can pay for actual consumption or commit to a predefined allowance.

These choices are independent. A software company can introduce a usage-based meter while preserving the predictable revenue associated with subscriptions. For technology leaders deciding how to monetize AI, both decisions matter.

AI pricing is moving beyond seats

Traditional SaaS pricing generally charges customers according to the number of licensed users. AI complicates that approach because two users can generate vastly different amounts of computational work. The value they receive may also have little relationship to how many people access the application.

These differences are pushing vendors toward meters based on tokens, completed tasks, and business results. Established SaaS companies are also adopting hybrid models that combine existing seat licenses with additional AI entitlements. This allows them to charge for AI activity while preserving the subscription agreements their customers already use.

Bain identified this direction in an earlier Brief, “Per-Seat Software Pricing Isn’t Dead, but New Models Are Gaining Steam,” published last fall. Its subsequent research reinforces the finding that seat licensing remains commercially relevant even as AI changes the relationship between software costs and customer value.

Much of the confusion comes from pricing terminology. Vendors describe products as usage-based, consumption-based, or outcome-based, although these labels can refer to different billing arrangements. Some products marketed around outcomes charge for completed activities, while many usage-based offerings require customers to purchase capacity in advance and pay extra when they exceed their allowance.

For buyers, these differences determine how predictable spending will be and what happens when consumption falls short of expectations. For vendors, they affect revenue stability, cost recovery, and exposure to changes in customer usage. Evaluating AI pricing therefore requires separating the unit being charged from the commitment governing its purchase.

The first decision: charge for effort, output, or outcomes

The first pricing decision is what activity should generate a charge. Bain identifies three main approaches: effort-based, output-based, and outcome-based pricing. Each measures a different aspect of what AI delivers and creates a different relationship between vendor compensation and customer value.

Among AI-native companies and established seat-based SaaS vendors introducing hybrid AI meters, output-based pricing is the most common.

These percentages describe the specified AI-native and hybrid-pricing population. Bain also finds little meaningful difference between AI-native companies and established SaaS vendors in their choice of meters. The more useful distinction is what customers purchase and where the software operates in their workflow.

Effort-based pricing measures resource consumption

Effort-based pricing ties charges to the technical resources an AI system consumes. Common units include tokens, which are pieces of text processed or generated by a model; compute, meaning the processing resources required; and agent hours, which measure how long an AI agent operates.

For infrastructure providers, these units relate directly to the service delivered. A customer consuming more processing resources generates more billable activity, making technical usage a practical basis for pricing.

The approach also works for vendors offering broad portfolios of AI capabilities. Different applications may produce entirely different outputs, making a shared definition of completed work difficult to establish. Resource consumption provides a common measure across those activities.

Vendors can simplify billing by converting technical consumption into credits or monetary units, such as dollars. Customers then manage spending through a shared unit instead of tracking separate measures for every capability. This gives vendors a consistent way to price new AI functions as their portfolios expand.

However, resource consumption and customer value can diverge. Two operations using similar amounts of compute may produce very different business benefits. Effort pricing therefore gives vendors a measurable way to recover delivery costs while leaving customers to judge whether the resulting work is worth the expense.

Output-based pricing measures completed work

At the application level, customers often understand the work they want completed more easily than the computing resources it requires. Output-based pricing addresses this by charging for identifiable units of work.

A marketing application might charge for generated drafts or recommended leads. A document-processing product could charge for summaries, while an enterprise automation tool might bill according to the number of records updated.

Business buyers can understand these units because they describe something the software has delivered. A customer can evaluate the cost of producing a summary or updating a record without knowing how many tokens the operation consumed.

Output pricing is particularly suitable for focused applications with clearly defined deliverables. It also lets vendors manage their internal AI costs separately from customer-facing prices. If a vendor reduces the resources needed to generate an output, its delivery costs fall while the billable unit stays the same.

That gives vendors an incentive to improve efficiency. But completing the work does not guarantee that the customer gets the result they wanted.

A system might recommend a sales lead that never meets the customer’s qualification requirements. The recommendation is an output; a qualified lead represents an outcome. Similarly, updating a database record is a completed activity, while finishing the broader business process that depends on the update represents a different level of achievement.

This distinction determines who bears the consequences of ineffective work. Under output pricing, the vendor earns compensation when the agreed activity is completed. The customer primarily carries the risk that the output is inaccurate, unusable, or commercially unproductive.

Outcome-based pricing measures business results

Outcome-based pricing ties vendor compensation to an agreed business result. Examples include successfully resolving a customer support issue, recovering value associated with fraud, or collecting outstanding revenue.

With this approach, producing intermediate work is insufficient unless it leads to the contracted result. A vendor’s revenue therefore depends more directly on whether the customer achieves the specified objective.

That connection can bring pricing closer to the value customers believe they receive. It also transfers more risk to the vendor because payment may depend on factors beyond the AI system’s immediate activity.

The three meters consequently suit different products. Infrastructure services often favor effort because customers purchase technical resources. Focused applications can favor output because customers purchase recognizable work. Outcome pricing becomes attractive when vendors and customers can agree on a measurable business result.

Reaching that agreement is the central challenge.

Why Outcome-Based pricing works for some AI products

Outcome-based pricing appeals to customers because payment depends on achieving something valuable. For vendors confident in their product’s effectiveness, it offers a way to connect compensation more closely to business performance.

Yet adoption remains limited because the model faces practical constraints. AI can generate measurable activity without producing results that both parties can reliably use to calculate payment. Bain identifies three conditions that outcome-based pricing must satisfy.

All three matter because business results often depend on several systems, employees, and external factors. A result may be easy to measure while its causes remain difficult to separate. Without agreement on attribution, the vendor and customer can dispute which results should generate charges.

Customer support offers measurable outcomes

Customer support is one of the clearest applications because individual interactions often have identifiable resolutions. When an AI agent handles an inquiry, the vendor and customer can frequently determine whether the issue was resolved. This creates a measurable event around which to establish pricing.

Zendesk, Sierra, and Fin use resolution-oriented pricing for customer support interactions. Decagon also offers outcome-based pricing alongside an output-based alternative.

These companies sell AI customer support capabilities, so their pricing models directly affect how they earn revenue from customer interactions. Resolution-based charging can connect their compensation to successful service, while output-based alternatives allow payment to depend on completed activity.

Decagon’s two approaches illustrate how the same application category can support different definitions of billable work. Depending on the agreement and customer preferences, a vendor might charge for an interaction handled or an issue successfully resolved.

The difference becomes important when an AI system completes its assigned activity but leaves the customer needing further assistance. An output meter can generate a charge for the completed interaction. A resolution-based agreement instead makes the definition of success central to payment.

Transaction risk and financial workflows offer other possibilities

Outcome pricing also becomes possible when software operates close to a measurable financial event. Riskified provides an example from transaction risk management.

Riskified guarantees approved transactions against chargebacks and receives compensation calculated as a percentage of approved orders. Its pricing connects fees to defined transaction activity, while the guarantee makes financial risk protection central to the customer’s purchase decision.

The company has a commercial interest in this model because transaction-linked compensation determines its revenue. The guarantee also means its economics depend on the relationship between fees received and the chargeback exposure it assumes.

HighRadius is experimenting with pricing tied to business results in accounts receivable automation. In that setting, compensation can be linked to financial processes rather than individual AI activities performed along the way.

HighRadius also has a commercial interest in demonstrating that its software creates measurable business value. Outcome-related pricing can strengthen that proposition when customers can connect improvements in accounts receivable performance to the product’s contribution.

These examples show how outcome-oriented agreements can work across different applications. Wider adoption depends on whether results remain measurable and attributable across customers with different processes.

Complex workflows make attribution difficult

Attribution gets harder when AI contributes to a result alongside several other activities. Marketing illustrates the problem.

An AI application might generate campaign material, recommend audience segments, or optimize targeting decisions. Revenue generated by the campaign can also depend on brand recognition, pricing, distribution, market conditions, and the sales team’s work.

Even when campaign revenue is observable, the buyer and vendor may disagree about how much the AI system contributed. This makes it difficult to determine what the vendor should receive.

HR workflows create similar problems. A hiring decision may involve applicant-tracking software, AI screening, interviews, management judgment, and several approval stages. The final decision is observable, but isolating the contribution of one AI application can be difficult.

Software engineering presents another measurement challenge. AI tools can generate code, suggest fixes, and assist developers, yet consistently measuring the resulting productivity improvement remains difficult.

Across these workflows, collecting technical usage data solves only part of the problem. Vendors also need an agreed definition of business success and a defensible way to connect that success to their software.

Outcome contracts create operational costs

Attribution becomes a contracting problem when compensation depends on the measured result. Vendors and customers may need to negotiate qualifying events, measurement methods, exceptions, and responsibility for outcomes.

Those terms must then be built into billing systems. Each agreement needs rules for determining which events qualify for payment and how the charges are calculated.

Administration grows more demanding as the customer base expands. Organizations with different processes may require different definitions of success, creating variations that the vendor must manage consistently.

Outcome pricing also increases the vendor’s exposure to the customer’s operating environment. If payment depends on completing a business process, weaknesses elsewhere in that process can reduce vendor revenue even when the AI system performs its assigned work.

These constraints help explain why Bain expects outcome-based pricing to remain relatively limited over the next several years. The model can work when results are observable, attributable, and contractible. More capable AI alone cannot remove the need for reliable measurement and enforceable agreements.

The second decision: direct consumption or committed capacity

Once a vendor chooses what to measure, it must decide how customers purchase the measured activity. The same effort, output, or outcome meter can support two different purchasing structures.

Under direct consumption, customers pay according to actual activity. Under committed capacity, they purchase an allowance covering an agreed quantity of activity, whether or not they eventually use it.

Bain finds that approximately four out of five vendors introducing AI pricing choose capacity-based arrangements. This finding concerns purchasing commitments, while the earlier percentages describe pricing meters.

The distinction explains why AI-specific usage measures have spread faster than changes to enterprise purchasing economics. Vendors can introduce new billable units while continuing to receive revenue through contracts agreed in advance.

Direct consumption makes spending follow activity

Under direct consumption billing, customers pay for the quantity they use during the billing period. If an AI application charges for generated summaries, the bill reflects the number produced. If an infrastructure service charges for tokens, spending changes with the quantity processed.

This ties utilization closely to payment. Customers with variable demand can increase or reduce consumption without purchasing a fixed allowance that may exceed their needs.

The approach also makes the marginal cost of additional activity visible. Marginal cost is the extra expense created by performing one more unit of work. A product or engineering team can see how another workload affects spending and adjust its use accordingly.

But that flexibility brings financial uncertainty. When consumption rises unexpectedly, expenditure increases with it. Enterprise buyers may struggle to approve budgets before they know how much AI their organization will use.

The problem grows when an application spreads across many teams or enters workflows with variable activity levels. An organization might know the price per task while remaining uncertain about its annual spending.

Finance teams must then plan for expenditure that changes with operational demand. This uncertainty can slow procurement, particularly when buyers need advance spending approval.

Direct consumption remains important for infrastructure software and technically oriented buyers. These customers often have strong reasons to connect spending to resource use and may already have the tools needed to monitor consumption.

For enterprise applications with less predictable adoption, committed capacity offers another way to manage uncertainty.

Capacity pricing establishes an allowance

Under capacity pricing, customers commit to purchasing a defined quantity of AI activity or resources. The entitlement may be expressed in credits, usage units, or another allowance linked to the product’s meter.

Customers draw down that allowance during the agreed period, with additional activity potentially subject to overage charges. The defining feature is that the committed payment remains due even when actual consumption falls below the purchased quantity.

Unused capacity does not automatically carry forward or generate a refund. The vendor therefore receives the agreed payment even when the customer uses fewer units than expected.

Consider an application that charges according to the number of AI tasks completed. With direct consumption pricing, expenditure follows the tasks actually performed. Under capacity pricing, the customer purchases an allowance covering an agreed volume of tasks.

If the customer completes fewer tasks than the allowance covers, the committed payment stays the same. If demand exceeds the allowance, the contract may permit additional paid consumption.

Both agreements use the same output meter. Their economics differ because one charges for actual activity while the other establishes a purchase commitment.

This is how software described as usage-based can retain subscription-like revenue characteristics.

Enterprise buyers value predictable commitments

Capacity pricing appeals to procurement teams and CFOs because it establishes a defined financial obligation. Buyers can compare the cost of an AI deployment with an approved budget and see how much the organization has committed to spend.

That predictability matters when consumption is hard to forecast. Employees may adopt applications at different rates, workflows may expand, and individual users may generate substantially different levels of demand.

A fixed allowance gives the purchasing organization control over its initial commitment. It also fits established enterprise procurement processes built around negotiated contracts, spending approvals, and planned software budgets.

For buyers, the benefit comes with a utilization risk. When an organization purchases more capacity than it consumes, the effective cost per unit of actual usage increases.

An allowance that appears economical at the expected activity level can become expensive when adoption is lower than anticipated. Customers therefore need to forecast demand carefully and monitor utilization after deployment.

This creates a trade-off between budget certainty and paying for unused entitlements. The contract fixes the initial obligation, but the value of that purchase still depends on how much useful activity occurs.

Vendors benefit from committed revenue

The same purchasing structure offers software providers a different advantage. Direct usage revenue changes with customer activity, so lower consumption reduces the corresponding payment.

Capacity commitments establish revenue obligations in advance. The vendor receives the committed amount even when the customer consumes less than expected.

This preserves an important feature of traditional enterprise software economics. Under seat licensing, customers purchase access for a specified number of users. Some licenses may remain unused, or employees may use the software infrequently, but the contractual payment generally stays in place.

Capacity-based AI pricing applies the same principle to a different entitlement. Customers purchase the right to consume a specified amount of AI activity rather than access for a fixed number of people.

The billable unit changes while the vendor retains the ability to collect revenue from allowances customers do not fully use.

The result is an economic asymmetry. Customers carry the cost of unused capacity, while vendors retain the associated payment.

This helps explain the prevalence of capacity arrangements. They combine AI-specific measurement with a committed-revenue model that enterprise software providers already understand and have a financial incentive to preserve.

Buyers also have reasons to prefer the structure because it simplifies budgeting. But the interests of the two parties differ: vendors benefit from payment certainty, while customers must weigh that certainty against the possibility of unused capacity.

The popularity of these agreements therefore reflects their fit with established enterprise purchasing practices and vendor revenue models. It does not establish that they necessarily produce better customer outcomes, higher retention, or greater profitability.

Major software vendors already use capacity models

Capacity pricing appears in several established software products. These examples show how vendors can introduce AI-specific charges while retaining commitments familiar to enterprise buyers.

Atlassian Rovo uses AI credits, allowing customers to purchase access to a defined quantity of AI activity. ServiceNow Now Assist uses predefined AI entitlements, connecting purchases to allowances for its AI capabilities.

Adobe Firefly similarly uses credits to govern access to AI generation. The commercial units differ, but each allows AI consumption to be managed through a defined entitlement.

Atlassian, ServiceNow, and Adobe all have a commercial interest in how these allowances are structured because they sell the underlying products. Capacity-based purchasing can give them more predictable revenue while allowing customers to plan spending.

Credits and entitlements also offer a way to introduce AI-specific pricing alongside existing software contracts. A company can retain seat-based subscriptions for core application access while adding an allowance for AI activity.

This hybrid approach accommodates changes in AI costs and consumption without requiring a complete redesign of the customer agreement. It also lets vendors charge separately for AI operations that create meaningful incremental expenses.

For established SaaS providers, that separation can be particularly useful. Conventional application functionality may continue to deliver value through user access, while AI capabilities introduce additional resource consumption or completed work.

The resulting contract can contain several pricing components while maintaining a defined financial commitment. Buyers gain a way to budget for AI, and vendors can recover AI-related costs through a separate entitlement.

The purchasing decision determines financial exposure

Choosing between direct consumption and capacity requires understanding which uncertainty matters most to the customer.

Direct consumption ties payments closely to actual activity. It can work well when demand varies, resource use is measurable, and buyers can manage expenditure that changes over time.

Capacity establishes a predictable commitment. It can suit customers whose procurement processes favor defined budgets and whose expected consumption is stable enough to support an allowance.

Each structure leaves a different risk. Direct consumption exposes customers to unexpected increases in activity, while capacity exposes them to inaccurate forecasts and unused entitlements.

These risks exist regardless of the underlying meter. An effort-based product can use either purchasing structure, and the same applies to output-based and outcome-based pricing.

The meter determines what generates a charge. The purchasing structure determines how much customers commit to buying and how actual utilization affects their costs.

This independence matters when comparing AI products. Two vendors advertising usage-based pricing may charge for different activities, require different commitments, and allocate financial risk in substantially different ways.

The right AI pricing model depends on both decisions

For software executives, the practical starting point is determining whether AI has changed the product’s economics enough to justify a pricing adjustment.

Bain identifies two questions that help establish the need for change:

1. Does AI materially change how customers receive value from the product?
2. Does AI introduce substantial marginal costs as the software performs more work?

Either condition can justify reconsidering the existing pricing model.

A product that continues to deliver value primarily through user access may retain seat pricing. An application where AI creates substantial additional work or resource consumption may need a separate meter, potentially layered onto the existing subscription.

Once the need for change is clear, the next question is what activity should generate a charge.

Match the meter to the value delivered

For infrastructure products and broad AI portfolios, effort-based pricing can provide a consistent measure across different capabilities. Customers purchase processing resources, and vendors can connect charges to the underlying consumption.

For focused applications, identifiable outputs may correspond more closely to what customers recognize and purchase. Generated drafts, summaries, recommended leads, and updated records are examples of work that buyers can count and evaluate.

Outcome pricing deserves consideration when the business result can be measured, attributed specifically to the AI system, and incorporated into an enforceable agreement.

That evaluation should include the cost of operating the pricing model. A result that appears easy to measure in a demonstration may require complicated contract terms or billing procedures across enterprise customers with different workflows.

Vendors also need to consider how much control they have over the result. The more an outcome depends on customer processes, employees, or external conditions, the greater the vendor’s exposure to factors outside its software.

A pricing meter should therefore reflect the product’s role in creating value while remaining practical to measure, explain, and administer.

Match the commitment to customer purchasing needs

Once the meter is established, vendors must determine how customers will purchase its units.

Direct usage aligns activity closely with expenditure. Committed capacity establishes a defined spending obligation for buyers and a more predictable revenue commitment for sellers.

The choice should reflect customer purchasing preferences, expected consumption patterns, budget requirements, and the consequences of unused allowances.

A buyer with variable demand and strong usage controls may prefer direct billing. An enterprise with formal spending approvals may find an agreed allowance easier to purchase, even when consumption remains uncertain.

These decisions must also reflect the vendor’s cost structure. AI capabilities with substantial marginal costs require careful attention to consumption, regardless of whether customers purchase units directly or through committed capacity.

For example, an output-based application may charge customers a fixed amount for each completed task while incurring variable model-processing costs. If usage increases or the cost of producing an output changes, the vendor must ensure its pricing continues to cover delivery expenses.

Capacity agreements introduce another consideration. A vendor receives committed revenue in advance, but customers may consume their allowances at different rates. The vendor must therefore understand how the cost of delivering purchased capacity compares with the revenue attached to it.

Evaluate the economics behind competitor pricing

Competitor pricing labels offer limited guidance because similar descriptions can conceal different financial arrangements.

Two products described as usage-based may employ different meters, require different commitments, and expose customers to different spending risks. Comparing only the advertised unit price can therefore miss the effective cost of using the software.

For buyers, that effective cost depends partly on utilization. A capacity agreement with an attractive price per unit can become less economical when much of the allowance remains unused.

For vendors, the calculation also includes the cost of producing each billable unit. Effort, output, and outcome meters expose providers to different levels of delivery cost and performance risk.

Software leaders evaluating a new pricing model should therefore examine expected activity, delivery costs, contractual commitments, and the ability to measure what customers receive. These factors determine whether the agreement remains sustainable as adoption changes.

The practical test comes after deployment, when customers begin consuming AI at rates that may differ from their forecasts. Vendors need to track the relationship between billable activity and delivery costs, while buyers need to monitor actual utilization against purchased entitlements.

Those measurements provide the basis for adjusting allowances, overage terms, and future commitments. They also reveal whether the chosen meter continues to reflect the work customers value as AI becomes a larger part of the product.

Recap

AI is changing what software vendors charge for, but not necessarily how customers pay. As pricing moves beyond traditional seat licenses toward resource consumption, completed work, and business outcomes, committed capacity remains the dominant purchasing model. This allows vendors to monetize AI activity while preserving predictable revenue, but it also places greater responsibility on buyers to manage utilization and avoid paying for unused allowances.

For CEOs, CTOs, and other technology leaders, the distinction between pricing meters and purchasing commitments is increasingly important. A usage-based product does not automatically mean customers pay only for what they consume. Similarly, outcome-based pricing does not guarantee a closer connection to business value unless results can be measured, attributed, and incorporated into contractual terms.

The priority for enterprise buyers is to understand how each pricing structure affects total software spending, operational flexibility, and financial risk. For software vendors, the challenge is to establish pricing that reflects customer value, covers AI delivery costs, and supports sustainable revenue as adoption grows.

The broader shift is not simply from seats to usage or outcomes. It is toward pricing models that must account for both the work AI performs and the financial commitments customers are willing to make. Organizations that evaluate these decisions separately will be better positioned to negotiate software agreements, forecast AI spending, and capture value as AI becomes embedded in enterprise operations.