Buyer checklist
A useful AI automation proposal should make the future workflow understandable before anyone builds it. It should define what happens, what does not happen, who remains responsible, how success will be tested, and how your team can operate or exit the system later.
That standard matters because an attractive demonstration is not the same as a dependable business process. A proposal can mention AI, integrations and dashboards yet leave the buyer to discover hidden usage costs, weak exception handling or unclear data responsibilities after implementation.
This checklist is for UK small-business owners and operations leaders comparing an agency, consultant or software-led automation proposal. It is practical procurement guidance, not legal advice. If the planned workflow makes significant decisions about people, handles sensitive data or supports a regulated activity, seek appropriate legal and specialist review.
AI automation proposal checklist: the short version
Before approving work, confirm that the written proposal covers all ten items:
- A named business outcome with a measurable starting point and target.
- A defined workflow boundary, including triggers, outputs, exceptions and exclusions.
- A system and data map showing what is accessed, transferred, stored and deleted.
- Human decision points, approval rights and an accountable process owner.
- Test cases and acceptance criteria agreed before launch.
- Security and access controls appropriate to the data and systems involved.
- Monitoring, alerts and recovery for failed or unexpected runs.
- Costs and change rules covering setup, tools, usage, support and revisions.
- Documentation and handover that your team can actually use.
- Ownership and exit terms for accounts, assets, data and supplier changes.
Start with the business outcome, not the technology
The proposal should name one operational result in plain language. “Implement an AI agent” is a technical activity. “Reduce manual enquiry triage and response delay by classifying new enquiries, sending complete records to the correct sales queue within two minutes, and holding ambiguous cases for review” links the workflow to an operational outcome.
Ask the supplier to document the current baseline: monthly volume, average handling time, rework, response delay, error rate or another relevant measure. Then agree the target and the observation period. A sensible target can be “reduce median processing time while keeping routing accuracy above the agreed threshold”; it should not be an unqualified promise of revenue or perfect accuracy.
If you are still deciding whether a workflow is suitable, complete an AI automation readiness audit before comparing build proposals.
Define the workflow boundary and exclusions
A decision-ready proposal follows the work from start to finish. It names the trigger, required inputs, processing steps, outputs, destinations and people involved. It also states what is outside scope.
For an enquiry-routing workflow, the boundary might begin when a website form is submitted and end when a validated record is created in the CRM and the correct team is notified. It should explain what happens when a required field is blank, a duplicate arrives, the CRM is unavailable, the message is spam, or the model is uncertain. If a score is used to decide which cases receive human review, the proposal should explain how that score is produced and validated against representative cases rather than assuming it is a dependable probability.
Decision-ready scope: “Validate six required form fields, identify the requested service from an approved taxonomy, apply a tested review rule, route cases that pass that rule, hold the remainder for a named reviewer, and log every outcome.”
List languages, channels, business units and historical data separately. If something is excluded—such as telephone enquiries, document interpretation or automatic quote approval—put the exclusion in the proposal rather than relying on a sales conversation.
Map systems, data and supplier access
The proposal should identify every connected system and the minimum access each connection needs. This can include forms, email, CRM, cloud storage, messaging tools, accounting software, analytics platforms and model providers.
For each data type, ask where it comes from, why it is needed, where it is processed, how long it is retained and how it is removed. The ICO’s guidance on AI and data protection addresses accountability, transparency, lawfulness, fairness, security, data minimisation and individual rights. Those topics should be reflected in the design when personal data is involved.
Do not accept “GDPR compliant” as a substitute for a data map. The proposal should distinguish your responsibilities from the supplier’s, identify relevant third parties, and state whether your information may be used to train or improve an external model. Your legal adviser can determine the agreements and assessments required for the specific use.
Keep meaningful human control
“Human in the loop” is only useful when the proposal defines the loop. It should name who reviews an item, what evidence they receive, how quickly they must respond, what authority they have to override the system, and what happens when they are unavailable.
Human review is particularly important when an output could materially affect a customer, employee or supplier. The person should not be a ceremonial approver. They need enough context, time and authority to question the output and choose a different action.
Write down actions the automation may take independently and those that always require approval. Sending an internal notification may be low risk. Rejecting an applicant, issuing a binding quote, changing payment details or sending sensitive information may demand stronger controls or may be unsuitable for autonomous execution.
Agree test cases and acceptance criteria before launch
“Tested and working” is not an acceptance criterion. A proposal should describe representative tests, expected results and the evidence you will receive.
- Normal cases: common, complete and valid inputs.
- Boundary cases: maximum lengths, unusual formats, multilingual text or borderline classifications.
- Failure cases: missing values, invalid records, rate limits, expired credentials and unavailable systems.
- Safety cases: prompt injection attempts, untrusted attachments, inappropriate requests and confidential information.
- Recovery cases: retry behaviour, duplicate prevention, manual replay and reconciliation after an outage.
Test input and record quality separately from model and end-to-end workflow performance. The UK Government’s Data Quality Framework distinguishes completeness, uniqueness, consistency, timeliness, validity and accuracy for data. Choose the data dimensions that matter to the workflow and define pass criteria for each. Then add task-specific measures—such as routing precision, false-positive and false-negative rates, abstention or review rate, and successful completion—where they are relevant.
Specify security, monitoring and recovery
An automated workflow becomes part of business operations, so the proposal should cover both prevention and recovery. Ask how credentials are stored, permissions are restricted, changes are reviewed, dependencies are updated, records are logged and unusual behaviour is detected.
The UK Government’s Code of Practice for the Cyber Security of AI includes supply-chain security, documentation of data, models and prompts, appropriate testing, regular updates, behavioural monitoring and proper disposal. A small business may implement controls proportionately, but the proposal should not ignore them.
Monitoring should state who receives an alert, what information the alert contains, when a retry is safe and when the system stops. Recovery should cover backups or reprocessing where relevant, a manual fallback, duplicate prevention, and a record of actions already taken.
Make costs and change control explicit
Separate one-off implementation from recurring costs. The proposal should identify supplier support, automation platform charges, model or API usage, database or storage costs, communication fees and paid connectors. For usage-based services, request the unit, forecast assumptions, alert threshold and spending limit.
Also define what counts as a correction, an in-scope refinement and a new requirement. A changed CRM field, an additional language and a new approval path can have very different effects. A simple written change process prevents every adjustment becoming either a surprise invoice or an undocumented production edit.
| Area | Vague wording | Decision-ready commitment |
|---|---|---|
| Outcome | Improve efficiency | Name the process, baseline, target, measurement and review date |
| Scope | Connect our systems | List systems, fields, permissions, steps, exceptions and exclusions |
| Testing | Full QA included | Provide test categories, expected results, pass thresholds and sign-off owner |
| Support | Ongoing support | State coverage, response targets, monitoring owner and excluded work |
| Cost | From £X per month | Separate setup, subscription, usage, support and change charges |
| Exit | Cancel at any time | Explain account ownership, export format, credential removal and transition help |
Require documentation, handover and an exit plan
Documentation is part of the product, not an optional extra. A good handover explains the workflow in business language and provides enough technical detail for safe operation.
- A current workflow diagram and plain-English operating description.
- A list of systems, accounts, permissions, owners and third-party dependencies.
- Configuration, field mapping and approved prompts or rules, with sensitive values excluded.
- A runbook for alerts, failures, manual fallback and common changes.
- Test results, known limitations and outstanding risks.
- Training for the people who operate, review and approve the workflow.
- A version history and method for approving future changes.
The exit section should say who owns the workflow, documentation, domain-specific configuration, accounts and data. It should explain how information will be exported, how supplier access will be removed, and what happens to retained copies. Business-owned accounts and portable documentation reduce avoidable lock-in.
A simple 20-point proposal scorecard
Score each of the ten checklist areas at the top of this guide:
- 0: absent or only discussed verbally
- 1: mentioned but not specific enough to verify
- 2: specific, verifiable and assigned to responsible parties where applicable
A total does not replace judgement: one critical zero in security, human control or data handling can outweigh a strong overall score. Use the scorecard to expose questions, compare like with like and record why you accepted a trade-off.
Worked example: lead qualification and routing
Imagine a UK service business that wants to route website enquiries. A responsible first phase might validate form fields, remove obvious spam, classify the requested service from an approved list, and send uncertain cases to a sales coordinator. If the design uses a model score to separate cases, the supplier should validate the score and threshold against representative data; tested ambiguity rules and human review should remain available when a score is not reliable enough.
Acceptance criteria could include:
- every valid submission produces one traceable CRM record;
- a retry does not create a duplicate record;
- cases that meet the tested review rule are held for a named person;
- repeated CRM failures alert the responsible owner; and
- a manual submission route remains available.
The supplier should test normal, incomplete, duplicate, adversarial and outage scenarios.
This makes the proposal more useful than a generic promise to “qualify leads with AI.” It also provides a controlled path from pilot to wider use. For a detailed implementation pattern, see our guide to automating lead qualification and routing.
Red flags when comparing proposals
- The demonstration is polished, but there is no written process map or exception list.
- The proposal guarantees perfect accuracy, revenue or hours saved without a baseline and measurement method.
- One shared administrator login is requested for every connected system.
- “Human review” appears in the sales deck but has no named role, queue or response process.
- Testing excludes failures, retries, duplicates, unsafe inputs or third-party outages.
- Recurring model, platform, messaging or support charges are omitted.
- Your supplier owns production accounts that your business cannot access.
- Documentation and transition assistance are unavailable or priced only after cancellation.
- The system processes more personal data than the stated outcome requires.
- There is no safe manual fallback for a workflow the business depends on.
Questions to ask before signing
What evidence will show that the automation is ready to launch?
Ask for named test cases, expected results, pass thresholds, known limitations and a sign-off process. Confirm who can delay launch if evidence is incomplete.
Who owns the accounts and automation assets?
Prefer business-owned production accounts with supplier access granted through named users or roles. The proposal should distinguish reusable supplier intellectual property from your data, configuration, workflow assets and documentation.
What happens when a connected service fails?
Look for bounded retries, duplicate protection, alerts, a manual fallback and a reconciliation procedure. “The platform retries automatically” does not explain who verifies the final business outcome.
How will changes be tested after launch?
Require version control or a change history, a safe test environment where practical, regression tests for critical paths, approval before production deployment and a rollback method.
How should a small business use AI risk frameworks?
Use them proportionately to improve questions and controls, not as a claim that every item applies identically. The NIST AI Risk Management Framework is voluntary and designed for different sectors and organisation sizes. Its companion Playbook organises suggested actions around Govern, Map, Measure and Manage; NIST explicitly notes that the suggestions are not a universal checklist to follow in full.
What a strong proposal lets you decide
A strong proposal does not remove uncertainty. It makes the important uncertainty visible and gives you a controlled way to learn. You should be able to tell what will be built, how it will behave, which risks remain, what your team must do, what it will cost, and how to stop or change course.
That is the difference between buying a promising demonstration and commissioning an operating capability. If you want to understand practical use cases first, read our guide to AI automation for small business.
Useful official resources
Need an automation proposal you can evaluate?
Rahman Digital Agency can help you define and implement an AI-enabled workflow with explicit scope, review points, testing, monitoring and handover. Start with one qualified use case and a documented path from pilot to dependable operation.
Explore AI automation services Discuss your workflow