Why briefs for this go wrong
A brief for a website can describe pages. A machine learning brief has to describe an outcome whose feasibility nobody knows until the data is examined, which makes the usual format unhelpful.
The result is briefs that either specify a solution in technical terms nobody can price consistently, or state an ambition so broad that every supplier proposes something different.
Describe the decision, not the technique
The single most useful thing you can write is which recurring decision you want to improve, who makes it, how often, and what it costs when it goes wrong.
| Instead of | Write |
|---|---|
| We want a neural network for demand | We order stock 6 weeks ahead and are frequently short on fast movers |
| We need AI for customer service | Tickets take 4 hours to reach the right team and we want that shorter |
| We want predictive maintenance | Unplanned line stops cost us production and we want more warning |
| We need a recommendation engine | Customers buy one category and never discover the others |
The right column lets a supplier propose the appropriate approach, and sometimes tell you that a simpler thing solves it - which is information worth having before you spend.
Be specific about data
- Which systems hold the relevant data, and roughly how far back.
- Approximate volumes - orders per month, customers, jobs per year.
- Whether outcomes are recorded, and how reliably.
- Known quality problems you are already aware of.
- Whether a supplier can access a sample early, and under what terms.
That last point changes proposal quality more than anything else. A supplier who has seen a sample can quote with far less contingency, and a supplier who cannot will either pad the price or discover problems mid-project.
Say what success and failure look like
Define success in business terms - fewer stockouts, faster routing, less time spent - and state how it would be measured. If you cannot say how you would know it worked, that is worth resolving before starting.
Also state the constraints and the things that must not happen. Data that cannot leave your infrastructure, decisions that must remain with a person, explanation requirements, systems that cannot be modified. These shape the solution and are expensive to discover late.
Ask for a staged proposal
Nobody can responsibly quote a fixed price for an outcome that depends on data they have not seen. A brief that demands one gets either an inflated price or an optimistic one that will change.
Request a short, fixed-price first stage - data assessment and feasibility - with the larger build quoted after it. That gives you a decision point with real information, and a cheap exit if the data will not support the idea.
If a supplier quotes a fixed price for a model before seeing your data, they are pricing the risk, not the work.