Ask a small company why its machine-learning project disappointed and you will often hear about data, models or budgets. Look closer and the first mistake was usually earlier and simpler: the request handed to the contractor said something like “use AI to improve our operations.” That sentence cannot be built, tested or paid for. This explainer shows, in plain language, how to write an AI project request that a builder can actually act on, and why the evidence from stalled projects points to the same missing ingredients every time.
Defining the request before you ask for help
Treat the request as the written answer to one question: “What should be different on the day this work is finished?” It is not a technical specification, and you do not need to name an algorithm. It is also not a wish list of everything an intelligent system might one day do. It is a short page that the person doing the work reads before they suggest an approach.
The reason this matters more for machine learning than for ordinary software is uncertainty. A normal feature either exists or it does not. A model gives answers that are right some of the time, so someone must decide in advance how often “right” is good enough. If nobody writes that down, the builder will pick a number that flatters the result, and the buyer will judge by a gut feeling after the invoice arrives.
The five parts that decide the outcome
The decision or task being supported
Start with the human activity. “Reduce the time the support team spends sorting incoming tickets” is clear. “Add intelligence to ticketing” is not. Name who does the task now, how long it takes and what happens when it goes wrong. If you have seen an example such as how algorithms are helping firms make better calls, notice that every good example begins with a specific decision, not with a technology.
The inputs you can really supply
Say what data exists, where it lives, how clean it is and whether you are allowed to share it. Admit the gaps. A builder who learns in week one that half the records have no label can adjust the plan; one who learns it in week six will quietly lower the target. If the input is images, text or sensor readings, give two or three real samples, with sensitive details removed.
The target, written as a test
Write the acceptance test before any work begins. For instance: “On a set of two hundred past tickets that the team has already sorted by hand, the system should place the right category first at least as often as a new colleague would, and it must never send a billing complaint to the sales queue.” Notice what this sentence does. It names the test set, a comparison point and a failure that is unacceptable. The builder can now measure, and the buyer can now check.
The limits
Limits are the constraints that shape every technical choice: the budget range, the deadline, where the data may be stored, response time, who must be able to read an explanation of a result, and what happens when the system is unsure. A one-line note such as “when confidence is low, route to a person” changes the design far more than a paragraph of enthusiasm.
What happens at hand-over
Models degrade as the world shifts, so ask for a handover that includes the test set, a short description of how the model was built, instructions for retraining and a named person who can answer questions. Otherwise you own a black box that nobody can touch.
What the pattern of failed projects looks like
Project reviews published by practitioners, along with plenty of informal accounts, point to a handful of recurring causes. These are patterns, not measured percentages, so treat them as a checklist rather than a ranking.
- The goal was a technology (“add a chatbot”) rather than an outcome (“answer the common delivery questions without a queue”).
- No baseline existed, so nobody knew whether the result was better than the current process.
- The test data differed from real traffic, which made early results look better than live ones.
- Success was judged by impressions from a demo, not by a pre-agreed measurement.
- Nobody owned the system after launch.
Every item on that list is a hole in the written request. Fill the holes and the failures become less likely, though never impossible.
A before-and-after you can borrow
Before: “We want to use AI to forecast demand and cut waste.”
After: “We run a regional bakery chain. Today a manager guesses next-day quantities for each product from experience. We want a daily suggestion per product per shop, delivered by seven in the morning. We hold roughly two years of daily sales in spreadsheets, with gaps during renovation weeks. Done means the suggestions beat the managers’ own guesses on the last ninety days of history, never recommend zero for a bestseller, and can be explained in a sentence a shop manager will accept. Budget range and a working date for a first trial are attached.”
The second version tells a builder which question to answer, with what material, to what standard. It also tells them what not to build: there is no mention of a dashboard, an app or a grand platform.
Common questions, answered briefly
Do I need to know which method to use? No. Describing the problem and the test is your job; choosing the method is theirs. A good builder will propose an approach in response to the brief and may point out where a simple rule would do the job.
What if I cannot define “good enough”? Then run a short exercise first. Have two people label a small sample by hand and see how often they agree with each other. That agreement rate is a realistic ceiling for any system, and it gives you a defensible target. The explainer on how computers sort images into classes touches on why that human disagreement matters.
Should the brief mention money? Yes, as a range. It prevents proposals that are either unaffordable or oversized, and it lets the builder tell you honestly what fits.
How long should it be? One page. If it spills over, the project probably needs splitting.
Where to send the request
With the page written, you need people to read it. Some teams use their own network or an agency; others look at marketplaces. ProfessNow lets you search by profession and city, look at the profiles on offer and send a booking request, which is a convenient place to paste a brief when you want to reach technology specialists near you. Whichever route you take, the brief does the heavy lifting: it lets a stranger understand the job in a couple of minutes and answer with specifics.
Reading the answers you get back
A brief also gives you a lens for replies. Check whether each response restates your goal in its own words, mentions your test, asks about the gaps you admitted and says what it needs from you. A reply that talks only about the supplier’s own technology has probably not engaged with the page. Prediction work in particular is full of confident language; the primer on how software guesses what comes next is a reminder that every forecast carries an error, and your brief is where you state how much error you can live with.
A short template
- One sentence: the task or decision, and who does it today.
- Two sentences: what data exists, where, and its known flaws.
- One sentence: the acceptance test, with a baseline and one failure that must not occur.
- One line each: budget range, first-trial date, data-handling limits.
- One sentence: who owns the result after hand-over.
The bottom line
Machine learning feels like magic from the outside, which is exactly why plain writing helps. A page that says what changes, with which material, judged by what test and handed to whom, turns a vague hope into a piece of work someone can finish. Write it first, share it freely and keep it as the yardstick you return to when enthusiasm or doubt creeps in mid-project.