What should an AI automation proposal include? At minimum: your problem expressed as a baseline number, a precise scope with explicit exclusions, a description of what the system will actually do in your systems (not just what it will "know"), what happens when it fails, how success will be measured, who specifically will build it, a full price including maintenance, and who owns the result. If any of those are missing, the gap is where your project will go wrong.
Most failed AI automation projects we are asked to rescue were visible in the proposal before anyone signed. This checklist is written for business owners who are not technical, are comparing two or three quotes that look nothing alike, and want to know which one describes something real.
| Metric | 2026 Benchmark |
|---|---|
| Sections a complete proposal covers | 12 |
| GenAI projects Gartner expected to be abandoned after proof of concept | 30%+ by end of 2025 (forecast) |
| Causes Gartner named | Data quality, risk controls, cost, unclear value |
| Our scoped pilot range, for comparison | $5,000 to $15,000 |
| US admin labour cost (BLS, May 2025) | $22.86/hour, $47,540/year base pay |
Why the Proposal Matters More for AI Than for Ordinary Software
In an ordinary software project, a vague proposal leads to arguments about features. In an AI automation project, a vague proposal leads to something worse: a system that works in the demo, fails on real work, and leaves nobody contractually responsible for the gap.
Gartner predicted in July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, naming poor data quality, inadequate risk controls, escalating costs and unclear business value. That was a forecast, not a count. But look at the four causes: every one of them can be addressed, or ignored, in the proposal.
There is a second, newer reason to read proposals carefully. AI-assisted development has made it cheap to produce something that looks finished. A polished dashboard and a convincing demo can now be built by someone who could not debug the system, extend it, or explain what it does when an input is unexpected. The demo has stopped being evidence of competence. The proposal is now where competence shows.
The Twelve Things a Good AI Automation Proposal Must Include
- 01The problem and the baseline
Your workflow, today's hours and errors, in numbers.
- 02Scope and exclusions
What will be built, and what explicitly will not.
- 03What the system does
Which systems it reads, writes and acts in.
- 04When it fails
Fallbacks, human approval, logging.
- 05Success measures
The numbers that decide whether it worked.
- 06Timeline, team, price, ownership
Phases, named people, total cost, who owns what, and what happens after launch.
1. Your problem, expressed as a baseline
The proposal should restate your workflow and put numbers on today's performance: hours spent, volume, error rate, cost. If it does not, nobody will be able to say later whether the project worked. A proposal that skips the baseline is often one that does not want to be measured.
2. Scope, with explicit exclusions
What will be built, in specific terms, and what will not. "Automate invoice processing" is not a scope. "Read supplier invoices arriving in accounts@, match them to purchase orders in Xero, post matched invoices as drafts, and send mismatches to the finance manager; credit notes and foreign-currency invoices are out of scope" is a scope. Exclusions protect both sides.
3. What the system does, not just what it knows
This is the single most revealing section. A weak proposal describes the documents the AI will be "trained on," the knowledge it will "have," and the questions it can "answer." A strong proposal names the systems the automation will read from, the systems it will write to, and the actions it will take.
There is a recognisable pattern behind many products sold as "AI agents": a database, an AI model key, your documents loaded into a search index, and a simple interface on top, renamed for whatever industry is being sold to. That pattern is genuinely useful for searching documents. It is not an automation, because it does not act. If the proposal never says what the system does, that is probably what you are being sold.
Ask: why can Copilot or ChatGPT not do this?
Every good proposal should answer this question in a sentence, and the answer should be specific: it runs on every new document without anyone asking, it writes into a system the assistants cannot reach, it checks records against each other, it runs at a volume nobody would paste into a chat, or it keeps data on your own infrastructure. If the vendor cannot say which, the project may be something your existing subscription already does.
4. What happens when it fails
Every AI system will produce wrong outputs sometimes. Language models are non-deterministic, and a perfectly formatted answer can be wrong. A good proposal describes what happens then: how outputs are checked against your business rules before any action, which actions need human approval, where uncertain cases go, and how everything is logged. If the proposal implies the system will not make mistakes, that is the clearest warning sign on the page.
5. Success measures and acceptance criteria
How you will both decide the project worked, in numbers. For example: "95% of matched invoices posted without human edits over a four-week period, with all mismatches routed correctly." Each deliverable should have criteria you can check, not "a working system."
6. A definition of a correct output, agreed by your people
Closely related, and often skipped: the people in your business who will judge the result need to agree in advance what a correct output looks like. The most expensive post-launch complaint is "it is working as designed, but it is not what we wanted." A proposal should either include this definition or schedule the session that produces it.
7. Testing before live data
The proposal should describe a sandbox or test phase before the system touches your live CRM, accounts or customers, and a period of real cases with human approval before it runs unsupervised. We have been brought in after agents wrote bad data into live systems during what was supposed to be testing. It is cheap to prevent and expensive to clean up.
8. A timeline in phases
Not just an end date. Discovery and access, build, real-case testing, go-live, measurement. A single workflow typically takes four to six weeks to reach reliable production; a two-week date for that usually means testing has been left out. See how long AI automation takes to implement.
9. Named people
Who specifically will build this, and can you speak to them before signing? Is the senior person from the sales call involved in delivery, or only in sales? Is any work subcontracted? The worst projects have three layers between your problem and the engineer solving it.
10. Your responsibilities
What the vendor needs from you, and by when: system access, credentials, sample data, a decision-maker who replies within a day. Most delays come from the client side, and an honest proposal says so up front rather than blaming you later.
11. Full price, including what happens after launch
The build price, any per-use costs (model usage, connector subscriptions, hosting), and maintenance. Automations need ongoing care: vendors change their software, new edge cases appear, and someone has to watch the exceptions. A proposal without maintenance terms is a quote for half the cost.
12. Ownership and exit
Who owns the code, the configuration, the prompts and the data? Can you take it to another vendor or bring it in-house? Where does it run, and under whose account? You should be able to leave without rebuilding from scratch.
Red Flags That Signal a Bad AI Automation Proposal
- It describes knowledge, not actions. "Trained on your documents" with no mention of which systems it writes to.
- There is no failure handling. Nothing about checks, approvals, fallbacks or logs.
- There is no baseline and no success measure. Nobody will ever be able to say it did not work.
- There is no named technical lead. Just "our team."
- There is no maintenance section. The price covers building, not running.
- The timeline is suspiciously short for production use, with no testing phase.
- It sells what your subscription already does. Drafting emails, summarising meetings and documents, writing first drafts and answering questions about files in Microsoft 365 or Google Drive all come with Copilot, Gemini, ChatGPT or Claude business plans. A proposal whose main deliverable is one of these is charging you to rebuild a feature you can switch on.
- Every case study has the same architecture with a different industry label.
Two questions that test a proposal in one meeting
You do not need to understand the answers in depth. You only need to notice whether they come back immediately and specifically, or slowly and vaguely.
A retrieval tool talks about the prompt. A real automation describes the fallback path and who gets alerted.
Someone who has built this answers in one specific sentence. Someone who has not gives a general reassurance.
"What does the system do when it cannot find a relevant answer?" Someone selling a document search tool will talk about prompt wording. Someone who has built a real automation will describe the fallback path: what the system does next, who is alerted, and how it is logged.
"What happens if the AI returns a malformed result halfway through a multi-step task?" A builder answers in one specific sentence about validation and retries. A seller gives a general reassurance.
We list more questions like these in how to tell if an AI agency can actually build it.
Check whether the proposal says what the system does in your systems. If not, it is likely a document search tool. Then check for failure handling, a baseline with success measures, named builders, and maintenance terms. Any missing item goes back to the vendor as a question before signing. A proposal with all of them can be compared on price.
How to Compare Two AI Automation Proposals That Look Nothing Alike
Proposals for the same workflow can differ by several times in price, and both can be honest. The difference usually comes from what each vendor discovered about your systems, or did not bother to discover. Put them side by side on the same grid:
| Compare | Proposal A | Proposal B |
|---|---|---|
| Did they look at your systems before quoting? | ||
| Baseline stated in numbers? | ||
| Systems read from and written to, named? | ||
| Failure handling and approvals described? | ||
| Success measures you can check? | ||
| Sandbox and real-case testing phase? | ||
| Named technical lead you have spoken to? | ||
| Maintenance terms and cost? | ||
| You own the code and configuration? | ||
| Total first-year cost, including running costs? |
A cheaper proposal with several empty rows is not cheaper. It has moved the cost to later, when it is harder to negotiate. A quote given before anyone looked at your systems is close to meaningless, which is why serious vendors will not give one.
Human Hours vs Automation: What a Proposal's ROI Section Should Look Like
A good proposal prices the work both ways, with assumptions you can check. Here is what that section should look like, using illustrative figures rather than any client's numbers.
The assumptions. The workflow takes 15 hours a week by hand at $22.86 an hour (BLS, May 2025, administrative assistants, base pay), so 780 hours and about $17,800 a year. After automation, 15% of the hours remain for review and exceptions: 117 hours, about $2,680 a year. The build is $10,000, the middle of a typical pilot range, plus maintenance.
| By hand | After automation | |
|---|---|---|
| Hours per year | 780 | ~117 |
| Cost per year | ~$17,800 | ~$2,680 plus maintenance |
| Year-one total including build | ~$17,800 | ~$12,680 plus maintenance |
| Year-two total | ~$17,800 | ~$2,680 plus maintenance |
What a proposal should also state: the maintenance cost as a number, the assumptions labelled as assumptions, and what the numbers leave out (speed, error reduction) without inventing a price for them. If a proposal claims savings with no arithmetic behind them, ask for it. Run your own version through the ROI calculator or the hire vs automate calculator.
What We Put in Our Own Proposals
It is fair to be held to the same checklist. Our proposals state your baseline in numbers, name the systems the automation reads and writes, describe the failure handling and approval steps, set acceptance criteria, schedule a sandbox phase and a real-case phase, give a phased timeline, name who will do the work, list what we need from you, price maintenance separately, and confirm that you own what we build. Our founder is on the discovery call and stays involved through delivery.
We also say, in the first conversation, when a project should not be bought: when a free template or a no-code setup will do the job, or when the workflow is too rare to repay a build. Our pricing page publishes our tiers, the automation quote tool gives a scoped estimate, and our AI automation development service explains how a project runs.
Free resources. Before comparing proposals, run your own baseline through the calculators on our free tools hub, and check our free automation templates. If a verified template already does the job, no proposal is needed. Where a proposal includes private AI, our free AI models directory shows each model's licence and hardware needs, so you can check the vendor's choice.
The Competitor Pulse Check
| Factor | A Strong Proposal | A Weak Proposal |
|---|---|---|
| Problem | Baseline in numbers | "Improve efficiency" |
| Capability | Systems it reads, writes and acts in | What it is "trained on" |
| Failure | Checks, approvals, fallbacks, logs | Not mentioned |
| Success | Measurable acceptance criteria | "A working solution" |
| People | Named technical lead | "Our team" |
| After launch | Maintenance priced | Handover |
| Ownership | You own code and configuration | Unclear or vendor-held |
| Overlap with Copilot, ChatGPT or Gemini | Says why a built-in assistant cannot do this | Sells drafting or summarising you already pay for |
Frequently Asked Questions
What should an AI automation proposal include?
An AI automation proposal should include your workflow's baseline in numbers, a precise scope with exclusions, the systems the automation will read and write, failure handling and approvals, measurable success criteria, a testing phase before live data, a phased timeline, named builders, your responsibilities, full pricing including maintenance, and code and data ownership.
How do I compare AI automation proposals?
Compare AI automation proposals on the same grid: whether the vendor looked at your systems, whether a baseline and success measures are stated, what the system actually does, how failures are handled, who will build it, maintenance terms, ownership, and total first-year cost including running costs.
What are the red flags in an AI automation proposal?
Red flags include describing what the AI knows rather than what it does, no failure handling, no baseline or success measure, no named technical lead, no maintenance terms, a timeline with no testing phase, and case studies that all share the same architecture with different industry labels.
Should an AI automation proposal include maintenance?
Yes. Automations need ongoing maintenance because connected software changes, new edge cases appear and exceptions need watching. A proposal that prices only the build is quoting part of the cost, so ask for maintenance terms and costs in writing before signing.
Who should own the code in an AI automation project?
The business paying for the automation should normally own the code, configuration and prompts, and control its own data and accounts, so it can move to another vendor or bring the work in-house without rebuilding. Confirm this explicitly in the proposal.
How do I know if an AI automation agency is legitimate?
A legitimate AI automation agency looks at your systems before quoting, names the person who will build your project and lets you speak to them, describes what the system does and how it fails, publishes or clearly states its pricing, and answers technical questions specifically rather than with general reassurance.
What's Next
Print the comparison grid, fill it in for every proposal you have, and send the empty rows back to the vendor as questions. Their answers will tell you more than their demo did.
→ Read the complete AI for small business guide.
→ Use our wider checklist in how to choose an AI automation company.
→ Or talk to us, and hold our proposal to this list.
Muhammad Kashif is co-founder of ValueStreamAI, leading technical delivery and AI strategy. He designs and ships custom agentic AI and healthcare automation systems for clients across the US and UK. More about Muhammad Kashif →