When three project proposals land in your inbox, an AI automation proposal checklist helps you compare them. One is two pages. One is forty. One is a Loom video and a payment link. All three promise to save you 20 hours a week, and you can’t tell which one will actually deliver.
Writing these proposals is my job, and I’ve read plenty of other people’s, including the ones founders bring to me after a build went wrong. What separates a good one from a bad one is rarely the price or the tech. It’s what the document puts in writing.
This post covers the 12 things a good proposal always includes, why each one matters, and what to ask when something is missing. Use it on any quote before you sign, mine included.
Key Takeaways
- An AI automation proposal checklist tests what a quote commits to in writing, not how polished it looks or how many tools it names.
- A good proposal states your problem in your own numbers and records a baseline before any build starts, so results can be proven later.
- Success metrics need a named check-in date. Without one, a proposal can never fail, which also means it can never be shown to work.
- Scope must list what is out as clearly as what is in. Most blown budgets trace back to a vague line that both sides read differently.
- You should own the accounts, workflows, prompts and data from day one, with a written exit plan in case the relationship ends.
- Running costs belong on the page line by line: model usage, SMS, call minutes and platform fees each grow with volume in different ways.
- The proposal should explain what happens after launch, because the build is maybe a third of the work. Tuning and adoption are the rest.
- If a proposal skips human-in-the-loop points and failure handling, assume nobody has thought about what happens when the AI gets it wrong.
Why Most AI Automation Proposals Are Hard to Judge
Most proposals are written to win the deal, not to be held to later. That’s not always cynical. Plenty of builders really do believe the result will be great, so they fill the pages with the future and skip the dull parts that protect you.
Bad proposals tend to fall into three patterns. The first is the tool list: a page naming n8n, Make, ChatGPT and a dozen integrations, as if a pile of logos proves anything. The second is the vision deck, full of words like transformation and efficiency with nothing specific about your business. The third is the hours-saved promise, where “save 20 hours a week” appears on page one and is never explained.
None of those tells you what will actually happen on a Tuesday afternoon when a lead comes in and nobody is at the desk.
This matters more than it looks. An often-quoted MIT study found that around 95% of AI initiatives deliver no measurable return. The ones that work start with the process and the problem, and only then choose the technology. A proposal that opens with tools is showing you the builder has it the wrong way round.
So read every AI automation proposal as a contract in disguise. Each claim is either something you can check later or it’s decoration. If you’ve already been burned once, my piece on starting again after a bad AI vendor covers how to rebuild trust in the process without repeating the same mistakes.
The AI Automation Proposal Checklist, Part One: Problem and Proof
The first three items test whether the builder actually understands your business, and whether you’ll ever be able to prove the work paid off.
1. Your problem, stated in your numbers
A good proposal opens with your problem, not the builder’s solution. It should read as someone listened: how many enquiries you get a month, how long they wait for a reply, how many calls go to voicemail, how many hours your office manager spends retyping jobs into Xero.
If the problem section would fit just as well in a proposal for any other business, it’s generic. Generic means the discovery was shallow, and a shallow discovery gets you a build designed for someone else’s business.
Ask where the numbers came from. The honest answer is usually a mix of your CRM, your phone system and a conversation with you. Estimates are fine as long as they’re labelled as estimates.
2. A baseline measured before the build
Most proposals skip this one, and it’s the one that decides whether you’ll ever know the money was well spent. The current state should be measured and written down before anything gets built. Missed-call rate. Average response time to a web lead. Quotes sent against quotes followed up. Hours per week on one specific admin task.
When I worked with Dr Claire’s dental practice, the baseline was stark: 47% of calls went unanswered, even with two receptionists on the desk. After the voice AI went live, missed calls dropped to zero and booked appointments rose 44%. That result only means something because the starting number was written down first.
Without a baseline, every result becomes a matter of opinion. The builder says it’s working, you’re not sure, and nobody can settle it.
3. Success metrics with a date attached
A baseline tells you where you started. Success metrics tell you where you’re meant to end up, and by when. “Improve lead response” is not a metric. “Every web enquiry contacted within 90 seconds, 24 hours a day, measured at day 30 and day 90” is.
The date matters as much as the number. A proposal with no check-in date can never fail, which also means it can never be shown to work. I set a formal review at 90 days on every build, and I’ve written up what a 90-day AI automation checkpoint should cover if you want the full list.
Good metrics are usually boring: response time, answer rate, bookings, hours recovered, revenue from a reactivated list. If a proposal measures activity (messages sent, workflows built) instead of outcomes, push back.
Part Two: What Gets Built and How It Behaves
Items four to seven describe the build itself. Vague proposals do the most damage here, because a fuzzy description of the work lets each side picture something different.
4. Scope, including what’s out
Every proposal lists what’s included. Good ones list what’s excluded just as clearly. If the build covers new web leads but not the old leads sitting in your database, it should say so. If it handles SMS and email but not Facebook Messenger, that should be written down.
Most blown budgets come back to one ambiguous line. “Automate lead follow-up” could mean a single text message, or a six-week sequence across several channels that changes based on replies. You’ll assume the second. The builder quoted for the first.
Here’s a useful test. Read the scope out loud to someone on your team and ask what they think is being built. If their answer surprises you, the scope isn’t specific enough.
5. A workflow map with the human checkpoints marked
You should be able to follow what happens step by step, from trigger to finish. A lead fills in a form. The AI texts them within a minute and asks two qualifying questions. If they qualify, it offers times from your calendar. If they don’t, it tags them for a nurture sequence. A summary lands with your team.
It matters just as much where a person stays involved. Quotes over a certain value, replies to complaints, anything involving a refund: these usually need a human to approve them before they go out. A proposal that never mentions human approval steps hasn’t thought about what happens when the AI gets it wrong.
This doesn’t need to be a fancy diagram. A numbered list in plain English is often clearer. What matters is that nothing important happens out of sight. For a sense of what well-designed flows look like, I’ve collected some agentic workflow examples from real businesses.
6. Integrations with the tools you already run
The proposal should name every system the automation will touch: your CRM, calendar, accounting software, phone system, job management tool and inbox. For each one, it should say whether the automation reads from it, writes to it, or replaces it.
Replacement is the one to watch. Some builders quietly move you onto their preferred platform as part of the project. Sometimes that’s the right call. Moving onto one CRM like Nexus can be a real improvement when your leads currently live in three places. But you should make that decision knowingly, not find out in week three when your team can’t locate their contacts.
Ask what happens to each integration if the other software changes how it connects or what it charges. You don’t need a perfect answer. You just want to know someone has thought about it.
7. Testing, error handling and an audit trail
How will this be tested before it reaches a real customer? A good proposal describes a test phase on dummy data, then a pilot on a small share of real traffic, then a full rollout. It should cover edge cases too: the customer who replies in te reo Māori or Mandarin, the lead who gives a fake number, the caller who swears at the bot.
It should also explain what happens when something breaks. Who gets alerted, and how fast? Does the automation fail safely by handing over to a human, or does it keep firing messages into the void?
Finally, you want a record. Every message sent, every decision made and every call summary should be logged somewhere you can look at it. That’s how you catch problems early, and how you answer a customer who asks why they got a particular text. I’ve gone into more detail on why an AI audit trail matters for your business.
The AI Automation Proposal Checklist, Part Three: Money, Data and Ownership
Most founders skim this section, and it’s the one that causes the most regret later. Read it slowly.
8. Running costs, broken out line by line
The build fee is only part of the cost. AI automation has running costs that grow with use, and a good proposal separates them so you can see which ones will climb.
Typical lines include AI model usage from providers like OpenAI or Anthropic, SMS charges per message, voice minutes for AI phone calls, and platform or software subscriptions. Some costs are fixed. Others rise with every lead. A voice agent handling 200 calls a month costs a very different amount from one handling 2,000.
Ask for a worked example at your actual volumes, then at double. If the builder can’t estimate that, they haven’t built enough of these to know. Be wary of costs bundled into one monthly figure with no breakdown. That isn’t always a problem, but it makes it very hard to see what you’re paying for.
The fair comparison is the cost of doing nothing: one missed job, one lead lost to the competitor who answered first, one part-time hire you didn’t need. Weigh the running costs against that number.
9. Where your data lives and who can see it
Your automation will handle customer names, phone numbers, email addresses and probably conversation history. The proposal should say where that data is stored, which third parties process it, and who on the builder’s side can see it.
For NZ businesses, the Privacy Act 2020 still applies when an AI tool does the processing, and the Office of the Privacy Commissioner has published guidance on using AI with personal information. Australian businesses have similar obligations. You don’t need to become an expert, but the proposal should show the builder has thought it through.
Specifically, look for which country the servers are in, whether your data is used to train anyone’s models (it shouldn’t be), how long conversation logs are kept, and what happens to your data if you stop working together. If the build sends SMS, the proposal should also cover consent and opt-outs, because the Unsolicited Electronic Messages Act applies to commercial texts in New Zealand.
10. Ownership of the build and a written exit plan
Who owns what gets built? This catches people out more than anything else on the list.
The accounts should be yours. Your CRM, phone numbers, AI provider accounts and automation platform should all be in your business’s name, with the builder added as a user. The data should be yours too. And you should hold a copy of the prompts, workflows and configuration, so another competent person could pick them up.
The exit plan is the other half. If the relationship ends, what does the builder hand over, in what format, and within how many days? Do the phone numbers move with you? Does anything stop working the day you leave? A good partner is happy to put this in writing, because they expect you to stay for the value, not because you’re stuck.
This is also the part of the proposal worth showing your accountant or lawyer. My list of questions your accountant should ask about an AI automation contract pairs well with this checklist.
Part Four: What Happens After Launch
The build is maybe a third of the work. The rest is tuning, fixing, and getting your team to actually use the thing. A proposal that stops at go-live is selling you half a job.
11. Training, optimisation and support
AI systems drift. Customer questions change, your offer changes, a new staff member starts, a software update breaks an integration. Someone has to watch the system and adjust it.
A good proposal spells out what the ongoing training, optimisation and support covers. How often is performance reviewed? Who fixes the prompts when the AI gives a clunky answer? How fast will someone respond if the booking flow breaks at 7 pm on a Friday? What’s included, and what counts as new work?
Look for a set review rhythm (monthly is common) and a clear way to raise issues. Also look for signs the builder improves things without being asked. The best sign is a proposal that describes months two and three, not just the launch date.
12. An adoption plan for your team
The most common reason automations fail has nothing to do with the technology. The team doesn’t trust the system, doesn’t understand it, or quietly works around it. Your office manager keeps phoning every lead back by hand because nobody told them the AI already did.
A good proposal names who in your business owns the system day-to-day and how they’ll be trained. Expect a short handover session, simple written instructions for common tasks, and an easy way for staff to flag when the AI gets something wrong.
It should also be realistic about the first few weeks. At some point, the AI will say something odd or a handover will get missed. The proposal should treat that as expected and explain how it’ll be caught, not promise perfection from day one.
Conclusion
Use an AI automation proposal checklist to confirm the document is specific, measurable, and honest about what happens after the invoice is paid. It should connect your problem to your numbers, set a baseline and a date to check against, and define what’s out of scope. Costs and data handling should be clear, and ownership should stay with you.
Run every quote through these 12 items and the weak ones fall away fast. There’s a bigger point underneath, though. The best automations don’t work in isolation. They connect to a system that knows your business: an AI brain that holds your context and your numbers, and an AI workforce that does the work. Treat each automation as a one-off, and you end up with a dozen tools that don’t talk to each other. If that’s where you are, how AI automation works for $1M to $5M businesses is a good next read.
Want a Second Pair of Eyes?
If you’ve got a proposal on the table and you’re not sure it passes, book a 30-minute Discovery Call. Bring it with you. We’ll go through it against this checklist together; I’ll point out what’s missing, and I’ll tell you honestly whether it’s a good deal, even if it isn’t mine.
No pressure, no pitch deck. Just a straight conversation about what the work should look like for your business.
Frequently Asked Questions
What should an AI automation proposal include?
At minimum, a clear statement of your problem in your own numbers, a measured baseline, success metrics with a review date, a scope that lists what is excluded, a workflow map with human checkpoints, integrations, a testing plan, separated running costs, data handling details, ownership and exit terms, and a plan for support and team adoption after launch. If any of these are missing, ask for them in writing before you sign.
How long does an AI automation project usually take?
A single, well-scoped automation such as instant lead response or an AI receptionist often goes live in two to six weeks, including testing. Larger builds that connect several systems and capture how the business runs can take two to three months. The proposal should include a timeline with milestones, and you should expect a tuning period of four to eight weeks after launch while the system settles.
Should I own the automations an AI partner builds for me?
Yes. Your accounts, phone numbers, data and the configuration behind the automations should belong to your business, with the builder added as a user. That way you can change providers without starting again. Owning it does not mean running it yourself. Most founders still want someone to maintain and improve it, but the choice should always be yours.
How do I compare two AI automation quotes fairly?
Put them side by side against the same checklist instead of comparing the headline price. Check whether each one includes a baseline, measurable outcomes, a clear scope, separate running costs and ownership terms. Then ask both builders for a worked example of monthly costs at your real volumes. The cheaper quote often leaves out testing, support or integrations that the other one includes.
What ongoing costs come with AI automation?
Expect a mix of usage-based and fixed costs. Usage costs include AI model fees, SMS charges per message and voice minutes for phone agents, and all of them rise with volume. Fixed costs cover software subscriptions and any ongoing training, optimisation and support. A good proposal lists each line separately and estimates the total at your current volume and at double, so growth never surprises you.
What are the red flags in an AI automation proposal?
Watch for proposals that open with a list of tools, promise hours saved without explaining how, or have no measurable outcome and no review date. Other warning signs include accounts set up in the builder’s name, no mention of testing or human approval steps, bundled costs with no breakdown, and nothing written about what happens after launch or if you part ways.
Is it safe to give an AI provider access to my customer data?
It can be, as long as the proposal explains where the data is stored, which third parties process it, who can access it and how long it is kept. Your data should not be used to train anyone’s AI models. In New Zealand, the Privacy Act 2020 still applies when AI does the processing, so ask your builder how they meet those obligations.
About Octavius
Titus Mulquiney is the founder of Octavius AI, where he builds AI brains and AI workforces for founder-led businesses stuck running everything out of their own head. Twenty years in marketing, ex-Sony product manager, ex-GM Zeal NZ. Based in Auckland, working with operators across NZ, Australia, and the US. Connect on LinkedIn.