The traditional outsourcing contract paid for effort. So many agents, so many hours, so many transactions processed at an agreed unit rate. It was easy to price, easy to audit, and structurally misaligned with everything the buyer actually wanted. The buyer wanted invoices paid accurately and on time, customers who stopped calling because their problem was solved, and cash collected faster. The provider was paid for headcount and volume. Those are not the same objective, and by 2011 enough organizations had been through two or three outsourcing cycles to notice the gap. Outcome-based contracting proposed the obvious correction: pay for the result. Pay per successfully resolved query rather than per call handled. Pay against days-sales-outstanding improvement rather than per collections activity. Share the benefit when the provider removes work rather than penalising them for it. The logic is impeccable. The implementations were considerably harder than the logic suggested.
Why the Input Model Persisted So Long
Per-hour and per-transaction pricing survived not because anyone thought it was optimal but because it had properties that outcome pricing does not. It was measurable without argument. Counting transactions is unambiguous. Both parties see the same number, and disputes are rare. It allocated risk clearly. The buyer bore volume risk, the provider bore efficiency risk, and each knew what they had taken on. And it required no shared definition of success. A transaction is a transaction. An outcome requires the parties to agree, in advance and in writing, what good looks like — and that conversation exposes disagreements that input pricing allowed both sides to leave unresolved.
The Measurement Problem Is the Whole Problem
Every difficulty in outcome-based outsourcing reduces to measurement, and it takes four distinct forms. Attribution. If days sales outstanding improves, was it the provider's collections work, a change in the customer mix, better credit screening upstream, an economic shift, or a large customer settling early? The provider claims the improvement; the buyer sees other causes. Both can be arguing in good faith. Baseline. Outcome pricing pays for improvement against a starting point. Establishing that starting point is contentious, because the provider wants a low baseline and the buyer a high one, and the historical data is usually incomplete, inconsistent or measured differently before transition. Dependency. Most outcomes depend on things the provider does not control. Collections performance depends on invoice accuracy, which depends on order data, which the buyer owns. Query resolution depends on system access and policy authority. Holding a provider accountable for an outcome they can only partly influence produces either inflated pricing or unenforceable terms. Gaming. Any metric strong enough to drive payment is strong enough to drive behaviour that optimises the metric rather than the objective. Pay per resolved query and queries get closed prematurely. Pay for cycle time and difficult cases get deprioritised. This is not provider dishonesty; it is how incentives work.
| Question | What the contract must establish |
|---|---|
| Attribution | Separate the provider's contribution from other causes of improvement. |
| Baseline | Agree the starting data, measurement period and validation method. |
| Dependency | Name the buyer-controlled inputs and the provider's actual scope of control. |
| Gaming | Balance speed, quality, cost or satisfaction rather than pay on one metric. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Where Outcome Contracts Worked
A consistent set of conditions separated the arrangements that delivered from the ones that produced two years of dispute. The outcome was substantially within the provider's control. Processes where the provider owned most of the chain — end-to-end payables, full collections, complete recruitment — worked. Processes where the provider handled one step of a chain owned by others did not. The data was already trustworthy. Outcome contracts require measurement systems both parties believe. Organizations whose baseline reporting was contested internally could not suddenly produce numbers a supplier would accept payment terms against. The metric set was balanced. A single measure is always gameable. Two or three metrics that pull against each other — speed and quality, cost and satisfaction — make optimisation at the expense of the objective much harder. And there was a defined route for renegotiation. Circumstances change, volumes shift, the business reorganises. Contracts with an agreed mechanism to revisit targets survived; contracts that locked in a formula for five years produced a provider losing money and a buyer receiving minimum-viable service.
Practical Guidance for Outcome-Based Contracts
- Test controllability first. For each proposed outcome, list what influences it and how much the provider controls. If the answer is under half, it is not an outcome you can fairly contract on.
- Agree the baseline before the pricing. Use a defined measurement period, a documented method, and a joint validation step. Baseline arguments after signature are the most common source of relationship breakdown.
- Use two or three metrics that conflict. Resolution rate with quality sampling. Cycle time with error rate. Cost with satisfaction. The tension is what prevents gaming.
- Specify measurement mechanics in detail. Who calculates, from which system, on what cadence, with what audit rights, and how disputes are resolved. Ambiguity here becomes a commercial argument.
- Fix your own dependencies first. If provider performance depends on data quality or approval speed you control, commit to those obligations in the same contract with the same consequences.
- Build in a scheduled review. At least annually, with an agreed mechanism to adjust targets for material changes in volume, scope or business circumstances.
- Start with one process. Pilot outcome pricing on a bounded, well-measured process before applying it across a portfolio. The learning about measurement is worth more than the saving.
- Keep a floor and a cap. Providers need enough predictable revenue to staff properly; buyers need protection against paying extraordinarily for an outcome driven by external factors. Pure variable pricing destabilises both sides.
The Relationship Effect
The most valuable consequence of outcome pricing was rarely the money. It was that the contract negotiation forced both parties to say what they actually wanted. Input-based contracts let everyone avoid that conversation. The buyer said "process our invoices" and hoped the provider would work out what mattered. Outcome contracts require specifying, in writing, what good performance means — and that specification is frequently the first time the buying organization has articulated it internally. Several organizations reported that the exercise improved their own operations before any provider did anything, simply because defining the outcome exposed processes nobody could describe and metrics nobody agreed on. That is a real benefit and it is available regardless of which pricing model you ultimately choose.
The AI Version of the Same Question
The pricing conversation has returned in a much sharper form, because AI-enabled providers have a direct interest in it. A provider deploying automation across a process it is paid for per transaction is destroying its own revenue. A provider paid for the outcome is doing the opposite. As automation capability improves, input-based pricing becomes actively adversarial: the buyer wants the work eliminated and the supplier's economics depend on it continuing. Which means the measurement problems described above are no longer optional to solve. Organizations that cannot define and measure outcomes will keep buying effort in a market where effort is being automated away, and they will pay human-equivalent rates for machine-delivered work — a margin transfer that is already happening quietly across the industry. The discipline required is unchanged from 2011: controllability, baselines, balanced metrics, measurement mechanics, and honesty about your own dependencies. The cost of skipping it has gone up considerably.
Common Questions
What is outcome-based outsourcing?
A contracting model that pays for results — resolved queries, collected cash, improved cycle time — rather than for inputs such as hours worked or transactions processed, aligning the provider's revenue with the buyer's objective.
Why are outcome-based contracts difficult to implement?
Because of measurement: attributing improvement to the provider rather than other causes, agreeing a baseline both parties accept, handling outcomes that depend on factors the provider does not control, and preventing metric gaming.
When do outcome-based contracts work best?
When the provider controls most of the process chain, the underlying data is already trusted by both parties, the metric set contains measures that pull against each other, and there is an agreed mechanism to renegotiate targets as circumstances change.
How does automation change outsourcing pricing?
It makes input-based pricing adversarial. A provider paid per transaction loses revenue by automating work, while a provider paid for outcomes profits from it — so buyers who cannot measure outcomes risk paying human rates for automated delivery.
Contract Model Review — Outpace works out which of your outsourced processes can fairly be paid for by result, builds the measurement both sides will accept, and stops you paying human rates for automated work.