Outcome-Based Pricing Is Safest for the Companies That Need It Least

Straightforwardly: you charge for a result rather than for consumption or access.

"Outcome-based pricing is if we achieve this result with the software that you have purchased, you will pay us X every time we do it…"

It's the logical end point of a progression the industry has been on for years. Perpetual licences gave way to subscriptions. Subscriptions are giving way to usage. There's a whole hybrid layer in between worth its own treatment — I've covered the mechanics of that in the full hybrid pricing model guide — but usage, in turn, points toward outcomes. Each step moves the charge closer to the value the customer receives, which is intuitively appealing and, in the abstract, correct.

The problem isn't the logic. It's what each step does to the predictability of your revenue.

The clearest live case is Intercom, in customer service software. The model is roughly: resolve a customer's problem, charge for the resolution — with agreed terms defining what "resolved" means.

That last clause deserves more attention than it usually gets. Under a subscription, ambiguity about value is a renewal conversation. Under outcome-based pricing, ambiguity about the definition is a billing dispute, every month, with every customer. You are contractually committing to a definition of success and then invoicing against it.

But the thing I find most instructive about Intercom isn't the model. It's their position when they adopted it.

"Intercom are smart because they have a bunch of products. So they have a bunch of 3D chess and they have a bunch of different ways of monetizing their products. They can run this as a kind of a baby experiment without too much risk."

They have a portfolio. Multiple products, multiple monetization methods, an existing revenue base. Outcome-based pricing runs inside that as a contained experiment. If resolution volumes come in low, or the definition proves contentious, or the unit economics disappoint, it's a disappointing line item — not an existential event.

Which gives you the test.

There's a reason I keep circling back to that definition problem, so let's stay with it for a moment, because it's where I've seen more of these deals go wrong than any pricing-model argument ever predicts.

A subscription SLA is mostly about the vendor's side of the bargain: uptime, response time, support windows. If you miss it, you issue a credit and move on. It's a side agreement, not the payment mechanism itself.

An outcome-based SLA is different in kind, not degree. The definition of the outcome is the invoice. Every month, you're not just delivering a service — you're asserting that a specific, contractually defined thing happened a specific number of times, and billing against that assertion. Get the definition loose, and you've built a machine that manufactures billing disputes on a monthly cycle.

Take "resolved," in Intercom's case. Resolved by what measure — the customer closed the conversation, a set period passed without reopening it, an internal classifier scored it as resolved? Each of those produces a different number, and a customer who disagrees with the classification isn't disputing your product, they're disputing your invoice. That's a fundamentally different conversation than a renewal.

The practical fix isn't clever. It's unglamorous specificity: define the outcome in terms both sides can independently measure, agree what happens when the measurement is contested, and instrument the whole thing so the numbers aren't a matter of who kept better notes. None of that shows up in the pitch for outcome-based pricing. All of it shows up in the second year, when the first dispute lands.

Outcome-based pricing is safest for companies that don't need it to work, and most dangerous for companies betting on it.

That sounds glib. It isn't. It follows directly from what the model does: it converts your revenue from something you can forecast into something contingent on results you only partly control. Whether that's acceptable depends entirely on whether you can absorb being wrong for a few quarters.

A company with several products and established revenue can. A company whose entire commercial model rests on the experiment cannot — and no amount of conviction about the model changes that arithmetic.

So the qualifying question isn't "is outcome-based pricing the future?" It's "what happens to us if this delivers half what we expect, for a year?" If the honest answer is we'd be fine, it'd just be disappointing, you can afford to run it. If it's we'd be in trouble, you're not experimenting. You're gambling, with extra steps.

Go back to the arithmetic underneath the inversion, because it's easier to see with numbers attached than as an abstract principle.

Say two companies each sign the same outcome-based contract: roughly $400K a year, priced entirely on resolution volume, with no floor. Nothing hypothetical about the deal itself — same terms, same customer profile, same delivery risk.

Company A runs five products and roughly $40M in total revenue. Company B has one product and roughly $3M in total revenue, and this contract is meant to be a meaningful chunk of its growth plan for the year.

Now the outcome volume comes in at half of forecast — not a catastrophe, just a slow quarter of adoption, the kind of thing that happens constantly in year one of any new pricing model. For Company A, that's a $200K miss against a $40M base: half a percent of revenue, invisible in the board deck, a note in the pricing team's quarterly review. For Company B, it's a $200K miss against $3M: closer to 7% of total revenue, unplanned, arriving mid-year, on top of whatever else didn't go to plan.

Same contract. Same shortfall. One company adjusts the forecast. The other has an emergency. That gap is the entire argument, and it's why generic advice about outcome-based pricing — "align price to value," "it's where the market's heading" — is true and useless at the same time. It's true for Company A and reckless for Company B, and the advice itself doesn't distinguish between them.

It's worth noting this isn't unique to outcome-based pricing — any usage-based structure carries the same asymmetry between the number you forecast and the number you get, just with a shallower distribution than outcome pricing's all-or-nothing resolution events. Outcome-based pricing is simply the model where that asymmetry is sharpest.

This generalises past outcome-based pricing, and it's the part most pricing advice gets wrong. Companies in different positions face genuinely different problems, and advice written for one is actively harmful to another.

If you have an installed base, your first obligation is not to break it.

"As a CEO, I can say the first thing that I'm concerned about is not upsetting them and not losing revenue from them."

And the specific risk is that you can't model the outcome ahead of time:

"It's quite a risky proposition to add elements such as usage-based billing because you have no idea, not until you've got quite a bit of data at least, what exactly the revenue impact of adding or changing that will be."

That's not an argument for standing still — the market is moving and standing still loses too. It's an argument for adding rather than replacing: keep the base on seats and features, layer the variable component on top. Less exposure, and you generate the data you need to make the bigger decision later.

If you're a funded startup, you have real freedom — no expectations to protect, so any model is available. But that freedom comes with a condition that's easy to gloss over:

"That only works if you've got a large amount of funding where you can experiment over a period of time and find out what works…"

Experimentation is funded by a buffer that absorbs being wrong. Without the buffer, you're not experimenting.

If you're established but want to move, there's a third route that gets far less attention than it deserves: launch a new product on the new model and leave the existing ones alone. Real data, real customers, no exposure to the revenue base. For most mid-sized companies this is the sensible answer, and it's rarely the one being discussed.

Here's the piece of evidence I keep returning to, because it cuts against the enthusiasm more effectively than any argument.

"What did OpenAI do? OpenAI chose to do a hybrid model, right? So they have an element of subscription and an element of usage. And that was smart, in my opinion, and a lower risk approach."

Consider the position they were in. Enormous funding, unprecedented demand, and effectively free rein to price however they liked. Any model was available to them.

"I'm guessing they could get away with anything they wanted to with the amount of funding they've got, and they chose to do hybrid."

The company with the greatest capacity to absorb revenue volatility still chose a structure with a predictable base underneath it. That reframes hybrid: not a cautious compromise for companies that can't commit, but the structure a well-advised company picks when it can choose freely.

One more reason to build for change rather than for a destination. The models are not going to settle.

"We went from the old fashioned perpetual for dozens of years and then subscription for a dozen years and then we go to hybrid for a dozen years. I think it's dozen weeks."

Utility billing, credits and tokens, outcome triggers, seats, features, bundles — these will keep recombining as buyers demand different arrangements. Anyone planning for a stable end state is planning for something that isn't coming.

Which surfaces questions most companies haven't answered:

"What about bundles? How do you handle that? What do you do with a bundle when somebody upgrades or cross grades or downgrades?"

And the operational consequence that catches people out:

"Instead of billing, you know, a thousand customers, 10 bucks a month, you're going to have to bill a thousand customers with all with completely different bill."

That is a materially different billing problem, and it needs entitlement history — a record of what each customer was entitled to and when it changed — not just a charge. That's the architecture question I've dug into separately: where billing logic ends and entitlement logic begins.

There's a fourth pattern worth naming on its own, because it gets folded into "usage-based" when it's really a different animal: continuous, utility-style billing. Think of an electricity bill rather than a phone plan. No upfront quota to buy, no tier to pick in advance — you consume, the meter runs, and the bill at the end of the period reflects exactly what happened, whatever that number turns out to be.

It's distinct from the credits-and-tokens pattern that's become the default for AI products, where the customer prepays a bucket and draws it down — I've written separately about how that model behaves under real usage. Utility billing skips the prepay step entirely. The customer's bill is a downstream fact, not a plan they committed to in advance.

That's attractive for the same reason it's demanding: it requires the vendor to be completely comfortable metering usage in real time, at a level of accuracy the customer will actually trust when the number is unexpectedly large. A subscription can be wrong and nobody notices for a quarter. A utility bill that's wrong is a phone call the same week.

This is where the model and the infrastructure question converge. Continuous billing isn't a pricing decision you bolt on later — it has to be built on metering and entitlement tracking from day one, which is the specific problem Zenmeter and its AI-era metering work exist to solve. Get the metering layer right and utility billing, credits, usage tiers, and outcome triggers all become configuration choices on the same foundation. Get it wrong and each one is a separate integration project.

If the models keep moving, the thing worth investing in isn't the right model. It's the ability to change models cheaply.

Most companies can't. Pricing logic sits in product code, accumulated over years — the configuration-not-code problem I keep coming back to:

"The majority of SaaS companies have hard coded a business model, which they've got away with over the years by putting a Band-Aid on it every five minutes and plugging it into Stripe and hoping for the best."

That was survivable when pricing changed annually. It isn't now — and it interacts badly with everything above. The companies most exposed to pricing risk are usually the ones least able to run the small, reversible experiments that would reduce it. Every trial costs an engineering cycle they can't spare, so they end up making one large irreversible decision instead of five small ones.

That's the wrong way round. Risk is managed by making mistakes cheap, not by trying to be right first time.

Ask the survival question before the strategy question. If this model delivers half of what you expect for a year, are you fine or are you in trouble? That answer determines what you're allowed to try.

Add before you replace. Layer variable components onto a predictable base. Keep the forecast intact while you learn.

Use a new product as the test bed if you have an installed base and want real data without real exposure.

Treat outcome-based as a later phase. Get consumption pricing working, instrumented and trusted first. Outcome pricing needs everything usage pricing needs, plus an agreed definition of success you're willing to invoice against.

Make changing your mind cheap. If a pricing change takes a release cycle, that constraint governs your commercial strategy — whatever the strategy deck says. Know what's actually configurable versus what requires engineering before you promise either your board or your customers a timeline.

Outcome-based pricing isn't a bad model. For the right company, at the right moment, with the right cushion, it aligns price and value better than anything before it.

But it's the least forgiving model yet invented, and forgiveness is exactly what you need when you're guessing — which, in a market this unsettled, everyone is.

The companies that will do this well are the ones who can afford for it to go badly. If that isn't you yet, build the capability to change your mind quickly, and revisit it when it is.