Per-Outcome Pricing: What Gets Clearer and What Gets Terrifying

I want to show you three pricing redesigns. All three are for real workflows I've helped teams design pricing for in the last 18 months. The numbers are representative but anonymized.

For each one, I'll walk through the SaaS version, the per-outcome redesign, and what the switch reveals about the underlying business. The point isn't that per-outcome is always right. The point is that running the math exposes things that seat-based pricing was hiding, and those things are usually more important than the pricing change itself.

The short version

Three real pricing redesigns. Support automation: $800/seat → $1.75 per resolved ticket. Customer paid $16K/month for what was actually $450K of equivalent labor; new price is $31.5K/month with 77% margin and a happier customer. Sales enablement: $150/seat → $40 per qualified meeting; renewal stopped being reflexive because the price reflected value. Code review: $25/seat → $1.20 per accepted suggestion; half the customers loved it, the other half had a CFO meltdown. Per-outcome pricing exposes things seat-based pricing was hiding. The contract needs five things in writing: unit definition, dispute window, arbitration, committed minimum, price ceiling. Most software in 2026 should be hybrid: platform fee plus per-outcome overage.

For the broader business model shift this pricing change is part of, see From SaaS to Service-as-Software. For the eval infrastructure that defends the quality bar, see The Eval-First Product Org and the handbook chapter on The Eval Is The Spec. For the unit-economics line on the board deck, see The CPO Mandate 2026 and the handbook chapter Gross Margin Is Your Job Now. The full handbook playbook for the SaaS-to-outcome pricing transition lives in Pricing for AI Products.

Redesign 1: Customer support automation

The SaaS version

A support automation platform, priced at $800 per agent seat per month. The customer has 20 human support agents, so they pay $16,000 per month. The tool offers AI-assisted reply drafting, ticket routing, and macros.

Metrics after a year of use: the team is 22% more efficient, meaning they handle 22% more tickets with the same headcount. The customer is happy enough. The vendor is happy. Net dollar retention is healthy at 112%.

The per-outcome version

Redesign the same product to charge $1.75 per resolved ticket where the resolution was AI-driven and the customer did not escalate within 48 hours.

The customer's volume is 40,000 tickets per month. Historically, about 45% of tickets could have been resolved by the agent at the quality bar (the rest require a human for various legitimate reasons).

40,000 tickets × 45% = 18,000 AI-resolved tickets per month. 18,000 × $1.75 = $31,500 per month.

Against $16,000 per month on the SaaS model, this looks like a massive price hike. It's not. It's the revelation that the SaaS price was far below the value the customer was receiving.

The customer was getting 18,000 human-hours of work per month (at maybe $25/hour fully loaded, that's $450,000 worth of support labor equivalent) and paying $16,000 for it. The SaaS price was capped by what the customer perceived as "a software license," not by the value delivered.

What the switch reveals

Three things.

1. The SaaS version was leaving money on the table. The customer is receiving $450K worth of equivalent labor at $16K. In the per-outcome version, the customer pays $31.5K for the same result. That's a 2x price increase and still represents a 93% discount on the labor-replacement value. Both sides are happier with the outcome-based number. The customer, strangely, is happier paying more, because the price is now tied to something they can measure.
2. The margin math gets interesting. Token cost per AI-resolved ticket is around $0.30. Infrastructure overhead is maybe $0.10. At $1.75 per ticket, gross margin is roughly 77%. That's SaaS-like margin, but at a higher absolute revenue, with much better alignment.
3. The incentive structure flips. On the SaaS model, the vendor's incentive was to keep the customer subscribed. Usage beyond the subscription was cost, not revenue. On the per-outcome model, the vendor's incentive is to maximize the number of high-quality resolutions. Both sides want the same thing: more tickets resolved well.

What gets terrifying

The vendor is now exposed to the quality of the AI resolution. If the 45% resolution rate drops to 30% because the customer's ticket mix shifts, revenue drops accordingly. Revenue is now variable in a way the CFO will not love. Forecasting is harder.

There's also the dispute surface. Did the ticket actually get resolved? Did the customer escalate because the answer was wrong or because the customer didn't read the response? Every dispute costs trust and money. You need a clear arbitration mechanism, and you need it from day one.

Redesign 2: Sales lead qualification

The SaaS version

A sales enablement tool, priced at $150 per sales rep seat per month. A typical customer has 30 SDRs, so they pay $4,500 per month. The tool scores inbound leads, enriches prospect data, and suggests outreach sequences.

The customer uses it. Some SDRs heavily, some barely. Renewal is up to the VP of Sales, who renews reflexively every year even though she's not sure which SDRs actually use the product.

The per-outcome version

Redesign to charge $25 per qualified lead that an SDR accepts and books a meeting from. "Qualified" is defined specifically: matches ICP criteria, has budget authority, expressed explicit interest, booked for discovery call within 7 days.

The customer is booking around 600 qualified meetings per month across all SDRs. Historically, about 60% of those came from AI-qualified leads.

600 × 60% = 360 qualified meetings per month. 360 × $25 = $9,000 per month.

This is a 2x price increase over the SaaS model. The customer signs anyway, because the alternative math is that each qualified meeting is worth about $400 in pipeline (derived from historical win rates and deal sizes), and $25 per meeting is a 94% discount on that value.

What the switch reveals

1. The usage distribution was hiding churn risk. Only 12 of the 30 SDRs were heavy users of the SaaS tool. Under per-outcome pricing, the customer's spend scales with actual qualified leads produced, which aligns better with what the VP of Sales actually cares about. The tool stops needing to justify the seats that aren't being used.
2. The definition of "qualified" becomes a contract. Under the SaaS model, "qualified" was a vendor marketing term. Under per-outcome, it's the billing event. Defining it precisely is non-negotiable. This forces a level of rigor that usually improves the product itself.
3. Sales cycles shorten. Procurement at the buyer's side now has a number they can benchmark. $25 per qualified meeting is comparable to what they pay for paid media ads or for BDR headcount math. The purchase decision moves from a SaaS tool evaluation to a pipeline-arithmetic decision, and the latter closes faster.

What gets terrifying

The product team is now responsible for what "qualified" means in practice. Every quarter, some qualified leads won't actually convert at the rate the vendor promised, and the customer will want a conversation. The vendor has to be ready to either tighten the definition (risking billable volume) or prove the leads met the contracted criteria (risking customer relationships).

There's also an attribution issue. The lead was AI-qualified, but the SDR did the outreach that actually converted it. Who gets credit? The contract has to specify, and the specification is almost always imperfect.

Redesign 3: Contract review and compliance

The SaaS version

A legal tech tool for contract review, priced at $1,200 per attorney seat per month. A typical customer has 8 attorneys, so they pay $9,600 per month. The tool flags risky clauses, suggests redlines, and compares against playbooks.

The customer's attorneys use it selectively, mostly for high-volume contract types. For complex or unusual contracts, they bypass the tool. Renewal is reasonably secure.

The per-outcome version

Redesign to charge per contract reviewed, at $40 per standard contract and $120 per complex contract. The pricing covers the AI review plus a human escalation layer for contracts the system flags as outside standard parameters.

The customer processes around 500 contracts per month. About 380 are standard, 120 are complex.

380 × $40 + 120 × $120 = $15,200 + $14,400 = $29,600 per month.

This is a 3x price increase. The customer accepts, because the current model has hidden costs: attorneys are spending significant time on review that could be automated, and the SaaS tool's utilization is far below what the vendor assumed at pricing. The per-outcome model reveals that the customer is actually getting $300K+ per month of attorney-equivalent review for $9,600. Correcting the pricing to reflect the work being done produces a $29,600 bill that the customer's operations lead happily approves.

What the switch reveals

1. The customer was structurally underpaying. Contract review, as a job, is expensive. The SaaS price was anchored to a "software license" mental model that disguised the actual value. The per-outcome price, while 3x the SaaS price, is still cheap relative to the attorney time it replaces.
2. Complex versus standard is the real product decision. Under the SaaS model, the vendor's incentive was to make the tool useful for both. Under per-outcome, the vendor has to decide whether to invest in better handling of complex contracts (which are more profitable per contract but operationally riskier) or to stay focused on standard contracts (which are simpler and higher-margin overall).
3. The human escalation layer has to be priced explicitly. In SaaS, the vendor could vaguely promise that complex cases would work out. In per-outcome, the cost of handling escalations is a visible line item. This forces the vendor to decide whether to run a services operation or to scope the product to cases that don't need one.

What gets terrifying

Liability exposure. When you charge per contract reviewed, you're implicitly taking on more responsibility for the quality of that review. Errors and omissions insurance becomes a real line item. Legal disclaimers in the contract become critical. The compliance story you tell to the enterprise's general counsel has to be airtight.

Also, revenue becomes seasonal in a way SaaS revenue isn't. Contract volume varies by quarter, by fiscal year end, by customer business cycles. Forecasting requires understanding your customers' operational rhythms, not just their subscription renewal dates.

The patterns across the three redesigns

Four patterns show up in every Service-as-Software pricing redesign I've done.

Pattern 1: SaaS pricing was usually too low

In every case, the per-outcome price ends up 2x to 3x the SaaS price, and the customer accepts it. SaaS pricing was anchored to "what a software license costs," not to "what the work is worth." Per-outcome pricing reveals the disconnect. Most Service-as-Software transitions are price increases, often large ones, in disguise.

Pattern 2: The definition is the contract

The hardest work in every redesign is defining the outcome precisely enough that both sides agree on what happened. "Resolved ticket." "Qualified lead." "Reviewed contract." Each of these terms looks obvious until you try to write the SLA. The rigor required surfaces product decisions that had been fuzzy under SaaS.

Pattern 3: Margin shape changes

SaaS margins are typically 75 to 85%. Per-outcome margins in 2026 are typically 55 to 75%, because the cost of delivering the outcome (tokens, compute, escalation labor, quality assurance) is a real cost of goods sold. The CFO's first reaction is often negative. The honest story is that the lower margin percentage is applied to higher absolute revenue, and the gross margin dollars per customer usually go up.

Pattern 4: Forecasting gets harder

SaaS revenue was beautifully predictable. Annual contracts, renewal cycles, known churn rates. Per-outcome revenue is variable by definition. You're forecasting customer usage, not customer subscription decisions. This requires different tooling, different CFO partnerships, and more sophisticated cohort modeling.

Most Service-as-Software companies end up with a hybrid model: a committed minimum monthly payment plus per-outcome overage. The minimum anchors forecasting, and the overage captures upside.

The test for your business

If you're considering a per-outcome redesign for any of your SaaS products, run this exercise in an afternoon.

1. Pick one workflow in your product. Something bounded, frequent, and measurable.
2. Estimate the volume of outcomes per customer per month. Use real data, not hopes.
3. Benchmark what the customer's alternative is. Human labor, a different tool, or doing without. Get a number.
4. Price per-outcome at 5 to 15% of the alternative. This leaves the customer a substantial discount while capturing value tied to real work.
5. Multiply by volume to get monthly revenue. Compare to your current SaaS price for the same customer.

The ratio between those two numbers tells you a lot. If per-outcome comes out to 50% of the SaaS price, you're on the wrong workflow or your SaaS price was too high. If it comes out to 5x the SaaS price, you have a big transition decision and probably a big opportunity.

In most of the exercises I've run with teams, the ratio comes out between 1.5x and 3x. That's the sweet spot: enough price lift to justify the transition cost, not so much that the customer conversations become impossible.

One more thing

Per-outcome pricing is the cleanest alignment between vendor and customer since money was invented. When your incentive and your customer's incentive are identical (produce more good outcomes), a lot of enterprise sales friction disappears.

It's also the most exposing business model you'll ever run. Every product flaw shows up in revenue, not just in churn. Every quality drop hits the P&L within weeks. Every customer whose volume drops takes revenue with them.

If you're not ready for that level of exposure, the honest move is to stay in SaaS and use AI to augment what you already sell. If you're ready, the prize is a business that grows with your customer's success in a way SaaS never could.

The math is clarifying either way.

---

The per-outcome pricing calculator I use with clients, including the five inputs and the sensitivity analysis, is on the toolkit at falkster.com/toolkit.

Further reading

• Kyle Poyar and OpenView on SaaS pricing evolution
• Tomasz Tunguz on usage-based and outcome pricing models
• Andreessen Horowitz on pricing AI products
• Stripe Atlas guides on consumption and hybrid pricing
• Ben Thompson (Stratechery) on the economics of agent-delivered value