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.
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.
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.
"We'll work on it" isn't a commitment. An Outcome-as-a-Service engagement commits to three things, from the start.
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.
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.
The metric is tracked weekly. If it isn't moving, we surface why and propose the next move — before the quarterly review, not after.
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 once the bottleneck is actually gone — Usage, billed per transaction the system processes, per applicant, per booking, per order. No transactions that month, nothing owed.
During Discovery we agree the fee basis that honestly fits how your value is created — Usage per transaction, or a share of the result you actually gained. Either way it's the same commitment: 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.
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.
Read more on our blog: Service-as-a-Software vs Software-as-a-Service: What Changed →
Xamun does. One operation goes live end to end within 30 days. 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, if the agreed number does not move, Xamun fixes it for three years 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.
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.
Two shapes, selected by your own requirements rather than the supplier's preference. Usage: you pay per unit from the day the system runs, and nothing before it does. Licence: one capital fee with source code included, and the final tranche falls due only at go-live. 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.
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.
No rate card — Usage, a small fee per transaction the system processes, nothing billed before it works, nothing owed if it doesn't. And for three years after done, if the number slips, we keep building until it holds again. Free. No questions.