Per-outcome pricing means the customer pays for a unit of work the software produced, not for a seat in the software. The unit is a countable result: a resolved ticket, a qualified meeting, an accepted code-review suggestion, a reviewed contract.
What it looks like
Take a support automation platform priced at $800 per agent seat. A customer with 20 agents pays $16,000 a month. Redesign it to charge $1.75 per resolved ticket where the resolution was AI-driven and the customer did not escalate within 48 hours. At 40,000 tickets a month with a 45 percent resolution rate, that is 18,000 resolved tickets, or $31,500 a month. It looks like a massive price hike. It is not. It is the revelation that the SaaS price was far below the value delivered: the customer was getting roughly $450,000 of equivalent support labor for $16,000. The customer is strangely happier paying more, because the price is now tied to something they can measure.
What the math exposes
Running the numbers surfaces things seat pricing was hiding, and those things are usually more important than the pricing change itself. Four patterns show up in every redesign:
- SaaS pricing was usually too low. The per-outcome price lands 2x to 3x the SaaS price and the customer accepts it, because SaaS pricing was anchored to what a license costs, not what the work is worth.
- The definition is the contract. "Resolved ticket" or "qualified lead" looks obvious until you write the SLA. Defining it precisely forces product decisions that had been fuzzy.
- Margin shape changes. SaaS runs 75 to 85 percent. Per-outcome runs 55 to 75 percent because tokens, compute, and escalation labor are real COGS. But it is a lower percentage on higher absolute revenue, so gross margin dollars per customer usually go up.
- Forecasting gets harder. You forecast customer usage, not renewal decisions. Most companies end up hybrid: a committed minimum plus per-outcome overage.
What gets terrifying
Revenue becomes variable. If a 45 percent resolution rate drops to 30 percent because the customer's ticket mix shifts, revenue drops with it. Every quality drop hits the P&L within weeks, and every dispute over whether the outcome actually happened costs trust and money. That is why the contract needs five things in writing: unit definition, dispute window, arbitration mechanism, committed minimum, and price ceiling. For the full pricing framework this sits inside, see Pricing for AI Products.
Per-outcome is right when the unit is countable, the customer values it, and evals can defend quality. It is wrong when the value is augmentation rather than automation, or when the unit is too granular to forecast. Pick one bounded workflow, estimate outcomes per customer per month, and price it at 5 to 15 percent of the customer's alternative cost. Compare that number to the current SaaS price. The ratio tells you whether you have a transition worth running.