How to Write an AI Project Proposal That Gets Signed

An AI project proposal needs one thing a normal software proposal does not: a written definition of "good enough" with a number attached. Everything else in the document is standard consulting practice. That single section is why most AI proposals turn into unpaid research projects, because a client who has not agreed to an accuracy target will keep asking for one more improvement, and you will keep supplying it for free.

This is the skeleton I would put in front of a client, section by section, with the language that actually does work.

The seven sections, and what each is for

Everything below is those sections in order. Skip the cover page.

1. State their problem before your solution

Open with the problem in the client's own vocabulary, including the numbers they gave you on the call. "Your two support staff spend roughly four hours a day answering the same 30 or so questions about order status, sizing and returns" is worth more than any capability list, because it proves you were listening and it anchors everything that follows to a cost they already feel.

If you cannot write this paragraph with real numbers, you have not had a good enough discovery call. Go back and get them. A proposal built on a vague problem statement will be priced wrong in one direction or the other.

2. Describe the deliverable in nouns, not adjectives

Say what exists at the end. "A chat widget on your product pages that answers questions from your existing help centre articles and hands off to email when it cannot" is a deliverable. "An intelligent customer support solution" is a mood.

Then, immediately, list what is not included. This is the single highest-return paragraph in the document. For the example above: no changes to your help centre content, no phone or WhatsApp channel, no integration with your order system, no multilingual support. Every one of those is a real project someone will assume is included unless you say otherwise.

3. Define "working" with a number

Here is where AI work diverges from ordinary builds. A checkout button either works or it does not. A model that answers customer questions is right most of the time, and "most" is exactly what you and the client are about to disagree on.

So write the acceptance criteria as a test you can run in front of them:

• A test set, agreed in advance. "We will assemble 100 real customer questions from your last three months of emails. You approve the list before development starts."

• A pass threshold. "The system answers at least 85 of those 100 correctly, judged by your support lead. Correct means factually accurate and consistent with your policies."

• A defined failure behaviour. "For the remainder, the system says it does not know and offers a handoff. Confidently wrong answers count as failures, not as near misses."

• Who judges. Name the person. If it is a committee, expect the target to move.

That last bullet matters more than it looks. The failure mode of AI projects is not a system that scores 70 percent, it is a system that scores 88 percent while the client points at the 12 and asks why it is not fixed yet. A written threshold turns that conversation from a disagreement into an invoice.

If you want the underlying mechanics of why models are wrong in the way they are, AI hallucinations explains what you are actually promising to bound.

4. Write the assumptions section like a lawyer

Assumptions move risk off your side of the table for things you genuinely cannot control. Keep them short, specific and boring:

• Client provides the 100-question test set within five working days of kickoff.

• Existing help centre content is accurate and current. Correcting source content is out of scope.

• Client provides API access to their site or a staging environment by week one.

• Model provider pricing and availability remain broadly as at the proposal date.

• One named person has authority to approve the test set and sign off delivery.

Each of those is a real project killer, and each one, written down, converts "the project slipped" into "the project slipped because item three arrived in week four." That is a very different conversation.

5. Milestones that pay you as you go

Three payments is the usual shape for a project under about 12 weeks:

Weight it toward the front. AI projects front-load the effort in data preparation and evaluation, and a 10 percent deposit does not cover the two weeks you will spend before anything is visible.

Attach a date to each milestone, not a duration. "Week 3" invites argument about when week one started.

6. Price it against their number, then explain what changes it

Your price comes from the value in section one, not from your hours. If four support hours a day cost them roughly 60,000 a year, a 12,000 project is an easy conversation and 3,000 is leaving money on the table. The full reasoning behind that is in how to charge for an AI automation project, which is worth reading before you write a number down.

Then add the change-control line, in plain language:

"This price covers the scope above. Anything added after the test set is agreed is quoted separately as a change, at 150 per hour, and we will tell you the cost before we do the work."

Two effects. Clients stop asking for small additions casually, and when they do ask, you have a pre-agreed mechanism instead of an awkward negotiation.

Also state your ongoing cost assumption explicitly, because AI projects have a running bill the client will otherwise discover in month two: "Estimated model API cost at your current volume is 40 to 90 per month, billed to your own provider account." Put it in their name, not yours. Costs you can manage down over time, but not if you have absorbed them silently.

7. Say what happens after delivery

One paragraph. Support window, what maintenance means, and what the retainer costs. "Thirty days of bug fixes included. After that, ongoing tuning, monitoring and content updates are 500 per month." Half the value of an AI build is in the tuning that follows, and the proposal is the cheapest place to establish that this is a normal expectation rather than an upsell. For the terms that clause should actually commit to, see how to write an AI maintenance and support contract.

A note on disclosure

If your delivery leans heavily on AI tools, decide in advance how you are handling that in the document. Most clients now assume it and a few care a great deal. The argument for saying it plainly is covered in whether to tell clients you use AI. What matters for the proposal is consistency: the version of your process described in the document should be the version you actually run.

Where project work sits against the other ways of earning from AI, and what it does and does not scale into, is laid out in AI monetization strategies.

Not every engagement should be scoped as a one-off. If the relationship is ongoing, see how to price an AI agency retainer for a different pricing model built around capped, recurring scope.

FAQ

How long should an AI project proposal be?

Two to four pages for a project under about 20,000. Longer proposals do not win more work, they just take longer to read. The acceptance criteria section is the one place worth spending extra words.

Should I include the technical approach?

A short paragraph, and only where it affects the client's risk or cost. Which model provider you use matters to them because it determines the running bill and where their data goes. Your retrieval architecture does not. Detailed technical design in a proposal invites a client to negotiate implementation choices they are not equipped to evaluate.

What if the client will not agree to an accuracy threshold?

Treat that as information. A client who will not define "working" before you start is a client who will define it after you finish, which means they define it. Offer a small paid discovery phase instead: build the test set together, run a baseline, and price the full project once you both know what is achievable.

Should I offer a money-back guarantee?

Rarely, and never on accuracy. If you want a confidence signal, guarantee the milestone structure instead: if the prototype misses the agreed threshold at milestone two, the client can stop there and owes nothing further. That is a real risk transfer you can actually price, and it is far safer than promising a result that depends on their data quality.

How do I handle a client who wants to compare proposals on price?

Make the comparison hard on purpose by being the only one with a written threshold. A cheaper proposal without acceptance criteria is not cheaper, it is undefined, and saying that in one sentence during the follow-up call is usually enough. This is the same positioning logic that runs through selling AI services to local businesses.