Tag: Agency Selection

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.

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.

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.

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.

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.

“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.

“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.

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.

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.

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.

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 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.