September 13, 2026 · 7 min read
How to Evaluate an AI Automation Proposal Before You Buy It
An automation proposal should make the work more understandable before it makes the work more technical.
If the proposal leads with model names, broad percentages, or a long software list but cannot explain the current workflow, the buyer is being asked to purchase confidence rather than evidence.
Use these questions before approving the work.
What exact workflow is in scope?
Ask for the trigger, endpoint, frequency, volume, systems, owners, and exceptions. “Automate bookkeeping” is not a scope. “Prepare store-level journal entries from an approved source file and route exceptions for review” is closer.
What is the verified baseline?
Request current touch time, cycle time, correction work, volume, and operating cost. Ask which numbers were measured, which were reported, and which were estimated. If the seller cannot distinguish capacity from cash savings, treat the ROI claim cautiously.
Why is this tool appropriate?
The proposal should compare the requirements of the workflow with the tool’s reliability, data handling, integration path, cost, and maintenance burden. Ask what simpler rules-based or native integration was considered before adding a model.
Where does human review remain?
Ask which actions proceed automatically, what threshold stops them, who approves material decisions, and who owns exceptions. Be especially careful around payments, accounting judgments, employment decisions, sensitive data, legal conclusions, and safety-critical actions.
What data leaves the business?
Request a plain-language data-flow diagram. Identify every vendor, what it receives, why it needs the data, how access is authenticated, whether the data is retained or used for training, and how the relationship can be terminated.
How will failure appear?
Silence is not monitoring. Ask how the system reports missing data, duplicates, partial completion, bad credentials, API outages, and model uncertainty. Require a manual fallback and a named person responsible for recovery.
How will the result be tested?
The test plan should cover the normal path and edge cases. Agree on acceptance criteria before launch. A live demonstration with one clean example is not an acceptance test.
Who owns the work?
The agreement should identify ownership of delivered code, configurations, documentation, accounts, credentials, and reusable consultant tools. Ask what happens if the relationship ends tomorrow. The business should be able to operate or replace the system without indefinite dependence on the original builder.
What will maintenance require?
Request a list of dependencies, expected recurring cost, update process, retesting triggers, and support terms. “No maintenance” is rarely credible when the workflow relies on external systems.
How will value be measured?
The proposal should name the baseline, measurement period, evidence owner, and limitations. Results from another client are context, not a guarantee.
Buyer checklist
- The current process is mapped.
- Baseline figures are labeled measured, reported, or estimated.
- Capacity is not presented as automatic cash savings.
- Data access and vendors are visible.
- Human approvals and exception owners are named.
- Edge cases, outages, and fallback are tested.
- Ownership and exit rights are written down.
- Maintenance costs and responsibilities are disclosed.
- Success will be measured over an agreed period.
A strong proposal should survive these questions. A good consultant should welcome them.
Ready to run your own workflow through this checklist? See Pricing and Every Service in Detail or request a quote.