AI Proposal: What to Read Before You Sign

An AI proposal is a promise written down before anyone has seen your data, so the useful part is not the price but the sentences that say what “done” means, who owns the exceptions, what is out of scope and what happens after delivery. If those four are vague, the price is a guess. I read proposals for a living, my own included, and these are the lines I read first.

Many buyers do it the other way round. They open the document, jump to the number, glance at the timeline and then compare two numbers that describe two different promises. This essay is about reading the rest of the document, because that is where a project is won or lost months before anyone writes a line of code.

What should an AI proposal include?

Strip away the logo, the methodology slide and the paragraph about the team, and a proposal that deserves a signature contains six things. A sentence that says what changes in your business when the project works. A definition of done you can test. A list of what is in and what is out. A list of assumptions, including what the supplier needs from you. A way of handling change. And a plan for the day after delivery.

I will take these in order, because most proposals I am shown carry the first one and a half. The outcome sentence is usually there, in marketing language. The definition of done is usually a verb: “deliver”, “implement”, “go live”. A verb is not a test.

The single best check I know is to read the outcome sentence aloud and ask whether a person who dislikes you could prove it false. “Improve customer service with AI” cannot be proven false, which is exactly why it is comfortable to write. “First-line replies to the twelve most common order questions are drafted by the system, and a person approves them in under thirty seconds” can be proven false on a Tuesday afternoon. Prefer the second kind of sentence, even when it is smaller. In my experience the smaller promise is the one that gets finished.

How do you set acceptance criteria for an AI project?

Traditional software has a luxury that AI work does not: the same input gives the same output, so “works” can be checked once. An AI system gives answers that are mostly right, and the interesting question is how mostly, on which cases, and who decides. That makes acceptance criteria for an AI project a different kind of document, and it is the part of a proposal I would spend the most time on if I were the buyer.

A usable criterion has four parts. A sample: a set of real cases from your own business, drawn before the project starts, not a supplier’s demo data. A measure: what counts as correct, written so that two people would score the same answer the same way. A threshold: the share of cases that must pass, ideally split between the easy majority and the awkward minority. And an owner: the person on your side who signs off, because a test nobody on your side will run is a test the supplier will end up running alone.

If the proposal says “we will agree the success measures during the project”, read it as “we will decide how good it needs to be once we know how good it is”. That sentence is not dishonest, but it moves the risk to you at the one moment you have the least information. I would rather have an argument about the threshold in week one than a quiet disagreement in week twelve. If you want to see what a measurement plan looks like, I wrote about it in what to measure in an AI pilot.

There is also a legitimate version of “we will agree it later”, and it is worth knowing so you can tell the two apart. Some projects genuinely cannot set a threshold until a small paid first phase has shown what the data looks like. A good proposal then says so, prices that phase separately, and names the decision at the end of it: continue, change course or stop. The difference is that the uncertainty has a date and a price on it.

Who owns the exceptions the proposal does not mention?

Every business process has a diagram and a reality. The diagram is the version everyone agreed on; the reality includes the customer who always pays late, the product that is sold in a bundle only to one wholesaler, and the order that the warehouse manager corrects by hand on Fridays. None of these appear in a proposal written from a first conversation, and all of them appear in the project.

So I look for a sentence that says who finds the exceptions and when. The honest version sounds like this: the supplier will sample a few hundred real cases in the first two weeks, list the exceptions it finds, and agree with you which ones the system handles, which ones go to a person and which ones are out of scope. The dishonest version is silence, which in practice means the exceptions turn up in testing and are renamed “change requests”. I described that pattern at more length in the exception list, and I still think it is the most useful document a project produces.

A related line: what does the system do when it is not sure? A proposal that never mentions the fallback path has not thought about the work. The answer does not need to be elaborate. “Low-confidence cases are routed to a named person with the draft attached” is a complete answer. “The model will handle it” is not.

What does an AI proposal quietly leave out?

The scope section tells you what is included. The useful reading is of what is missing, and in AI work the omissions follow a pattern. I check for six.

• Data preparation. Someone has to find, clean and connect the data. If the proposal assumes it arrives tidy, ask who tidies it and at what rate.
• Integration. Connecting to your accounting package, ERP or mailbox is often half the work. A proposal that says “integrates with your systems” without naming them has not looked at them.
• Running costs. Model usage, hosting and monitoring are bills that continue after delivery. They should appear as an estimate with the assumptions behind it, and as a line you can later check against reality.
• Testing on your data. Not a demo, but the sample from the acceptance criteria, run by the supplier and repeated after every significant change.

• People and training. The staff who will approve, correct and escalate. If nobody budgets their time, the system gets switched on and then quietly avoided.
• Security and data protection. Where the data goes, who processes it, and what the supplier does with it. If personal data is involved, this is not optional, and it belongs in the proposal, not in a later email.

For the pricing side of this, how fixed prices and hourly rates behave on projects like these, I would point you to the comparison of fixed and hourly AI pricing. My point here is narrower: a low price with a short scope list is not a low price. It is a different scope that happens to be printed in a smaller font.

How should an AI proposal handle changes?

Change is not a failure of a project, and a proposal that pretends otherwise is the first red flag. In AI work in particular, you learn things once the system meets real cases, and some of what you learn is that the original idea needs adjusting. The question is not whether change will happen but who tells whom, how early, and what it costs.

I look for three things. First, a duty to flag: the supplier says it will tell you as soon as it sees something that will cost more or take longer, before the work is done rather than after. Second, a rate: if scope grows, how is the extra work priced? A day rate stated in the proposal is more useful than a promise to be reasonable. Third, a decision point: at planned moments, such as the end of the first phase, you decide whether to continue, with enough information to say no.

From the supplier’s side I will add something I learned the expensive way. A proposal that is silent on change protects nobody. The client assumes everything they might later want is included, the supplier assumes nothing is, and the first disagreement arrives with both of them feeling cheated. Writing the change process down feels pessimistic. It is the opposite: it is what lets both sides stay on speaking terms when the project turns out to be bigger than the first conversation suggested.

What happens after delivery?

Look for the section titled “handover” or “support”, and if there is no such section, look for the sentence that would be in it. A system that goes live has an owner, a log, a way to see when it is getting worse, and a person who can change it. After delivery, who is that person? If the answer is “our team, on request”, then the project has a hidden dependency that will not show up as a line item until month fourteen.

Good proposals say what you receive at the end besides the working system: documentation a new person could follow, the test sample and the scoring method so you can re-run the acceptance test yourself, access to the code and configuration, and a named internal owner. I wrote about the supplier-side version of this in the lock-in problem nobody puts on the checklist: the best sign a project worked is that you no longer need the person who built it to keep it running. A proposal can promise that, or it can leave it out, and you can tell which by reading.

What are the red flags in an AI proposal?

Having read these from both sides of the table, I find the warning signs have become quite consistent. None of them is conclusive on its own, but three or more in one document is a conversation worth having before you sign anything.

• A guaranteed accuracy figure given before anyone has seen your data. A number promised without a sample is usually a number chosen to close the deal.
• No assumptions section. Every estimate rests on assumptions. If they are not written down, they are still there; you just cannot see them.
• The word “integrates” without a system name. It usually means nobody has looked yet.
• Effort described in weeks, outcome described in adjectives. “Robust, scalable, intelligent” cannot be tested. A number or a sample can.
• Nothing about what you must supply. AI projects need your time, your data and your decisions. A proposal that asks for none is either naive or planning to ask later.
• A demo in place of a plan. A demo shows the idea is possible. It does not show the work is survivable, and I have written before about the gap between demo and production.

How do you evaluate and compare AI proposals?

If you have two or three proposals, the temptation is to build a table with price, duration and a column of features. I would build a different table, with the supplier names across the top and these rows down the side: the outcome sentence, the test, the exception process, the exclusions, the change rules, the handover. Fill in each cell from the document, and where a cell is empty, write “not stated”. A proposal with five “not stated” cells is not cheaper than one with none; it is unfinished.

Then ask each supplier the same two questions, in writing, and compare how they answer. What would make your estimate wrong? What do you need from us in the first month? You are not looking for the right answer. You are looking at whether the answer is specific, whether it arrives without defensiveness, and whether it changes the proposal. A supplier who updates the document after a good question is telling you how the project will run.

For the conversation around price, which is a different thing from the document, I have collected what an AI consultant hears when you talk about price. And if the proposals feel too large to judge, that is often a sign the first step should be smaller; how to scope an AI proof of concept covers that. If you are still choosing who to ask for a proposal at all, start with what to ask before you hire an AI consultant.

What goes into my own proposals?

I will finish with what I try to do when I write one, partly to hold myself to it. The first page says in two or three sentences what will be different in your business if it works, and what will not change. The second page says how we will know, with the sample, the measure and the threshold, and says who on your side signs off. The scope list has an “out of scope” column that is as long as the “in scope” one. The assumptions are numbered, so we can refer to them when one proves wrong. The price has a short paragraph on what would move it, and by roughly how much.

It is not a proposal that wins every comparison. A shorter, more confident document with a lower number can look better next to it. But I have yet to see a project go badly because the proposal was too specific. I have seen plenty go badly because it was not, and the people involved were rarely careless. They had signed a sentence that meant something different to each side.

So before you sign, read it as you would read a contract with someone you want to still be working with in a year. Look for what is measurable, who is named, what is excluded and what happens next. If you would like a second opinion on a proposal you have received, that is a conversation I am glad to have, and it is part of what an AI consultant for SMEs is for: sometimes the useful answer is that the proposal is fine, and sometimes it is a list of five questions to send back.

Frequently asked questions