Table of Contents
Outcome based pricing gives customers the cleanest possible value story: pay for the result, not the effort. It also sounds simple in a pitch. Charge per completed result, not per hour or per seat, and let the price speak for itself.
The complexity hides inside the word “completed.” This article looks at why generative AI makes that word much harder to price than it looks, and what companies selling this way need to protect against before the cost side catches up with them. An earlier article in this series covers the licensing side of the same problem.
Outcome Based Pricing: Key Takeaways
- An outcome like “a finished invoice” sounds like a single, well-defined thing, but real documents vary enormously in structure, completeness, and ambiguity.
- Generative AI systems often need multiple internal iterations (drafts, checks, corrections) to reach an outcome a human would accept, and each iteration consumes real compute.
- Token costs for agentic AI workloads have risen roughly thirtyfold since 2023 on complex tasks, even as the per-token price of the underlying models has fallen.
- Because price per result is usually fixed while the cost of producing it is highly variable, margin on any single transaction can swing from comfortable to negative.
- Salesforce’s own shift from per-conversation to per-action billing for Agentforce is a live example of a vendor restructuring its model once the underlying cost problem became visible.
The Outcome Based Pricing Problem With “Finish This Invoice”
An invoice is not a single, standardized artifact. One customer’s invoices arrive as clean structured data. Another’s arrive as scanned PDFs with handwritten annotations, inconsistent line-item formats, and missing purchase order numbers that have to be resolved by cross-referencing three other systems.
Both are technically “an invoice.” Producing a correctly processed result from each one is not remotely the same amount of work, and that gap is where this way of pricing starts to strain.
A related piece in this series described a fraud prevention example where a billable outcome required a transaction to be approved, processed successfully, and not flagged as fraudulent within ninety days. That definition solves the dispute problem: both sides agree on what counts.
It does not solve the cost problem. Nothing in that definition says how much computational effort it takes to reach that state for any given transaction, and that effort is exactly what determines whether the vendor makes money on it.
Generative AI Pricing Turns a Fixed Task Into a Variable Number of Attempts
This is where generative AI pricing becomes genuinely harder than pricing earlier, rules-based automation. A traditional document processing system either matched a template or it did not. A generative AI system can draft an answer, evaluate its own draft, identify a gap, redraft, and repeat that loop several times before producing something a human would sign off on.
Each pass through that loop is a real cost. A simple, well-structured invoice might be handled correctly on the first attempt. A messy one might take five or six internal passes, plus validation steps, before the system produces an acceptable result.
From the outside, the customer sees one invoice go in and one correct result come out. They reasonably expect to pay one flat, agreed price for it.
From the vendor’s side, the actual cost might have varied by an order of magnitude between two customers, or even between two documents from the same customer. There is no way to know which case applies until the work is already done.
Pro tip: Track cost to serve at the individual account level, not just as a company-wide average. A healthy blended margin can hide a small number of accounts that are quietly losing money on every transaction, and those tend to be the accounts with the messiest input data.
Token Burn: Why Cost to Serve Is Hard to Forecast
The mechanism behind this variability has a name in the AI industry: token burn. A straightforward query to a language model might consume a few thousand tokens. An agentic workflow, one that plans, calls tools, checks its own output, and retries when something looks wrong, can consume tens of thousands to well over one hundred thousand tokens for a single task.
Industry cost tracking shows the average cost of a complex, orchestrated AI interaction rising from around four cents in 2023 to roughly a dollar twenty by 2026. That is a thirtyfold increase, even though the per-token price charged by model providers has generally fallen over the same period.
The paradox is straightforward: workloads have moved from single questions to multi-step processes involving planning, tool calls, and validation loops. Each of those steps adds its own cost on top of the last, which is what makes total spend so hard to forecast per transaction.
The scale of this risk is not theoretical. In one widely reported case, a large company’s engineering organization burned through its entire annual AI compute budget in four months. An agentic coding tool had rolled out faster than finance had modeled, and individual work sessions cost over a thousand dollars in a matter of hours.
That is an internal tooling example, not a customer-facing pricing example, but the underlying dynamic is identical: usage that varies non-deterministically by task complexity, running against a spending assumption built on averages. Our breakdown of agentic AI cost drivers covers the mechanics in more detail.
Result Based Pricing and Outcome Based Pricing: Same Problem, Different Name
Result based pricing and this way of charging for AI work are largely the same idea described from two angles. One tends to describe the business framing, where the customer buys a defined result. The other is often used interchangeably, sometimes with a narrower focus on a single measurable deliverable.
Whichever term a contract uses, the underlying risk is identical. Whatever gets billed as “one result” has to absorb whatever variable amount of compute it actually took to produce, and the label on the contract does not tell the vendor how to price that variability.
What This Means for the Company Selling Outcome Based Pricing
Salesforce’s own experience with Agentforce is the clearest publicly visible example of a company adjusting its structure because of this exact problem. It initially priced at a flat rate per conversation, then found that a conversation was too variable a unit, both in what counted as resolved and in how much work it took to resolve.
The company moved to Flex Credits, detailed in its official pricing announcement, which bills per discrete action instead. That is a direct response to the challenge described in this article: a flat price against a variable-cost unit eventually forces a repricing.
Conversation Based Pricing vs Action Based Pricing
| Per-Conversation Pricing | Per-Action Pricing | |
|---|---|---|
| Billing unit | One conversation, regardless of steps taken | Each discrete action performed |
| Cost alignment | Loose. A short and a long conversation cost the same | Tighter. Cost tracks work actually done |
| Predictability for customer | High per-unit price, unpredictable total spend | Lower per-unit price, spend scales with usage |
| Vendor margin risk | High on complex conversations | Lower, but requires granular usage tracking |
| Best fit | Early pilots, simple use cases | Mature deployments, variable task complexity |
Companies pricing AI results generally need at least three protections that a simple flat rate does not provide on its own.
A Practical Checklist for Outcome Based Pricing That Protects Margin
- Tier pricing by complexity. A simple, clean case and a messy, multi-pass case should not be priced identically even though both produce “one result.”
- Monitor cost per account, not just per transaction type. An unusually expensive customer segment needs to be visible before it erodes a full quarter’s margin.
- Set a ceiling or escalation clause. Cases needing an unusual number of internal iterations should trigger a defined limit, so one pathological document does not turn into an unbounded compute bill.
- Measure token burn at the task level. Aggregate averages hide the specific workflows that are quietly unprofitable.
- Revisit pricing definitions on a fixed cadence. A definition that worked at launch, like Salesforce’s original per-conversation model, can stop matching the underlying cost structure as usage matures. Our services page covers how we help teams run this review.
Frequently Asked Questions
Why is this pricing approach harder than it looks for AI-powered products?
Because the price is usually fixed, but the cost of producing the result varies enormously depending on how many internal attempts, drafts, or validation steps a generative AI system needs to reach an acceptable outcome. A simple case and a complex case can cost the vendor very different amounts, even though both are billed the same.
What is token burn, and why does it matter for pricing?
Token burn refers to how many units of computation, tokens, a generative AI system consumes to complete a task. Agentic workflows that plan, use tools, and self-correct can burn tens of thousands of tokens for a single task, and that consumption is difficult to predict in advance, which makes the true cost of a transaction hard to forecast.
Why did Salesforce change its Agentforce pricing model?
Salesforce initially priced Agentforce per conversation, but found that a conversation was too variable a unit, both in what counted as a resolution and in how much computational work it required. It moved to Flex Credits, pricing individual actions instead, as a more precisely measurable and costable unit.
How can a company protect its margin under this kind of pricing?
Common protections include tiered pricing based on case complexity, per-account cost monitoring rather than relying on company-wide averages, and contractual ceilings or escalation clauses for cases that need an unusually high number of processing attempts.
Is this pricing model still worth using despite these challenges?
Yes, for the right product. It offers the clearest value alignment of any license model. The challenges described here are reasons to price and monitor it carefully, not reasons to avoid it. They mostly stem from treating an inherently variable cost as if it were fixed.
The Price Can Be Simple. The Cost Behind It Rarely Is
That simplicity on the customer-facing side is exactly what makes this model tempting to underprice on the vendor-facing side. A flat, easy-to-explain price hides a cost structure that is anything but flat, and companies that succeed here never confuse the two.
This is also the last of the operational deep dives in this series. The next two articles take a different turn. One is a personal, more speculative piece on a tool that does not really exist yet but probably should. The last pulls together what all seven prior articles add up to. You can follow the full series here.
If your company is pricing, or considering pricing, an AI-driven result and wants a second look at the cost model behind it, let’s have a conversation.