You already charge seats, usage or a subscription, and your agent or AI feature does work the customer can point to. Outcome-based pricing bills only when an agreed result happens, such as a resolved ticket or an accepted lead.
The definition matters more than the rate, because plenty of events your product can count are ones the customer never agreed to pay for.
Get the definition wrong and invoices turn into disputes. Even with a sound one, you pay for failed attempts before any result is billable, and a price that ignores that cost needs rebuilding after customers sign.
What follows lets you decide whether a result-based charge fits your product, write a definition both sides can count, and check what your billing must handle before the first outcome invoice.
The short version
When your agent or AI feature does work for the customer, the test is short. Charge per outcome only when the buyer values the result, both sides can verify it happened, and your product has real influence over whether it happens.
If any of the three is shaky, or consumption is easy to count but the final result is hard to verify, start with usage or credits. You bill for what both sides can count, which leaves much less room to argue over measurement when the invoice lands.
Whichever model you pick, three rules keep the price fair:
- Bill a result the buyer agrees is worth paying for. An event your software logs on its own is a usage unit, and pricing it as an outcome invites disputes.
- Price each outcome off the cost of every attempt, including the attempts that end without a chargeable result.
- Add a base fee when serving a customer costs you money before any billable result arrives.
The trap in rule 2 is that a cheap attempt hides an expensive result. If each attempt costs you $0.30 in compute and the agent resolves 4 of every 10 tickets, ten attempts cost $3.00 and earn only four charges.
That puts the real cost of each billable resolution at $0.75. Price it at $0.60 and you lose $0.15 on every result, even though each attempt looked cheap.
For a team moving off seats, I would start with a base fee or credit plan that absorbs the six attempts in ten that never resolve. The outcome price then only has to cover the attempt that produced the result, and the same $0.60 earns a margin instead of a loss.
Outcome-based pricing compared with seat, usage, and subscription pricing
The deciding difference is what triggers a charge. Seats, access and usage can be billable without a successful result. An outcome charge waits for the agreed result.
The unit and the payment arrangement are separate choices. A seat can be billed monthly, while prepaid credits fund a balance consumed by usage or outcomes. Buying credits upfront does not change what counts as billable.
| Pricing arrangement | What is counted | Charged without a result? | Who it suits |
|---|---|---|---|
| Flat subscription | Access during a billing period | Yes | Buyers wanting a fixed recurring access fee |
| Per-seat subscription | Billable users | Yes | Teams budgeting around user count |
| Usage-based | Activity such as calls or tokens | Yes | Buyers paying for measurable consumption |
| Outcome-based | Agreed completed results | No, for the outcome component | Buyers paying for verified results |
In an illustrative month, an agent runs 1,000 jobs and 600 succeed. Per-job usage pricing bills 1,000 units, while outcome pricing bills 600. The buyer pays for the 400 unsuccessful attempts under usage pricing. Under pure outcome pricing, you absorb that work without a charge.
If 900 jobs succeed next month, the outcome bill rises 50% at the same rate. A flat access fee stays unchanged, which suits a buyer with a fixed budget.
Outcome pricing suits buyers who accept a variable bill tied to verified results. Alternatively, charge for attempts through prepaid usage credits when consumption is measurable and results remain uncertain.
What counts as a billable outcome?
A billable outcome is a result the customer agrees is complete, such as a support ticket they consider solved. A reply the agent drafted or a job it ran is activity, and activity belongs in a usage unit.
If your agent closes 100 tickets in a month and 15 reopen within a week, billing on "closed" charges for 100 while the customer counts 85.
A 7-day verification window closes that gap. A ticket becomes billable only once it stays solved for a week, so the invoice shows 85 and those 15 never turn into disputed charges or refunds.
Ticket verification flow: 100 closures become 85 billable results and 15 unbillable reopens after seven days.
Is it valuable, provable, and countable?
Three checks decide whether a result your product materially influences can carry a charge.
Value is judged against the customer's goal, whatever compute or effort the result took.
Proof means the buyer sees the same evidence that triggers your charge.
A repeatable count means rerunning your rule over the same event records gives the same total every time.
When a result fails the proof check, bill the measurable activity with usage or credits instead.
How to write the outcome definition
For the ticket case, a definition the customer can read and your product can count looks like this:
- Unit: one ticket the customer marks solved, or that gets no reply for 7 days.
- Exclusions: failed attempts count zero, and a retry or duplicate of the same ticket counts once.
- Verification window: a ticket becomes billable once it stays solved for 7 days, a reopen inside that window keeps it unbillable, and failure evidence found later reverses the charge.
- Attribution: tickets a human agent took over don't count.
- Disputes: the ticket history is the evidence both sides review, and corrections land as a credit on the next invoice.
Paste that same text into the contract and into the spec for the code that counts results. The invoice and the customer's own count then come from one rule and can't drift apart.
Three examples of outcome-based pricing
An accepted lead, a merged fix and an approved document each give a buyer an observable completion event. Treat these as hypothetical charging rules for your own product.
1. An accepted sales lead
An agent qualifies a lead, a sales rep marks it accepted in the CRM, and that acceptance triggers the charge. Rejected leads and duplicate submissions count zero. The acceptance records value to the buyer without making payment depend on whether the rep later closes a sale.
2. A merged code fix
A developer reviews an agent’s proposed fix and merges it into the repository, making the merge the completion event. Unmerged proposals count zero, and a reverted merge within the agreed verification window removes the charge. The repository history gives both sides evidence they can check.
3. An approved document extraction
A document passes through extraction, then the buyer approves its extracted fields in an approval queue. Processing alone earns no outcome charge, and rejected outputs or retries of the same document do not add billable units. Counting each approved document once makes the total repeatable.
Pick a completion event the buyer already records in a CRM, repository or approval queue. Tying the charge to that shared record gives both sides a way to reconcile the invoice and helps reduce disputed charges and refunds.
When does an outcome-based pricing model fit?
For a product that completes the customer’s task, outcome pricing is a candidate.
When the customer still has to finish the work, charging for the downstream result makes your revenue per customer rise and fall with decisions your product never touched. I would start with usage or credits in that situation.
An outreach agent might book meetings, while the customer’s sales team handles discovery, proposals and closing. A booked meeting is within the agent’s contribution. A closed deal depends on what happens afterward.
Run the numbers over two months in which the agent books 100 meetings each. The sales team closes 30 deals in the first month and 15 in the second. At a fixed price per closed deal, your revenue falls 50% even though the agent delivered the same number of meetings.
Choose a billing unit that stops where your product’s contribution stops. Contacts researched can be your usage unit while closing remains outside the product. Meetings booked could support an outcome charge if the buyer accepts them as completed, valuable work.
That acceptance needs a specific question. Replace “Would you pay per result?” with “If we charge for each meeting booked, would your finance team accept the invoice using the booking record as evidence?”
The answer separates an event you can count from one the buyer will pay for. Settling that distinction protects against disputed invoices and gives the pricing conversation a better chance of closing.
How do the economics work?
Outcome pricing covers your costs only when the price per accepted result beats what each one cost to produce, unsuccessful attempts included, and one customer's month of numbers shows whether yours does.
Variable cost covers compute, model calls and the payment fee on each invoice, which grows with the result count. If a customer's work ran $2,500 in variable delivery cost in a month, unsuccessful attempts included, and that same month produced 2,500 accepted outcomes, each outcome cost $1.00.
At $1.50 per outcome you bill $3,750, which leaves $1,250 of contribution margin toward fixed costs, before salaries and overhead.
A fixed rate still leaves revenue moving with the count. If next month the same attempts yield only 1,500 accepted outcomes, you bill $2,250 against roughly $2,500 of cost, and the account runs $250 negative.
Track cost per accepted outcome for each customer every month. Reprice or add a base fee wherever it climbs toward the rate.
The buyer runs the mirror calculation, dividing the whole bill by accepted outcomes. With a $500 base fee, that is $4,250 across 2,500 outcomes, or $1.70 each.
Quote that $1.70 next to what the buyer pays for the same work today, such as their seat bill or the headcount doing it. That comparison is the one that decides whether they sign.
Compute is spent the day the agent works, while the charge waits for verification and the invoice. If your definition sets a 7-day verification window before a result turns billable, a month of delivery plus that window comes to about five weeks, so $2,500 or more leaves your account before the first payment lands.
A base fee paid upfront or prepaid credits shrink the days of delivery you fund from your own cash. With Creem's credit wallets, the buyer pays before the agent spends compute, and auto-refill charges a top-up product on the customer's saved card before the balance hits zero.
To get paid before the agent spends compute, try Creem and set up a credit wallet for your first outcome-priced customer.
Which outcome-based pricing structure should you choose?
A base fee with an outcome allowance is the structure I would test first, because it keeps an account paying in a month when results are thin.
Pure per-outcome pricing
The buyer pays only for agreed results. Failed runs earn nothing, but you still pay for them, so each result’s price has to cover that work.
Divide a low-success month’s total attempt costs, including failures, by its billed results. If that cost exceeds your price per result, add a base fee.
Base fee plus included outcomes
A recurring fee includes an outcome allowance, with additional results charged at an agreed rate. The fee remains payable when the buyer uses fewer outcomes, including none.
Take a plan where $200 a month includes 100 outcomes, with additional outcomes at $2 each. Delivering 150 outcomes produces a $300 bill, including $100 for the extra 50.
A 20-outcome month still bills $200. Quote the allowance and overage rate together so the buyer sees both the minimum bill and how it grows.
Minimum commitments and caps
A minimum commitment sets what the buyer owes even when results fall short. A spending cap limits their bill without limiting your processing costs, so pair it with one ceiling rule:
- Work pauses.
- Work continues at the agreed price.
- The buyer approves extra charges.
Creem’s usage-based billing can carry an included allowance and a cap on a usage price set to automatic settlement, so the ceiling you write into the contract is also enforced in billing.
Write the commitment period, cap reset date and ceiling rule into the same clause of the order form.
How to test outcome pricing before you switch
Keep existing bills unchanged while you count outcomes and show buyers sample invoices, then charge under the new model only for customers who agree to the paid pilot. Counting without charging catches ambiguous events and duplicates before they become payment disputes.
Apply the proposed definition to actual customer activity and compare your count with the buyer’s records.
Show the buyer a sample bill next. Include base fees, minimum commitments and overages alongside their current charges at expected volume. The test is whether they recognize each counted result as work they agreed to pay for.
If your rule counts 120 outcomes and the buyer recognizes only 100 as complete, that leaves 20 potential disputed charges.
Review those 20 records together and correct the counting rule or completion definition before taking payment, even if the sample bill is lower than today’s.
Run a paid pilot with customers who accept the sample counts. Track billed outcomes, revenue, disputed counts and changes in customer behavior. Measure margin per billed outcome, including the cost of every unsuccessful attempt.
On Creem's usage-based billing, your product verifies results before sending them as usage events to custom meters. Pilot customers' subscription units, seats or add-ons can change with proration without changing other subscriptions.
A usage price runs on a live subscription, so a pilot on Creem pairs the per-outcome charge with a base fee rather than billing results alone.
I would expand once a full billing cycle passes with no disputed counts left open and margin per outcome meets the target set before the pilot. Otherwise, change the unit, rate or base fee, then rerun the uncharged count.
What your billing setup has to count and collect
Your product confirms the result, a meter counts it once, the invoice shows that count, payment is collected, and someone owns the tax filing.
Each result record needs the customer, completed work and completion time. If 40 verified results arrive alongside 10 repeated messages, the meter should record 40 units. Counting all 50 overbills by 25%.
Creem’s usage-based billing meters use event_id as an idempotency key. For this illustration, use your result record’s ID as event_id, so retried deliveries carry the same ID and count once.
Keep outcomes separate from credits granted, consumed and recharged. Creem’s credit wallets debit usage from the balance, refuse charges on a shortfall and email the customer. The customer_credits.exhausted event fires once on that shortfall, so your product can pause the job or trigger a refill.
You can turn on auto-refill, which charges a top-up product on the customer’s saved card before work stalls.
Decide whether a mid-job shortfall stops work or triggers refill, matching your contract’s promise at the spending ceiling.
For postpaid billing, decide what happens to access while charges remain unpaid. Creem retries failed renewals automatically, and in Creem's own data from 28 Jul to 26 Oct 2026 those retries recovered 27.7% of failed renewals. If unrecovered compute costs threaten margin, prepaid credits bring cash in before delivery.
Check the rest before launch:
- Invoices connect the billing unit and count to the amount charged.
- Checkout supports the buyer’s currency.
- Reconciliation connects charges, refunds, chargebacks and fees to payouts.
- Someone owns VAT, GST and sales tax filing before the first international charge.
On a payment processor alone, founders still owe the VAT and the filings themselves. One founder's public Reddit post describes running Stripe without tax handling until VAT obligations became an issue, then moving to Creem.
Bill each result with meters and let Creem handle the tax
If your product can verify a result and the buyer accepts that record as proof, outcome pricing can carry part of the bill, usually beside a base fee or credits.
Whichever model you pick, the work left after the definition is turning a count that changes every month into a charge that gets paid and taxed correctly in each buyer's country.
Your product decides which results qualify and sends each one as an event. One way to run this on Creem's usage-based billing is to send each verified result to a meter as a usage event, so it bills on the subscription or debits a prepaid credit wallet.
Creem is the legal seller on the subscriptions, credit packs and top-ups your buyers pay for, so we calculate, collect and remit the tax on each of those sales.
Stop working out the tax on an invoice that changes every month, and try Creem so each counted result is billed with the tax collected and remitted for you.