Pay per result
You only charge when the outcome is real and verifiable. The invoice and the value are the same event. This is the cleanest alignment possible between what you build and what your customer pays for, and it is also the hardest model to execute well.
What this model actually means
Pay-per-result pricing, also called outcome-based pricing, means your customer pays nothing until a specific, predefined outcome occurs. A support ticket resolved by your AI. A lead qualified and handed off. A document processed and filed. The outcome has to be measurable, verifiable, and agreed on in advance.
This is not the same as billing for work done. Usage-based pricing bills for consumption: API calls made, tokens processed, compute minutes burned. Pay per result ignores all of that. It does not matter if your system tried ten times before it succeeded. The customer pays once, when it worked. If it never works, they pay nothing.
That asymmetry is the point. The vendor's revenue is structurally tied to delivering value, not to appearing busy.
Why you land here
The Pricing Unit Picker routes you to pay per result when your product delivers autonomous work on behalf of a human operator, and when the success or failure of each task is unambiguous. Typically: your product is an AI agent or automation that takes actions and produces discrete outputs, not a tool that augments human work in continuous ways.
Products that fit this model tend to have a few things in common. The outcome is binary enough to invoice on: the ticket either resolved without escalation, or it did not. The customer's willingness to pay is tightly linked to that outcome, not to your system's activity level. And your product has enough confidence in its own accuracy that it can absorb the downside of a failed attempt without bleeding out.
If all three of those are true, pay per result is probably the most honest pricing model you can offer. It also tends to be the most compelling in a sales conversation: "you only pay when it works" is a strong opening sentence.
What it is often confused with
The confusion most commonly happens with usage-based pricing. Both feel "fair" in the sense that the customer is not paying for a fixed seat or a flat fee regardless of use. But the unit of fairness is completely different.
Usage-based pricing aligns cost with consumption. You process more, you pay more. This is honest, but it is not outcome-aligned. A customer running a thousand API calls that produce nothing of value still gets a bill. A customer whose requests fail halfway through still pays for the compute they consumed. Usage billing rewards activity, not results.
Pay per result strips out the middle. The customer's cost is zero until their problem is solved. This is a meaningful distinction in how the model feels to both parties during a down month: with usage billing, bad results still generate a bill; with outcome billing, they do not.
The mechanism: risk transfer
Pay per result is, at its core, a risk transfer arrangement. You are absorbing the cost of your own failures. Every attempt that does not produce the defined outcome costs you compute, inference, and potentially human review time, with no revenue to show for it.
That is not a design flaw. It is the mechanism. You take on the operational risk so your customer does not have to. In return, the customer is willing to pay more per successful outcome than they would for a subscription that hedges the same risk back onto them. The $0.99 that Intercom charges per resolved support ticket sounds cheap until you realize that unresolved tickets were already costing the customer far more in human agent time.
The model works well when your success rate is high enough and your marginal cost per attempt is low enough that the math stays in your favor. When success rates drop or compute costs rise, the economics can flip quickly. This is why pricing per result is also a forcing function for product quality: you cannot hide behind an invoice for effort.
The definition problem
The hardest part of pay-per-result pricing is not the technology. It is the contract. You need a definition of "result" precise enough that both sides would independently agree on whether any given case qualified. Vague definitions generate disputes. Disputed invoices destroy customer relationships faster than almost any other billing failure.
Consider what "resolved" means in a support context. Does the ticket close automatically after 24 hours with no reply? Does the customer have to explicitly confirm resolution? What happens when the customer closes the ticket but later reopens it with the same complaint? Each of these edge cases needs a written answer before you price the first ticket.
Write the definition before you set the price. If you cannot write a definition you are confident in, that is a signal your outcome is not well-specified enough for this model yet. Move to usage-based pricing as a bridge while you sharpen the definition. Pay per result works best when the outcome has been running in production long enough that you know exactly how to measure it.
Risks and failure modes
Metric gaming. When the billing unit is a specific outcome, the incentive to define the outcome narrowly in your favor is real. A support ticket "resolved" because the AI deflected the customer, not because the customer's problem was solved, will eventually erode trust. Define outcomes in terms of customer success, not system success.
Adverse selection. Customers with high-complexity, low-automatable work will try to get onto outcome-based pricing and run tasks your system cannot handle reliably. You need the ability to decline or price certain task types differently.
Cash flow gaps. If your outcome cycle is long (a qualified lead that takes a week to confirm), you may be doing significant work before any revenue lands. Model this carefully before committing to the structure.
What to do from here
If your product qualifies for pay per result, the most important next step is writing the outcome definition as a legal document, not a product spec. Every word matters. Run it past a customer before launching it so they can surface the ambiguities you have already stopped seeing.
Price based on the value of the outcome to the customer, not on your cost to produce it. A resolved support ticket is worth between $8 and $40 to a human-staffed team. Charging $0.99 to $2 is not undercutting yourself; it is pricing for adoption at a point where trust is still being built. But do not start below what the math can sustain. The model only survives if your success rate and your per-outcome price are both honest numbers.
The question that clarifies whether you are ready: could you write the invoice criteria for a customer right now, and would both of you agree on every case that came through in the next week? If yes, you are ready. If not, that document is the work.