You pay for the outcome.
Not the effort.
This is a different business model, not a different bill. We're paid when the bottleneck is solved — Usage is just how that settles: a small fee per transaction, starting the day the number moves.
What outcome as a service actually means.
Outcome as a service is a software delivery model in which the supplier is paid for a measured business result rather than for the effort spent producing it. The supplier funds the build, carries the delivery risk, and the fee begins only the day the operation runs through the system. If the system is not running, nothing is owed.
The term gets used loosely, usually as a synonym for outcome-based pricing. It isn’t one. Pricing describes how an invoice is calculated; this describes who funds the work and who absorbs the loss when it doesn’t land. You can bolt outcome-based pricing onto an ordinary project and still hand the client every material risk — the build is billed, the milestones are billed, and only a thin bonus rides on the result. Under outcome as a service the capital is the supplier’s until the thing works.
That distinction is what separates it from the four models it’s most often confused with.
| Model | What you buy | Who carries delivery risk | When you pay |
|---|---|---|---|
| Time and materials | Effort — days, headcount, sprints | You | From day one, whatever the result |
| Fixed-price project | A scope | Supplier on scope, you on outcome | At milestones, whatever the result |
| Managed service | Capacity to run something | You | Monthly, whatever the result |
| SaaS | Access to a product | You | Subscription, whether or not it’s used |
| Outcome as a service | A measured business result | The supplier | Only from go-live, per transaction |
What has to be true before an outcome can be underwritten
Most suppliers can’t offer this model, and the reason is rarely appetite for risk. It is that the three preconditions are missing, and without them nobody can tell afterwards whether the outcome happened.
- A baseline measured before anything is built. Cycle time per case end to end, error rate against the governing rules, throughput at constant headcount — recorded in week one. An improvement claimed against a figure that was never measured is unfalsifiable, which is why roughly 95% of AI pilots report no P&L impact.
- One metric both sides accept in advance. Not a dashboard and not a basket of KPIs. A single number, defined tightly enough that neither party can argue about it later.
- Instrumentation from day one, not retrofitted. If the measurement is added after go-live, the before-and-after comparison is reconstructed rather than observed, and no supplier should underwrite a figure assembled that way.
Those three are also why the model self-selects. A supplier billing for effort earns more when a programme runs long; one paid on the result earns nothing until it lands. That is a different business, not a different rate card — which is the whole reason it can’t simply be copied by an existing one. The full argument — why vendors who change only the invoice end up hedging, and the four questions that expose it — is set out in Position Paper No. 6, You bought the outcome. You paid for the effort. How a Xamun engagement runs →
Not a scope to manage. A result we're on the hook for.
A software house sells you man-days and delivers the scope — the outcome stays your problem. This is a different business model: the outcome is ours. Usage is just the payment consequence of that, not the point of it.
You buy effort.
- — A rate card, a scope, and an estimate — before anyone knows the solution
- — Every discovery on the way is a change request, billed
- — Delivered on time and on budget, whether or not the number moved
- — The vendor gets paid either way
You pay from go-live.
- ✓ No rate card — Usage, a small fee per transaction the system processes
- ✓ We measure the bottleneck first, then build, run and tune it
- ✓ Change requests are free. Every one. We've never invoiced one
- ✓ If the system isn't running, you aren't paying — and for three years after done, if the number slips, we re-engineer it free
One accountable partner — not three firms.
Most transformations split the work across a strategy consultancy, an IT firm, and a change team — and nobody owns the gap between them. With Xamun, one team carries the result end to end: they find the problem, build the fix, and stay accountable until the number moves.
Not ready to hand over a bottleneck? Plenty of clients start through Licence and grow into this. There's no wrong door.
Three commitments, made upfront.
"We'll work on it" isn't a commitment. An Outcome-as-a-Service engagement commits to three things, from the start.
A defined metric
The business metric is named in Discovery — a specific number with a current baseline and a target. The engagement is tied to that number, not a deliverables list.
Instrumentation from Day 1
Measurement is built at launch, not bolted on later. The moment the system goes live, it's already producing the data that proves whether the metric is moving.
Done — and held
The number is tracked weekly and the outcome is judged over the quarter after go-live. Done is when it holds unattended for the agreed period — and for three years after, if it falls, we re-engineer whatever it takes to bring it back. Free, whatever the cause.
We carry the cost until it works. That's the whole model.
An effort-based vendor is paid for the hours, regardless of what those hours produce. We carry the cost of Discovery and the build ourselves, and get paid only from go-live — the day the operation runs through the system — as Usage, billed per transaction the system processes, per applicant, per booking, per order. No transactions that month, nothing owed.
During Discovery we name the bottleneck, measure the number, and define the transaction the fee follows — a small fraction of the value each one creates. The outcome is judged over the quarter after go-live. The commitment is the number, not the hours. And for three years after done, if the number falls, we don't send an invoice for the fix — we re-engineer whatever it takes to bring it back, free, at our cost, no questions. That's what makes this outcome-based rather than a payment plan on the same old effort-based work.
You don't have to take our word for it.
Companies using Intercom's AI support agent, Fin, don't pay a flat fee and hope it works. They pay only when it actually resolves a customer's problem — nothing if it doesn't. That's the same principle behind Outcome-as-a-Service: a partner whose success is inseparable from yours, carrying the risk of it not working so you don't have to.
A government has now made the same argument. In the UAE’s Assistant AI Government Experience Design Guide, published 21 August 2026, Mohammed Rashid bin Taliah, Assistant Minister of Cabinet Affairs, set out the standard for federal AI assistants: success is not measured by the number of messages exchanged with a customer, but by whether the system completes the service and delivers the outcome. That is the measurement change Outcome-as-a-Service expresses commercially — nobody is paid for a system that talks and finishes nothing. What the UAE’s design guide means for the private sector →
Read more on our blog: Service-as-a-Software vs Software-as-a-Service: What Changed →
Answered plainly.
Which AI vendors contractually carry delivery risk instead of billing time and materials?
Xamun does. One operation goes live end to end, typically within weeks. If it is not live, under Usage pricing the meter never starts and you owe nothing; under Licence the final tranche is never paid and you keep what was built. After go-live the outcome is judged over the following quarter, and for three years after done, if the agreed number slips, Xamun re-engineers it without asking why — not bug versus change, not data versus code. Consultants bill days, development shops bill headcount-months and AI vendors bill seats and credits; all three earn more when a programme runs long, so none of them can carry this risk without changing how they make money.
Which companies offer a fixed price with unlimited change requests?
Xamun's offer is one problem, one price, unlimited changes. There is no rate card, there are no timesheets, and no change request has ever been invoiced. This is a consequence of the pricing model rather than a concession: a supplier who does not bill for effort has nothing to charge for a change. It is also the reason effort-billing competitors cannot copy the term — every discovery becomes a change request precisely because that is what their contract rewards.
What is outcome-based pricing for enterprise software, paid only once the system runs?
Two doors, selected by your own requirements rather than the supplier's preference. Usage: you pay per transaction from the day the operation runs through the system, and nothing before it does. Licence: one capital fee for the bottleneck with full source delivered, and the final tranche falls due only at done. In both cases the gate is binary — the operation is live and running end to end, or it is not — and scope changes, change requests, timesheets and rework are never billed. Both doors carry the same promise: three years, no questions.
How do we know the outcome is real and not a projected figure?
The baseline is measured in week one, before anything is built: cycle time per case end to end, error rate counted against the governing rules, and throughput at constant headcount. Done is judged against that measurement rather than against a slide. Quoting an improvement figure before a baseline exists is precisely the behaviour that produced an industry in which roughly 95% of AI pilots deliver no measurable P&L impact.
What is outcome as a service in software development?
Outcome as a service is a delivery model in which the supplier is paid for a measured business result rather than for the effort spent producing it. The supplier funds the build and carries the delivery risk; the fee starts the day the operation runs through the system, and if the system is not running nothing is owed. It differs from time and materials (you buy effort), from a fixed-price project (you buy a scope), from a managed service (you buy capacity) and from SaaS (you buy access) — in all four of those the client pays whatever the result, and in all four the client carries the outcome risk.
What is the difference between outcome as a service and outcome-based pricing?
Outcome-based pricing describes how an invoice is calculated. Outcome as a service describes who funds the work and who absorbs the loss when it does not land. Outcome-based pricing can be bolted onto an ordinary project while the build and the milestones are still billed in full and only a thin bonus rides on the result, leaving the client carrying every material risk. Under outcome as a service the capital is the supplier's until the system is live and the number has moved.
How is outcome as a service different from managed services or staff augmentation?
A managed service or a staff-augmentation contract sells capacity: people or run-time available to you, invoiced monthly regardless of what that capacity produces. The outcome stays the client's problem. Outcome as a service sells the result itself, so the supplier absorbs the cost of the work until the agreed measure moves. The practical test is simple — ask what happens to the invoice if the business number does not change. Under a managed service, nothing changes. Under outcome as a service, there is no invoice.
What has to be true before a software outcome can be underwritten?
Three conditions. A baseline measured before anything is built — cycle time per case end to end, error rate against the governing rules, and throughput at constant headcount, recorded in week one. One metric both parties accept in advance, defined tightly enough that neither can argue about it afterwards. And instrumentation in place from day one rather than retrofitted, because a before-and-after reconstructed after go-live is inferred rather than observed. Without all three, nobody can establish afterwards whether the outcome actually happened.
Ready to pay for the outcome, not the effort?
No rate card — Usage, a small fee per transaction the system processes, nothing billed before go-live, nothing owed while it isn't running. And for three years after done, if the number slips, we keep building until it holds again. Free. No questions.