Outcome-based pricing means a customer pays for a result your software delivered, not for seats or usage. Before you can charge that way, you have to be able to do three things: deliver the outcome yourself, define when it is done, and prove to the customer that it happened. Most software companies can do none of the three today, because their product is a tool the customer operates, and the outcome belongs to whoever did the operating.
That is the part the guides skip. The pages that rank for this topic explain the models (per resolution, revenue share, milestones, hybrids) and the metering behind them. They are good at it. But they assume you already own an outcome worth billing. Customer support vendors were the first to adopt the model because they do own one: the resolved conversation happens inside their system, end to end.
For everyone else, pricing is the easy half. Delivery is the hard half. This post is about the hard half.
What the guides already cover
If you are new to the model, the existing guides are worth reading, and it is fair to summarize them before arguing with them.
Metronome's guide lists the requirements as measurable outcomes, proof of causation, and a pricing formula, and puts the standard plainly: "Effective outcomes are specific, measurable, connected to your solution, and valuable to customers." Lago's guide walks through the benefits, the risks (metric disputes, revenue volatility, instrumentation cost), and an implementation blueprint, and argues for binary, auditable metrics like "ticket resolved" over subjective ones.
Stefan Kontschinsky's piece on why outcome-based pricing models break names the three traps: unclear outcomes, unpredictable costs, and attribution. His conclusion is the closest any of them come to the delivery question. The model works only when a company can "own the outcome, measure it precisely and control the cost to achieve it."
All three are right. What they leave open is the first verb in that sentence. How does a software company come to own an outcome in the first place?
Why support went first
Look at who actually publishes outcome prices.
- Intercom charges $0.99 per resolution for its Fin agent.
- Zendesk announced outcome-based pricing for its AI agents on August 28, 2024, charging for issues "resolved autonomously by AI."
- Sierra describes its outcomes as "a resolved support conversation, a saved cancellation, an upsell, a cross-sell," and says "if the conversation is unresolved, in most cases, there's no charge."
Every one of these vendors does the work itself. The customer's end user talks to the vendor's agent, the agent handles the request, and the result is visible in the vendor's own records. Nobody else in the chain can claim the resolution, because nobody else touched it. Ownership comes from delivery, not from the price list.
The pressure to follow them is real. a16z's enterprise team used Zendesk's own seat price as the example: companies pay "per support agent ($115/month/seat), but when AI can handle ticket resolution, the natural pricing metric becomes successful outcomes," because AI handling the work means fewer seats. That logic does not stop at support. Any product where an agent can do the work instead of a person will feel the same pull. We covered the unit question in how to price your software when the customer is an AI agent.
The problem for everyone else
Take a typical B2B product: a shipping platform, an analytics tool, a scheduling system. The outcomes a customer cares about are things like "carrier rules set up correctly," "the weekly report sent to the exec team," "the integration connected and syncing."
Today, the customer produces those outcomes. Your software makes them possible, then waits. If the customer configures the carrier rules on a Tuesday, who delivered that outcome? Your product, the customer's ops lead, the implementation partner, the help article they read? This is the attribution trap Kontschinsky describes, and no billing system can resolve it, because the ambiguity is in who did the work, not in how it was counted.
So the honest answer for most software companies is that they cannot bill per outcome yet. Not because the pricing math is hard, but because they are not the ones delivering.
Three things you need before the price
Here is the test we use. An outcome is billable when you can say yes to all three.
1. Can you do the work, as the customer?
The outcome has to be produced by something you run, inside the customer's account, with that customer's permissions. Not a suggestion in a sidebar the customer then acts on. The actual change, made in the product.
This is where agents change the picture. An agent that works through your product's own tools, authenticated as the user, can complete the setup, file the report, or fix the configuration itself. At that point the outcome has a single author, and it is you.
2. Can you define done in your own data?
"Improved efficiency" is not an outcome. "Carrier rule created and the first label printed with it" is. The end state has to be something your product can observe directly, in its own records, without asking the customer how they feel about it. If done depends on a system you cannot see, you are back to arguing about attribution.
3. Can you show the customer what happened?
Every billable outcome needs a record the customer can inspect: what was done, when, as whom, and what changed. Lago calls for auditable data. Kontschinsky warns that when measurement lacks visibility, "customers begin questioning the accuracy of telemetry, and invoice disputes follow."
Even the support vendors are working at the edge of this. Intercom counts a resolution when the customer either confirms the answer helped or "exits the conversation without requesting further assistance," which Intercom calls an assumed resolution. At support volumes that is a reasonable proxy, and the definition is published, which is to its credit. But it is a proxy. Silence is counted as success, and that gap is where billing disputes come from. We looked at what it means for a real bill in Intercom Fin pricing explained.
When the agent does the work inside your product, the proof is simpler. The run either changed the account or it did not, and the log says which.
Activity is not an outcome
A common halfway step is to price the agent's activity and call it outcome pricing. Salesforce's Flex Credits are a clear, published example: "Each action costs $0.10," where actions are "the functions your agent executes on the platform to get information or perform tasks."
That is a sensible model, and it is easy to understand. But it is usage pricing with a better unit. An agent that takes five actions to finish one job, or ten actions and does not finish, is billed for the actions either way. The customer is still paying for effort and judging the result themselves.
The distinction matters because it tells you where you are. If you can meter actions but cannot say which runs produced a finished result, you have the delivery machinery and not yet the definition of done. That is progress. It is not outcome pricing.
The order of operations
If you want to charge for outcomes, work in this order.
- List the outcomes customers already pay people for. Setup, migrations, recurring reports, audits, cleanups. If customers hire consultants or assign staff to get them done, there is a price already.
- Pick the ones that happen entirely inside your product. Those are the ones you can deliver and observe without a partner.
- Build the delivery first. An agent that can act as each customer through your product's tools, with a definition of done for each task and a record of every run.
- Run it free or included for a while. You learn your real completion rate and your real cost per run before you promise anything.
- Then price it. Many teams start simpler than a per-outcome meter: sell the finished service once, or as a subscription with a set number of runs. The customer is still buying a result, and your invoice stays predictable.
Step 3 is the one that takes the time, and it is the one the pricing guides leave out.
Where Aimdoc fits
This is the problem we built Aimdoc for. The in-app agent works through your product's MCP, authenticated as each customer, so the work it does has one author: your product. Services are the outcomes you define on top, configured to each customer and run as that user, with every run recorded.
When a service is worth paying for, you can sell it through your own Stripe account: one-time or as a subscription, with included runs counted as the service executes. What you charge your customers is yours to set. What you pay Aimdoc is separate: prepaid credits for the agent's work, with caps you control. Aimdoc never charges you per outcome.
FAQ
What is outcome-based pricing?
A pricing model where the customer pays for a specific result the vendor delivered, such as a resolved support conversation, instead of paying for seats or usage. If the result does not happen, there is usually no charge.
How is it different from usage-based pricing?
Usage pricing charges for activity, like actions, calls, or conversations, whether or not they produced a result. Outcome pricing charges only for the result. An agent can generate plenty of usage without finishing anything, which is why the two are worth keeping apart.
Which companies use outcome-based pricing today?
The clearest published examples are in customer support: Intercom, Zendesk, and Sierra all charge per resolved conversation or similar outcome. They share one trait: their own agent does the work, so the outcome happens inside their system.
Can any SaaS company switch to outcome-based pricing?
Only for outcomes it delivers itself. If your customers operate your product to get the result, you cannot cleanly claim the result. The path is to have an agent do the work inside your product as each customer, define when each task is done, and record every run. Then the price follows.
If you want to charge for what your product gets done, start by having it do the work. See the in-app agent and how selling services works, or start free.