According to Forrester’s For Service Providers, AI Giveth And AI Taketh Away, technology services are moving from labor-based pricing toward outputs and business results. The change means more service providers are accepting responsibility for whether an agreed result is delivered.
That makes measurement part of the deal. Before work starts, the buyer and provider need to agree on what success means, how it will be measured, which data counts, and what happens if they disagree.
The AIDE Institute calls this an evidence contract.
What is an outcome-based AI contract?
An outcome-based AI contract ties some or all of a provider’s fee to a defined result. That result might be a completed task, a faster workflow, a quality threshold, or a business outcome.
An evidence contract is the measurement section of that agreement. It defines the result, the starting point, the time period, the data source, and the process for reviewing or disputing the result.
This is different from a traditional time-and-materials contract. An hourly contract can show how much work was done. An outcome-based contract must also show that the promised result happened.
Forrester makes an important distinction. Outcome pricing fits work where the result can be measured and linked to the provider’s work. A capacity model is a better fit when the scope is still being discovered.
Forrester also reports that Infosys would rather decline deals built on productivity targets that do not make financial sense. Sharing risk does not make a weak target easier to prove.
Why do AI performance metrics need context?
Approved AIDE case evidence shows why one generic productivity measure is not enough.
CME Group’s work with Google Cloud includes two types of evidence. A controlled study measured a change in pull requests after the trial expanded. A separate survey recorded whether developers believed the tool improved their productivity.
The first measure tracks an observable work output. The second records how participants understood their own experience. Both are useful, but they support different contractual claims.
Huntington’s document-redaction work with AWS offers another model. The case identifies the amount of work, the production rate, and an accuracy threshold. Those details make the reported result easier to check. The case is hosted by the provider and coauthored with the customer, so that source relationship should remain visible.
An SLB provider case reports higher production and less manual work for a defined group of wells over a set period. The operator is not named, the setting is narrow, and the result is reported by the provider. Those limits matter when deciding whether the result applies elsewhere.
These cases come from separate evidence records. Their results are not combined or compared. They show that an AI outcome can be a work output, a participant’s view, a technical threshold, or an operating result. Each one needs different proof.
What should an outcome-based AI contract measure?
The contract should answer seven questions:
- What is the result? Name the exact output, operating change, or business result being purchased.
- What is the starting point? State the baseline, control group, forecast, or other comparison.
- What is included? Define the workflows, users, assets, transactions, and exclusions covered by the measure.
- When will it be measured? Set the start date, end date, and any later check for durability.
- Which data counts? Name the source records and say which party can inspect them.
- Who is responsible for other changes? Account for data quality, process changes, employee adoption, provider technology, and outside conditions.
- How will disputes be handled? Set the review, adjustment, and resolution process before payment is at risk.
These terms also make AI ROI claims easier to test. Time saved, cost changes, quality improvements, and business results each need a clear baseline and evidence source.
Who should agree on the evidence?
Measurement should not be left to the delivery team alone. Procurement, finance, legal, technology, and the business owner all have a role because the result affects price, risk, and operating decisions.
The level of detail should match the risk. A small pilot may need a simple acceptance test. A long managed-services agreement may need continuing data access, audit rights, adjustment rules, and a formal dispute process.
What this means for your boss or board
The approval question is whether a proposed AI result is clear enough to carry payment risk. Leadership should ask what result is being purchased, whether the provider can reasonably influence it, and what evidence will show whether it happened. An outcome model is a stronger fit when those answers are specific. If the work is still being discovered, a capacity model or bounded pilot may be easier to govern.
Suggested framing: “The decision before us is whether to link provider payment to a defined AI result. The evidence supports that approach where the result can be measured and linked to the provider’s work. We recommend agreeing on the baseline, data source, measurement period, attribution rules, and dispute process before approving the commercial model.”
What this means for your company
Pricing and measurement should be designed together. Procurement can define the commercial terms, finance can test the baseline and value logic, legal can set data and audit rights, technology can confirm the evidence is available, and the business owner can define the operating result. The contract should name those owners rather than leave measurement to the delivery team after work begins.
Suggested framing: “For the company, this means treating measurement as part of contract design. We should assign an owner for the baseline, source data, result review, and dispute process, then confirm that each owner can provide the required evidence before signing.”
What this means for your team
The team needs a practical evidence plan. Before delivery starts, document the covered workflow, users or assets, starting point, exclusions, source records, measurement dates, and review process. This gives the team a shared definition of success and makes it easier to identify whether a reported change came from the provider’s work, internal adoption, data quality, or another condition.
Suggested framing: “For our team, the next step is to complete the evidence plan before delivery begins. The business owner will define the result, the data owner will confirm the source records, and the delivery lead will document dependencies and exclusions. We will assess whether the agreed result occurred within the stated scope and period.”
What this means for your clients
Consultants should test evidence readiness before recommending an outcome-based AI contract. Start by asking whether the client has a credible baseline, inspectable data, a defined measurement period, and a way to separate the provider’s contribution from other changes. If those elements are missing, the first engagement may need to establish the evidence system or run a bounded pilot rather than transfer outcome risk immediately.
Suggested framing: “For your organization, this finding raises a practical question: can the proposed AI outcome be measured and linked to the provider’s work? We suggest starting with an evidence-readiness review of the baseline, data access, attribution dependencies, and dispute terms before committing payment to the result.”
These examples do not prove that outcome-based AI contracts work better than other pricing models. They do not independently verify every provider-reported result or make one case a universal benchmark. They show why the measurement rules belong in the contract before delivery begins.
Forrester identifies the move toward results. The evidence contract explains what must be proven before those results support a payment decision.
