Choosing a contract model for AI, data and automation work

Why the contract model matters

The contract model decides who carries the risk when the work turns out harder than expected, and AI, data and automation work often does. Data is messier than the sample suggested. A model reaches the required accuracy later than planned. A process has exceptions nobody listed. The model also sets what the provider is paid for, and people work towards what they are paid for.

Three models cover most of this work: time-and-materials, outcome-based and build-operate-transfer. Data Prophets works under all three, and each suits a different kind of work. This guide leaves out prices, rates and legal terms. Those depend on your circumstances and need your own commercial and legal advisers.

Time-and-materials

Under time-and-materials you pay for the people and the time they spend. The scope can change as you learn, and the provider is paid for effort, whatever the result.

It suits work where the path is unclear at the start: discovery, a first use case on untested data, research-heavy model building, or a team that extends your own and takes direction from your managers.

The risk sits mostly with you. If the work takes longer, you pay for longer. The provider risks little beyond the relationship. You manage that risk by managing the work: short cycles, a working release at the end of each, a budget checkpoint at set intervals and a named person on your side who sets priorities.

• Suits uncertain or changing scope
• Client carries cost and duration risk
• Provider carries little delivery risk
• Control through short cycles and checkpoints

Outcome-based

Under an outcome-based contract, payment depends in whole or in part on a result: cases processed without manual touch, hours removed from a process, an accuracy level reached and held. The provider decides how to get there.

It suits work where the result can be measured, the starting point is known and the provider controls most of what determines success. Automation of a stable, high-volume process is the typical case. It fits poorly with exploratory work, where nobody can honestly promise a result.

The risk moves to the provider, who may do the work and miss the target. Providers allow for that risk in what they propose, and they will resist scope changes, because every change threatens the outcome. Your risk is of a different kind: an outcome defined badly can be met on paper while the business gains little.

• Suits measurable, stable work
• Provider carries delivery risk
• Client carries the risk of a poor definition
• Scope changes become harder

What an outcome-based contract must define

Three definitions carry the contract. The first is the baseline: the measured state before the work begins, taken over a period long enough to include peaks, and agreed by both sides in writing. Without a baseline, every later conversation becomes an argument about where you started.

The second is the measure: one or two numbers, the source system they come from, who calculates them and how often. Pick a measure that cannot be improved by harming something else. If speed is the measure, add a quality floor.

The third is control of the inputs. The provider can answer for a result only if it controls what drives it. List what you must supply and by when: data access, system changes, test users, decisions. Say what happens to the target if volumes shift, a source system changes or your side delivers late. Agree too how long the result must hold before it counts, and how disagreements about the numbers are settled.

• An agreed, measured baseline
• One or two measures with a named source
• A list of inputs each side controls
• Rules for changed conditions
• A period the result must hold

Build-operate-transfer

Under build-operate-transfer (BOT), a provider builds a team or centre for you, runs it for an agreed period and then transfers the people and operations to you. You are contracting for a capability you will own, and for delivery in the meantime.

It suits a long-term need for a sizeable team, such as a global capability centre or an AI centre of excellence, where you want ownership and lack the local hiring reach or leadership to start alone. Data Prophets has built and handed over two such centres, each with 80+ people.

The provider carries the hiring and operating risk during the first phases, and the risk of investing in a team it then gives up. You carry a commitment longer than a project, and transfer risk: whether the people stay, and whether the centre works as well under your management. The contract should define what transfers, the conditions that trigger transfer and the support after it.

Warning signs in each model

In time-and-materials, watch for months of activity with no working release, a team that grows without a matching plan, and status reports that describe effort in place of results.

In outcome-based work, be wary of a provider who accepts a target without asking to see the data or measure the baseline. Other signs are a measure only the provider can calculate, and a long list of exclusions that removes most real cases.

In BOT, the signs are vague transfer terms, hiring done without your involvement, and a centre leader you have never met. If the operating team sits apart from your tools and practices, the transfer will feel like taking over a stranger's company.

• T&M: effort reported, nothing released
• Outcome: target accepted without a baseline
• Outcome: a measure only the provider can see
• BOT: vague transfer terms
• BOT: hiring without your involvement

How to choose, and how to combine

Match the model to how well the work can be defined. If you cannot yet describe the result, use time-and-materials with tight checkpoints. If you can measure the result and the provider controls the inputs, consider outcome-based. If you want to end up owning a team, look at BOT.

Models can run in sequence. A common pattern starts with a short time-and-materials phase to explore the data and take the baseline, then moves to an outcome-based phase once both sides know what is achievable. Whatever you choose, keep ownership of code, data and documentation explicit, and have your legal and commercial advisers review the terms.

What to do next

Write one paragraph on the work you want done: the result, how you would measure it and who controls the inputs. If you cannot fill in the measure, start with time-and-materials. If you can, take a baseline first. If you need a team you will own, draft the transfer terms before anything else.