AI Pricing Models: Bundle, Add-On or Usage Credits for Software Teams

The seat was a convenient proxy because human users were the unit of consumption. AI changes that. When an agent resolves a support ticket or drafts a contract, the value created has little to do with how many people hold a licence. BCG's buyer survey found that 40% of buyers cite seat reduction as their primary lever to decrease software spending, which tells vendors that customers already see the seat count as the thing to attack when budgets tighten.

Analysts see the exposure at scale. Gartner projects that agentic AI could put up to $234 billion of application software spending at risk by 2030, with the exposed spend accounting for about 20% of enterprise software-as-a-service. Whether or not that forecast proves precise, the direction matters to a product leader: if customers can do the same work with fewer human seats, a pricing model anchored on seats makes the vendor poorer exactly when the product works best.

Vendors are responding with a spread of experiments rather than a consensus. Intercom lists its Fin agent from $0.99 per outcome with no seats required. Salesforce lists Agentforce conversations at $2 per conversation, alongside user licences and credit packs. Microsoft lists its Microsoft 365 Copilot Business add-on at $18 per user per month paid yearly, originally $21, which keeps the seat but separates AI as an add-on. These are list prices at a point in time and will change, but together they show the range of units in play.

Procurement behaviour differs by region, and it will shape how this plays out. Buyers in the United States tend to negotiate enterprise agreements with committed spend; European buyers often add data-protection and employee-consultation scrutiny to anything that monitors work; Gulf buyers frequently prefer a single accountable vendor and clear fixed commitments. Those are generalisations rather than measured differences, but they argue for a price book with a stable core and regional flexibility in packaging, rather than a single global construct imposed everywhere.

What to do: do not abandon seats overnight. Audit how your AI features change the relationship between seats and value for each customer segment. Where AI mainly helps a person work faster, a seat-based add-on may still be coherent. Where AI replaces tasks, a unit tied to the work done will track value better. Record which segments are in which category before choosing a model, because one price book rarely serves both.

McKinsey's analysis of pricing models and success metrics from 150 global vendors, both incumbent SaaS players and AI natives, identifies four families of pricing metric: flat fee, successful outcome, activity consumption and capacity. We use those four families as the working vocabulary in this article. We deliberately do not quote the vendor-by-vendor percentage split that McKinsey plots for them, because those shares appear only in a chart image on its page and not in published text; the verifiable evidence for the direction of travel is below.

McKinsey finds that only 16% of SaaS incumbents have commercialised AI applications as stand-alone products. In other words, most incumbents still treat AI as a feature inside an existing price, while AI-native competitors price the capability directly and meter it. McKinsey also cites an AI-native sales-development company where 90% of customers opted for activity-based pricing when offered a choice, which suggests that buyers will accept metering when the unit makes sense to them.

Incumbents also have a structural reason to move slowly: a flat fee is easy to forecast, to sell and to renew. But the ICONIQ Capital survey cited by BCG reports that 68% of vendors now charge separately for AI enhancements or include them only in premium tiers. The market is therefore not choosing between pure bundle and pure meter. It is choosing a layered structure in which a base subscription is complemented by separately priced AI capacity. Buyer appetite adds a further constraint. In a January 2025 Gartner poll of 3,412 webinar attendees, 19% said their organisation had made significant investments in agentic AI, 42% had made conservative investments, 8% none, and the remaining 31% were taking a wait-and-see approach or were unsure. Most buyers are therefore still testing, which favours pricing that is capped and easy to forecast.

A further difference is how quickly AI natives learn. A vendor that meters activity from the first day collects a clean record of how often each feature is used, by whom and at what cost. An incumbent that bundles AI into a flat fee learns about demand only indirectly, through adoption surveys and renewal conversations. Metering, even when it is not billed, is therefore valuable as a research instrument. We suggest that every incumbent instruments its AI features in the same way before deciding how to charge.

What to do: place your own price book on McKinsey's four metric families, flat fee, successful outcome, activity consumption and capacity, and identify the share of your revenue in each. Then do the same for your two closest AI-native competitors. If a rival prices the equivalent capability by activity while you give it away in a flat fee, you are subsidising their buyers' comparison, and the gap will show up first in price-sensitive deals.

Traditional software has near-zero marginal cost per user action. AI does not. Each model call consumes compute, and the volume of calls depends on customer behaviour and on how the product is designed. Bessemer's analysis of AI start-ups found that its fast-scaling 'Supernovas' average only about 25% gross margin, often trading margin for distribution, while its 'Shooting Stars' average about 60%. Margin is a design variable, and pricing is one of the main levers.

Unit costs are falling quickly. The Stanford HAI AI Index reports that the cost of querying a GPT-3.5-level model fell from $20 per million tokens in November 2022 to $0.07 by October 2024, and McKinsey notes that large language model delivery costs have declined by more than 80% per year over the past two years. It is tempting to conclude that cost can be ignored. That would be a mistake, because falling prices per token are routinely offset by longer contexts, more capable models and agents that call tools repeatedly.

The buyer side shows the same tension. McKinsey's 2026 survey reports that about 20% of respondents said AI-related operating costs, including token costs, constrained their AI use. Customers who cannot predict their own bill reduce usage or push back on vendors. Cost variability therefore damages both sides: the vendor's margin and the customer's willingness to adopt widely. A pricing model has to make costs legible to the buyer while keeping the vendor's cost curve below the revenue curve.

Engineering choices change the cost curve more than most pricing teams realise. Routing simple requests to smaller models, caching repeated queries, limiting context length and constraining the number of tool calls an agent may make can reduce cost per action substantially without touching quality for most users. Product and engineering leaders should treat these as pricing levers: every point of margin recovered through architecture is a point that does not have to be recovered from customers through a higher price or a tighter cap.

What to do: before pricing, measure the cost to serve for each AI feature at the 50th, 90th and 99th percentile of customer usage. If the heaviest users cost many times the median, a flat add-on will transfer margin from you to them. Build a simple model that shows gross margin by customer cohort under each candidate price, and refuse to launch a model whose heavy-user margin is negative without a cap or meter.

A bundle works when the feature improves the core product for everyone, usage per customer is bounded and the cost to serve is small. It is also the right choice while you are still learning what customers value, because it protects adoption data. The cost is that you forgo revenue from heavy users and may train customers to expect AI at no extra charge. Bundle to defend the core, not to avoid a pricing decision.

A separately priced add-on works when AI delivers distinct value to an identifiable group of buyers and can be sold as an upgrade. The ICONIQ survey cited by BCG reports that 68% of vendors take this route or restrict AI to premium tiers. The risk is the one Microsoft and Salesforce lists illustrate: a flat per-user add-on cannot reflect enormous differences in usage, and Salesforce's own list shows per-user prices ranging from $5 to $550 per user per month across its Agentforce licences and editions.

Usage credits work when value scales with consumption and cost scales with it too. They let the vendor sell a modest entry price, collect more from heavy users and keep margin under control. The cost is complexity: customers must understand what a credit buys. Salesforce, for example, lists Flex Credits at $500 per 100,000 credits, with one action priced at US$0.10, equivalent to 20 credits. The unit is the product's own action, not a token, which is easier for a buyer to plan around.

Packaging also communicates strategy. A visible AI tier signals that the company is investing and gives sales a premium story; a quiet bundle signals that AI is table stakes. Both can be right at different times. A reasonable sequence for many products is to launch AI inside a premium tier with an allowance, observe usage for two or three quarters, and then decide whether to extend it to the base tier, split it into add-ons or move to credits. Each step should be announced with notice, so that existing customers are not surprised.

Consider a hypothetical example with no vendor attached. A document-processing feature costs the vendor a few units of compute per page. A flat add-on priced for the average customer leaves the largest accounts, who process far more pages, paying the same fee for many times the cost. Moving to an allowance of pages with a modest overage rate preserves a simple entry price, keeps the heaviest users profitable and gives customer success a natural moment to discuss expansion when an account approaches its limit.

What to do: use the decision table in the exhibit below as a starting point. Ask four questions of each AI feature: who gets value, does value scale with use, does cost scale with use, and can the customer attribute results to a countable unit? Features that are broad and cheap should be bundled. Features that are valuable to a segment should be add-ons. Features with high variance in use and cost should carry credits or caps.

Outcome pricing is the most intuitive answer to the question of value: charge only when the agent succeeds. Zendesk, according to McKinsey, charges $1.50 per successfully resolved customer interaction, and Intercom lists Fin from $0.99 per outcome. These models are credible because a resolved conversation is a clear, countable event that the buyer would also record. For a support leader, the unit maps directly to cost per contact.

The barriers appear when the outcome is less clear. In an Andreessen Horowitz survey cited by BCG, 47% of buyers said they struggle to define clear, measurable outcomes, 36% worry about cost predictability, 25% face difficulty aligning on value attribution with vendors and 24% acknowledge that outcomes often depend on factors outside the vendor's control. Together, these figures describe a negotiation burden that many software teams are not set up to carry.

There is also a revenue-quality issue. Outcome fees are variable and can swing with the customer's own volumes, so forecasting becomes harder. McKinsey's own examples of outcome pricing, such as Zendesk's $1.50 per resolved interaction, remain the exception rather than the rule. The conclusion we draw is not that outcome pricing is a fad but that it is a late-stage model, best applied where the definition of success is stable, auditable and agreed in the contract.

Two practical variants sit between pure outcome pricing and pure activity pricing. A shared-risk structure charges a modest platform fee plus a per-outcome fee, so the vendor is protected against low volumes and the buyer pays more only when value arrives. A guarantee structure bills on activity but credits a defined share back when the agent misses a stated service level. Both ease the attribution debate by limiting the amount at stake in any single disagreement, and both are easier to explain to a finance committee than an open-ended share of benefit.

What to do: test whether your outcome passes four tests. It must be a single event that both sides can see. It must be attributable to your product rather than to the customer's other actions. It must be definable in a contract without extended debate. And it must be worth enough to the customer to justify a per-event fee. If it fails any of them, use activity pricing, with credits, and revisit outcome pricing once the data is clearer.

Most real-world AI price books combine models. A base subscription provides access and a baseline allowance. Beyond it, customers buy credits or pay by activity, perhaps at a declining unit price as volume rises. A commitment tier lets large accounts pre-purchase capacity at a discount. This hybrid structure answers the buyer concern about unpredictable costs while allowing the vendor to align revenue with the cost of delivery.

Predictability is not a minor detail. BCG's survey of IT buyers found that 91% expressed interest only in partially autonomous agents, which signals that buyers want to keep human control over what the software does and, by extension, over what it costs. A credit balance that can be seen, topped up, capped and forecast fits that preference far better than an uncapped bill arriving at month end.

Design details determine whether credits help or irritate. A credit should correspond to an action the buyer understands. The conversion between credits and money should be stated plainly. Customers should see usage by team and feature in real time, receive alerts before they reach limits, and be able to set their own caps. Rollover rules should be simple. A well-designed credit system turns usage data into a shared planning tool rather than a source of disputes.

Finance and legal details are easy to overlook. Prepaid credits may be recognised as revenue only as they are consumed, which affects reported results and cash. Expiry and refund terms vary by jurisdiction and can attract contractual challenge. Multi-currency price books need a policy for exchange-rate changes, and customer data used to meter usage must be handled within data-protection rules. None of this is a reason to avoid credits, but it is a reason to involve finance and legal from the first design session, and to take professional advice where needed.

What to do: write a customer-facing explanation of your pricing in under 200 words and test it with five buyers. If any of them cannot calculate a plausible annual cost for their own use, simplify the unit or add a calculator. Then design the usage dashboard before launch. Product, finance and customer success should all be able to read the same numbers, because the first renewal conversation will turn on them.

In the first thirty days, build the cost and value baseline. Instrument each AI feature to record usage, model cost and customer outcome by account. Interview a dozen customers about the unit in which they think about value. Map your features onto the decision table and propose a default model for each. The output is a one-page recommendation per feature, with the evidence for it and the unit-economics model behind it.

In days thirty to sixty, test willingness to pay and behaviour. Offer two structures to comparable cohorts, for example a bundled allowance versus a credit model, and compare adoption, expansion and support volume. Use the preview period to find the fair-use boundary rather than guessing it. Keep legal and finance involved so that contract language, revenue recognition and tax treatment of credits are settled before they become a commercial issue.

In days sixty to ninety, prepare the launch and the guardrails. Set caps and alerts, write the customer explanation, train sales and success teams, and define the exceptions process for large accounts. Agree the review cadence: monthly margin by cohort and quarterly review of price points. Most important, fix a date at which the model will be revisited, since cost curves, competitor offers and customer expectations will all change within a year.

Governance after launch keeps the model honest. Appoint a small pricing council with product, finance, sales and customer success. Give it a short monthly dashboard: gross margin by AI feature, share of accounts above their allowance, discounting rates, expansion revenue and complaints about bills. Decide in advance what would trigger a change, for example a feature whose heavy-user margin turns negative or an allowance that three-quarters of accounts never reach. Pre-agreed triggers turn arguments about opinion into decisions about evidence.

What to do: assign one accountable owner for AI monetisation, usually in product with a finance partner, and make gross margin by AI feature a standing item in the product review. The target is not the highest possible price. It is a price structure that customers can understand, that scales with value created and that leaves the company with a sustainable margin when usage grows faster than expected.

Karter McKinley's Strategy & Transformation work helps product and finance teams build the unit-economics model, test two or three price structures with customers and set the governance for reviewing them. We work with your data and avoid prescribing a single model before the evidence is in.