What Is Outcome-Based Pricing? Whose Outcome ‘Pay When the Task Is Complete’ Bills For

TL;DR: Outcome-based pricing means the vendor shares risk in the customer’s realized result, so revenue rises and falls with whether that result lands. Pricing per completed agent task is consumption relabeled, not an outcome. To choose a value metric you can defend, name it in the customer’s terms and keep it close enough to their result that they keep paying for it.

A growing number of AI vendors price per completed agent task and market it as outcome-based pricing. The label is doing more work than the mechanism supports. A completed task is a unit of work the vendor defines and controls. A business outcome is the result the customer realizes in their own operation. Those are not the same thing, and the gap between them decides who carries the risk when the value does not land.

Outcome-based pricing is a value metric tied to the customer’s realized business result, structured so the vendor carries part of the risk when that result does not materialize. The term is being stretched in the current AI wave, and the objection a sharp buyer will raise doubles as a design criterion you can use before you ship your own price. Well-built consumption pricing is often the right model. The issue is the label, and what it hides from you when you are setting the price.

What outcome-based pricing actually means

This is a choice about what the meter counts, not a separate pricing model. It sits inside the licensing decision that anchors the rest of your pricing architecture: you charge against the business result the customer achieves, such as deals closed or conversations resolved, rather than the seats they license or the actions your software performs.

Shared exposure is the defining feature

Genuine outcome pricing has one defining feature: shared exposure. You charge a fraction of the value the customer captured, or per unit of work that stayed resolved for a defined window, so your revenue rises and falls with whether the customer’s result materialized. Strip out that shared exposure and you no longer have outcome pricing, whatever the marketing says.

Why “outcome” is a family of metrics

An outcome is not one metric but a family of potential metrics, and the abstract idea is too imprecise to count or invoice against. A move becomes outcome-based only once a specific, countable result is named, close enough to the customer’s own result that they recognize the value: qualified leads that entered the sales process, tickets that stayed resolved, fraud avoided. Until a specific instance is named, “priced on outcomes” is a category label rather than a value metric. The difference between a pricing model and a value metric is exactly where this is lost.

Usage-based vs outcome-based pricing: who carries the risk

Consumption pricing charges for a defined unit the customer consumes, an API call, a credit, a completed task, and the customer pays whether or not value results. Outcome-based pricing charges for the realized business result, so your revenue moves with the customer’s success.

Why “pay per completed task” blurs the line

The column that blurs is the last one. When you charge per completed task and call it an outcome, you are still defining the unit in your system’s terms and still collecting whether or not the customer achieved the result. Naming it “outcome” changes the language, not the risk. The credits-versus-resolutions comparison works through this at the metering layer; here the question is narrower: not which meter is better, but whether either one is actually pricing an outcome.

The River of Value: where you gate the flow

Software Pricing Partners uses a metaphor for this, the River of Value. Value is rain on a mountain, the product’s capability, and it coalesces into a river that exits into the customer’s fields, their business operations. The value metric is the point where you gate and count the flow. Pricing on activity gates it high on the mountain, near the rain; pricing on the customer’s realized result gates it far downstream, in the customer’s fields, where you take a share of their harvest and have to defend that the share is fair.

A short history of outcome-based pricing

Outcome pricing has a real lineage, and the current usage stretches it. Its roots are in professional services, where firms were paid on results delivered rather than hours worked: performance fees, gain-share arrangements, success fees paid when a deal closed. The instinct was sound, tying the fee to what the client received rather than the labor spent.

The Lehman formula and its two flaws

The typical structure of that era was the Lehman formula, a declining percentage taken on transaction value and paid at close. In practice it collapsed to a crude schedule with a few entries, a blunt percentage-of-value instrument rather than a designed model that varies price across the dimensions that drive value. So the classic outcome model carried two flaws from the start: its attribution was contestable, and its construction was primitive.

When consulting tested outcome fees at scale

The consulting industry ran the attribution experiment at scale. Through the 1990s and 2000s, large integrators tried to charge on engagement outcomes, revenue uplift, cost reduction, shareholder-value delta, and watched clients dispute attribution line by line whenever the invoice crossed a meaningful threshold. The same dynamic is now playing out with outcome-based software pricing.

In the outcome-based engagements I worked on early in my career in Big Four consulting, the pattern was the same every time. The model sounded great at signing. Once the value materialized, the client’s incentive flipped, and they argued the outcome down and suppressed the measured result so the invoice shrank. The failure was not greed. The outcome had been defined as value expressed in dollar increases, a financial result that sits far into the customer’s field. At that distance the client’s own labor, their market conditions, and every other contributor fed the same number, so the value streams commingled and our contribution could not be cleanly isolated. The client could legitimately claim the harvest was theirs.

The River of Value rule, made concrete

That is the River of Value rule made concrete: the further downstream the outcome metric, from financial to deal to operational, the more value streams commingle and the more contestable the attribution becomes. Pick a metric close enough that the buyer recognizes the value but attributable enough that your contribution is not commingled with everyone else’s. The design-side treatment of outcome pricing walks the metric ladder for a vendor building this deliberately.

What AI vendors are calling “outcomes”

The current AI-agent wave puts the label on per-task billing. HubSpot’s Breeze Agents bill per recommended lead for the prospecting agent and per resolved conversation for the customer agent, framed on HubSpot’s own product pages as paying when the task is complete. Salesforce prices Agentforce on Flex Credits and leans on outcome language in how it positions the product.

Report this faithfully. HubSpot’s price sheet is plain consumption pricing, and there is nothing dishonest in it. A charge per recommended lead and per resolved conversation is clear, countable, and easy to verify against an observable event. The stretch is in the positioning, where “pay when the task is complete” invites the reader to hear “pay only for results.” Salesforce’s Flex Credits are a surrogate unit, a vendor-defined pool consumed at different rates across actions, a legitimate accounting layer that sits a further step removed from any single customer result.

The gap: vendor output vs business outcome

The label papers over a specific gap. A recommended lead is not a qualified lead that has entered the sales process. A resolved conversation is not a ticket that stays deflected. The task completing is a vendor-defined output. The outcome is what happens next in the customer’s operation, and the customer is the one who finds out whether it landed.

Why the gap invites the dispute

Priced on the action, you are asking the customer to pay whether or not the value materializes. If a recommended lead never converts, or a resolved conversation reopens the next day, the customer still paid. That gap is what invites the dispute. A metric closer to the result earns willing payment, because the customer can see the value they are paying for. This is the seller’s design problem, not a warning to buyers: the question is whether the unit you meter is close enough to the result that the customer keeps paying for it at renewal.

This is not a criticism of consumption pricing

None of this makes task-completion pricing a bad model. It is often the right one. Charging per completed task is legible, the customer can verify each charge against an observable event, and it avoids the opacity that unmanaged credit pools create. Vendors who price this way and describe it accurately, as consumption of a defined unit, are doing nothing wrong, and often something smart.

Engineered surrogate units versus improvised ones

The critique lands only on the label. A surrogate unit like credits is a legitimate architecture choice when it is deliberately engineered: a published conversion table, definition stability where a change in what a credit buys is treated as a price change, exportable underlying events. What draws pushback is the un-engineered version, adopted as the path of least resistance and re-rated quietly at renewal, where the conversion rate is a lever the party who owns the meter controls unilaterally. The same discipline applies to the word “outcome”: use it when the metric is genuinely tied to the customer’s result, and do not reach for it to make consumption feel safer than it is.

Why vendors reach for the word “outcome”

Vendors reach for the word because it smooths over the anxiety buyers feel about unpredictable consumption bills. In our engagement work we watch that anxiety show up as usage rationing and companies assigning someone to watch the meter, a metric problem rather than a messaging problem. When an anxious meter suppresses the exploration you were counting on, relabeling it does not calm a buyer who has learned to read it.

How you price signals how you treat customers

Once procurement looks under the hood of what the credit or the task actually counts and finds consumption dressed as outcome, the trust goes with the veneer. A buyer who finds opacity in one place assumes it everywhere else in your model, and the suspicion surfaces as friction across the rest of the deal, from harder audits to slower approvals. How you treat customers is how you price. And how you price tells a customer what to expect in a relationship with you.

Three questions to answer before you ship the price

Before you ship an agent price, answer three questions about your own model.

First, does the price move when the customer’s result moves, or only when your agent performs an action? If the meter runs on activity, you have a consumption model. Own that, and do not dress it as an outcome.

Second, if the output produces no value, who carries the cost, and can you defend that position? If the answer is that the customer pays regardless, you are transferring the risk to them, and you need a reason they will accept when they audit the bill.

Third, is the metric named in the customer’s business terms or in your system’s terms? “Qualified leads that entered the pipeline” is the customer’s language. “Recommended leads” is your system’s. A metric named in the customer’s terms is one they transact on without haggling.

A model that answers these cleanly is one buyers renew. A model that fails them is one procurement takes apart at the table.

How to price an agent without stretching the term

Pick a value metric the customer recognizes and can verify. If you want genuine outcome pricing, instrument the realized result and share in it, accepting the execution risk that comes with charging on the customer’s success. If you are not ready to carry that risk, price on the task and say so plainly. A metric you can defend is what closes and renews.

From coarse schedules to a smooth pricing surface

The deeper move, once you accept that a smart buyer will always audit the unit, is a better pricing artifact rather than a better word. Coarse tiered pricing schedules invite buyers to argue special scenarios when they land between pricing tiers, which nearly guarantees a net price out of tune with the value. Tuning a smooth pricing surface is where that goes next, and it is a separate topic from this one. To see how that diagnosis starts from your own deal data rather than a competitor’s framing, read our approach.

Does outcome-based pricing actually work in B2B?

Outcome-based pricing works in B2B, but most implementations run it wrong, and they run it wrong in the same three ways. The skepticism behind the question is earned: outcome-based contracts close with conviction and dissolve quietly at renewal often enough that practitioners have learned to ask for evidence. The failures are structural rather than operational, which is why better tooling and more granular data rarely rescue a model that picked the wrong metric to begin with.

The first failure mode: the metric was chosen for measurability rather than proximity to customer value. The vendor instruments what its own system can count, the customer never draws a line from that count to their P&L, and willingness to pay erodes across contract cycles even when the metric moves in the right direction. The fix runs backward from the customer’s result to what you can instrument, never the other way.

The second: the baseline was never defined, so neither side agrees on what changed. Without a pre-agreed counterfactual, improvement arrives and the customer credits their own team, market conditions, or parallel initiatives, and rarely in bad faith. The starting line was never locked in, so the attribution is genuinely ambiguous and the invoice is hard to defend.

The third: asymmetric risk transfer wearing the outcome label. The contract capped the vendor’s downside while the customer absorbed the variability. At renewal a CFO sees vendor revenue that held steady while the customer’s result swung, and the mismatch between the label and the risk structure becomes the negotiation.

The implementations that hold up share three conditions. The vendor’s scope is narrow enough that attribution is defensible: collections recovery on a specific receivables book, conversion on a defined funnel step, a single named cost line, categories where nothing else in the customer’s environment moves that variable the same way. The value metric is one the customer already tracked before the vendor arrived, so the finance team owns the data series and the vendor never inherits the permanent burden of proving why a new metric matters. And renewal conversations center on the result rather than the usage: when the quarterly business review runs on tasks completed or seats activated, the model has reverted to consumption in practice, whatever the contract says. Designing an outcome-based model around these conditions is a design exercise that starts well before contract language.

When attribution confidence or a customer-tracked metric is missing, the defensible path is to start with consumption pricing and migrate. The signal to move is a cohort pattern: enough customers of the same type showing consistent results, in a repeatable workflow, at comparable magnitude. At that point you can name the outcome metric in the customer’s language, point to prior cohorts as the baseline reference, and defend attribution because the scope is bounded. Model choice is a position on a spectrum, and it should move as your attribution evidence matures.

If you are choosing a value metric for an AI agent and are not sure whether it prices the customer’s result or just your software’s activity, the fastest test is to run the unit against your own transaction data. Book a working session and we will pressure-test the metric against where your success rate is heading, so the price you ship tracks the value the customer realizes rather than relabeling your software’s activity.

FAQs