Outcome-based pricing is having its moment. Intercom bills $0.99 per resolution. HubSpot moved its Customer Agent to $0.50 per resolved conversation in April 2026. Zendesk charges up to $2.00 per automated resolution, and Sierra built a company past $150M in ARR on a single promise: you only pay when the agent actually does the job. The model has clearly won the argument. The question almost nobody is asking is the harder one, is your outcome-based pricing actually profitable? Because outcome pricing has a property no other model shares: it quietly punishes you for being good at your job.
Why outcome pricing inverts your margin safety
Usage-based pricing comes with a built-in safety valve. A heavy customer triggers more usage, so they pay more, and your cost and your revenue move in the same direction. You can under-price the unit, but you can't get blindsided, every expensive action generates a charge.
Outcome pricing severs that link. You bill a flat price per result, but the cost of producing that result is variable and uncapped. A resolution the agent nails in one model call costs you a few cents. A resolution that needs three retries, a long context window, and forty tool calls can cost you many times that, and it bills the same fifty cents or ninety-nine cents either way.
The incentive runs backwards, too. As your agent improves, it resolves more conversations, so you bill more outcomes. That sounds like the model working as intended, and at the surface it is, HubSpot's own change means the same included credit allowance now stretches to roughly twice as many resolutions. But the outcomes your agent learns to handle last are also the hardest and most expensive ones. You are scaling your revenue and your most expensive unit of cost at the same time, and only one of them shows up on the invoice.
The "resolved" trap: you're billing on a definition you don't control
Most outcome models don't bill on a result you define, they bill on a result the vendor's system declares. Zendesk and HubSpot mark a conversation "resolved" after a window of inactivity (commonly 72 hours). Intercom counts "assumed resolutions" when a customer simply stops replying. That has two consequences founders rarely price in.
First, your revenue depends on someone else's definition of success. If the definition is loose, you bill outcomes that weren't really outcomes and invite disputes. If it's strict, you eat costs on near-misses you can't charge for. Second, a billed outcome can be clawed back, a customer who returns to a "resolved" thread can reverse the charge after you've already paid the compute to produce it.
Zendesk formalizes this with what it calls an Outcome Measurement Agreement: both sides agree contractually on what counts as resolved before signing. That handles the legal half of the problem and gets the lawyers' attention. The financial half, what each "resolved" event actually costs you to produce, gets almost none.
Outcome-based pricing profitability: the math nobody runs
The formula is not complicated. Your outcome margin is the price per outcome minus the fully-loaded cost per outcome. The trap is in that second term, because the fully-loaded cost per outcome includes something most teams leave out entirely: the cost of every attempt that didn't resolve.
You pay your model and tool providers for every attempt, but you only bill the ones that succeed. So your true cost per billed outcome is roughly your cost per attempt divided by your resolution rate. If your agent resolves half of conversations, and real published resolution rates for deployed agents tend to land between 42% and 50%, you're paying compute on the other half and recovering nothing.
Work a quick example. Say each attempt costs you $0.12 in model and tool spend, and your agent resolves 50% of conversations. Your true cost per resolved outcome is $0.12 ÷ 0.50 = $0.24, before retries. Price the outcome at $0.50 and you've got a tidy 52% margin. Now look at your hardest segment: long, ambiguous tickets that resolve at 25% and cost $0.30 per attempt. True cost per resolved outcome there is $0.30 ÷ 0.25 = $1.20. You are losing seventy cents on every hard resolution and billing the same $0.50. Blend the two segments together and you might still report a healthy margin. Look at them separately and one of them is bleeding.
That gap between the blended number and the per-segment reality is the whole game. You can't see it on a monthly compute invoice, and you can't price around it if you can't measure it. Pricing a result you can't cost is just a guess with a decimal point, which is why the foundation of any outcome model is knowing the true cost per agent and per customer underneath it.
Four checks before you trust your outcome pricing
A short diligence list will tell you whether your outcome model is profitable or just hopeful. * Cost every attempt, not just every win. Your denominator is billed outcomes; your numerator has to include the unbilled failures you paid for. * Segment by difficulty and by customer. The blended number is designed to hide the negative-margin tail. Find the tail. * Model the improvement paradox. Project your margin as resolution rate rises. Does the extra volume outpace the rising cost of the harder outcomes you're now closing, or does it erode you? * Cap or re-price the long tail. Define a fallback, escalate, throttle, or surcharge, for the outcomes whose cost runs above their price, before they scale.
When outcome pricing is worth it anyway
None of this is an argument against outcome pricing. When you can genuinely prove and cost an outcome, it's the most aligned model in software: it removes the buyer's risk, ties your revenue directly to their success, and is exactly why companies like Sierra and Intercom can charge confidently for results. The buyers want it, too, survey after survey shows enterprises prefer paying for outcomes over seats.
The point is narrower and more useful: don't do it blind. Only around 9% of companies have fully implemented outcome-based pricing, while close to half are piloting it. The ones who win this transition won't be the ones who adopted the model first, they'll be the ones who instrumented cost per outcome before they scaled it, instead of discovering the math at renewal. If you're weighing this against the alternatives, it's worth reading how usage, outcome, and hybrid models actually compare and the same blended-average blind spot that makes a "profitable" product lose money on power users.
The companies that make outcome pricing pay treat one question as a first-class, real-time metric: what does a resolution cost us, per agent, per customer, per use case? Answer that, and outcome pricing becomes the strongest model you have. Skip it, and you've signed a fixed price against a moving, uncapped cost.
That's the layer Paygent is built for: tracking cost and margin per outcome, per agent, and per customer, so you can sell results you've already proven you make money on.
