Most SaaS pricing advice treats software like a place I rent. I pay for access, and the bill barely changes whether I visit twice a month or live in it. AI software doesn't feel like a place to me. The best parts feel like work getting done while I'm doing something else.
So I keep coming back to the same question: if AI is labor, why do I price it like real estate?
Use the Pricing Unit Picker - Free Tool if you want a quick recommendation before you commit to a pricing story.
The invoice line
Here's a practical test: if you're building an AI SaaS product, write the invoice line item first. Not the features list, the bill. The unit you charge for ends up shaping everything else. Once I look at it that way, "pay per result" stops sounding like a pricing trick and starts sounding like a constraint.
Subscriptions are rent. They turn messy value into a clean budget line. That predictability is why monthly and annual plans won. Even per-seat pricing is the same move with a proxy attached. If I can't measure value directly, I charge for something correlated with it, like headcount.
Why AI wants a meter
AI makes the tradeoffs harder to ignore because the costs show up per run. With LLMs, the model isn't a fixed asset sitting on my server. Every time I run it, I pay someone for tokens. That doesn't mean subscriptions can't work. It means a flat price becomes a bet about usage and a bet about my customer behaving "normally."
OpenAI's own API pricing makes the variable cost explicit, down to dollars per million tokens.¹
So I start looking for a meter.
The obvious answer is usage-based pricing. I charge for tokens, API calls, minutes, or runs. It's honest about costs, and it protects my margins.
But it also puts a taxi meter on the product. The meter changes behavior. People hesitate, they optimize, they avoid poking around. Exploration starts to feel like waste.
Pay per result keeps the meter, but moves it to a unit the customer actually cares about. If I charge per token, I have to sell "intelligence." If I charge per support conversations resolved, I have to sell "resolution."
Those are not the same sale. One is abstract capability. The other is a promise about an outcome.
This is where it gets interesting: once I price per result, I’m forced to define what the product is. Every founder says they sell outcomes. Most products are priced like access. That mismatch is survivable when the customer does the last mile themselves.
But when I ship an agent, the last mile is the whole point. The unit becomes the product.
That shift makes more sense once you read Agents Learned to Talk. Now They Need to Learn to Pay., which argues that agent software eventually needs native economic primitives.
Intercom's Fin is one of the cleanest examples I’ve seen in the wild. Currently, they price the AI agent at $0.99 per "Fin resolution." They even spend words defining what a resolution means and how it's counted, because they have to.²
That definition matters more than the number. Pay per result pricing drags measurement out of the basement and into the contract.
Stripe’s writeup on outcome-based pricing reads like a checklist of questions a subscription lets me avoid: what counts, how I measure it, how I handle attribution, and what I do with edge cases.³
So when I ask "is pay per result better," I end up with a different question: what unit of value is stable enough that both sides can trust it?
The spectrum of pricing units
That question also answers the "are there other models" part, because pay per result isn't alone. It's one point on a spectrum of ways to choose a unit.
At one end is pure access rent: flat monthly or annual fees.
Then there are proxies for value: per seat, per feature tier, per department, per location. The unit is easy to count, even if it’s not the thing anyone truly wants.
Then there is consumption: pay for what gets used. At the time of writing, OpenView reported that three out of five SaaS companies use some form of usage-based pricing, and that hybrids are more common than pure pay-as-you-go.⁴
Then there are transaction models: a fixed fee or a percentage per successful payment, per order, per invoice processed, per shipment. It feels like usage, but the unit is closer to commerce.
Then there is take rate: the product becomes a marketplace or a pipe, and I take a cut of the value that flows through it. This is still a unit, it's just a unit in money instead of actions.
And then there is outcome pricing, where the unit is a verified result: a ticket resolved, a qualified lead, an hour of uptime, a conversion lift.
Stripe points out that this already exists in places as different as payments and jet engines, which is reassuring because it suggests the model isn't an AI novelty.⁵
Here’s that spectrum in one table.
Model | What I charge for | What it optimizes for | Best when | Main risks | Measurement burden |
|---|---|---|---|---|---|
Subscription (flat) | Access over time | Predictability | Value is steady, usage is lumpy | Overpay resentment, under-serve incentives | Low |
Per seat | Access times team size | Expansion and adoption | Value scales with headcount | Seat policing, misfit for non-user outcomes | Low |
Usage-based | Tokens, calls, minutes, runs | Cost alignment | Usage closely tracks value and cost | Meter anxiety, limits exploration | Medium |
Transaction-based | Fees per payment, order, invoice, shipment | Throughput | The product sits on a transaction path | Step pricing can hide risk transfer | Medium |
Take rate | Percentage of money flowing through | Volume and value flow | The product is the market or the pipe | Platform risk, margin compression | Medium |
Outcome-based (pay per result) | Verified outcome (resolved, booked, lifted) | Delivered relief | Outcomes are frequent, countable, and attributable | Gaming, attribution disputes, perverse incentives | High |
Hybrid (base + variable) | Access plus usage or outcomes | Risk sharing | Both predictability and variable value matter | Complexity, harder to explain | Medium to high |
So yes, there are many models. But they all reduce to the same move: pick a unit, then argue about whether it's a fair representation of value.
Where outcome pricing breaks
Outcome units make a strong promise, but they come with three kinds of pain.
The first is definitional pain. "Resolved" sounds obvious until I have to define it. Does it require customer confirmation? What about a reopen within 72 hours? What about a human stepping in for the last sentence?
Intercom has to answer these questions because the whole price rests on them. ²
The second is attribution pain. Most real outcomes have multiple parents. A conversion might be seasonality. A lead might be a marketing campaign. A support resolution might be the docs, not the bot.
Stripe calls this out directly: if I can't defend attribution, I won't be able to defend the invoice. ³
The third is incentive pain. When I get paid per outcome, I can start optimizing the count instead of the truth behind the count. That’s how ad tech got weird.
It's not that metrics are evil. It's that the measurable unit quietly becomes the target, and the target isn't always the thing the customer actually values.
There's another failure mode worth naming because it hides in plain sight. A lot of "pay per result" is actually pay per milestone.
I charge for a lead, but the customer really wants revenue. I charge for a summary, but the customer really wants a decision.
That's not automatically bad. It just means I'm selling a step and calling it an outcome, which is a quiet way of moving risk back to the buyer.
This is also the strongest counter-argument for subscriptions. They make buying possible.
Procurement loves a predictable line item. Leaders love knowing the bill before they see the usage. And the less I tie price to a contested metric, the fewer disputes I create.
Outcome pricing can be truer to value, but it also forces measurement, definitions, and arbitration into the relationship. Sometimes the simplest thing is worth paying for.
The boring answer
This is why my current best answer is boring: the model that often works is a hybrid.
I can charge a base platform fee that covers steady costs and buys predictability, then layer on a variable fee tied to usage or results.
I can add caps so a surprise spike doesn't feel like betrayal, and minimums so my business isn't allergic to seasonality.
Stripe suggests base-plus-outcome structures as one way to balance risk. ³
But the more interesting implication is what this does to product and marketing.
Feature marketing is for tools. Outcome marketing is for workers.
If I price per result, I’m no longer selling software that might help. I’m selling a predictable unit of labor, and the customer is buying relief.
That changes what I build. It also changes what I have to prove.
I don't get to hide behind activity metrics, because activity isn't billable. Only outcomes are.
The unit test
So here's the unit test I keep coming back to, and it's something I can run before I build anything complicated.
I write one sentence that could appear on an invoice. "X dollars per Y." Then I ask if Y is something a customer would brag about internally, not something my product team would brag about in a demo.
If the sentence sounds like a proxy, I’m probably still selling access. If it sounds like relief, I might be onto an outcome.
Then I do one more thing: I write the dispute email. The angry version.
If I can’t imagine what data I'd show to resolve the dispute, I'm not ready to price on that unit yet.
Maybe AI gets cheap enough that subscriptions come roaring back. But even if that happens, I think the habit shift might stick.
Once customers experience paying for the job being done instead of paying for the right to try, "access" starts to feel like rent on a task.
Rabbit Hole
- Software Companies Are Becoming Staffing Agencies
- The $5,000 Problem (Includes free tool)
- Every Venture Is Either a Commodity or a Brand
- OpenAI, "API Pricing." This page shows token-based model pricing, which matters because it makes variable, per-run LLM costs concrete instead of theoretical.
- Intercom, "Pricing and usage limits" and "Fin AI Agent resolutions." Intercom’s Fin documentation describes a per-resolution pricing model and defines how a "resolution" is counted, which matters because outcome pricing lives or dies on definitions and disputes.
- Stripe, "Outcome-based pricing: A guide for businesses." Stripe lays out the mechanics and pitfalls of pricing tied to results, especially definitions, attribution, and the need for contracts and instrumentation that can survive scrutiny.
- OpenView, "The State of Usage-Based Pricing: 2nd Edition." This survey writeup matters because it reports broad adoption of usage-based pricing and emphasizes that hybrid approaches are common, supporting the idea that most companies mix models instead of picking one pure scheme.
- Stripe, "Outcome-based pricing: examples." Stripe points to outcome pricing outside software (including manufacturing and service contexts), which matters because it frames the model as a general business pattern, not an AI-specific gimmick.