Choose an AI automation consultant who can define one useful workflow, show relevant evidence and explain how your team will control and operate it. A convincing demonstration helps start a conversation. A good proposal also covers the baseline, data access, review effort, failure handling, cost and handover.
You do not need to compare model names to make the first decision. Ask each consultant to explain the same business process in plain English. Their ability to state what will happen when the happy path fails is often more informative than the speed of the demonstration.
Can they describe the problem before choosing the tools?
Give the consultant a real example of the current task, including an awkward case. Ask them to name the trigger, inputs, output and person responsible. They should distinguish the part that needs interpretation from the part an ordinary rule or integration could handle.
Look for questions about volume, source quality, access and who reviews the result. A proposed “AI transformation” without a defined first workflow is difficult to price or evaluate. The first-process scorecard gives you a way to compare candidate workflows before comparing builds.
What evidence should you ask to see?
Ask for an example with a similar operating problem, even if it comes from a different industry. What was built, what did the consultant personally contribute, who uses it and what remains limited? Ask whether screenshots show a live system, a prototype or a demonstration using fictional data.
Separate a working capability from a measured result. My XO3D ONE case study shows an internal studio system with genuine interface captures and demonstration records. The website intelligence dashboard shows an evidence-to-action workflow; its readiness views do not prove a commercial uplift. Those distinctions should remain clear in any supplier's proof.
Where a consultant claims savings or growth, ask for the period, baseline, method and limitations. A testimonial may describe a useful experience, but it is not automatically a controlled comparison. You should not need to infer the strongest claim from a polished image.
Which questions belong in every proposal?
| Ask about | Look for a specific answer |
|---|---|
| Scope | One workflow, defined inputs, output and exclusions |
| Baseline | Current effort, errors and review time, with evidence dates |
| Ownership | Named sponsor, operator, accounts and access responsibilities |
| Exceptions | Detection, stop conditions, escalation and manual fallback |
| Acceptance | Representative examples, known failures and agreed checks |
| Cost | Build, services, internal effort and future change terms |
| Handover | Documentation, training, configuration and operating owner |
Who controls the data, accounts and actions?
Before providing access, establish which sources the workflow needs, why it needs them and what each tool may read or change. Ask where information goes and which provider terms apply. The answer should fit your organisation's actual requirements and approvals.
Clarify who owns the service accounts, where credentials are managed and how access can be withdrawn. Ask who can approve a customer message, publication or other external action. A connection to a system should not silently become authority to act through it.
Also establish what you receive at handover and any dependencies on the consultant's own services. Ownership and licensing should be explicit in the agreement, rather than guessed from the fact that a build runs in your browser.
How will they demonstrate failure handling?
Illustrative evaluation scenario, not a client result: an enquiry-preparation workflow receives a message with no deadline and a broken attachment. A useful response flags the missing facts and routes the case for review. It should not invent the deadline or claim the attachment was read.
Ask the consultant to include such cases in the acceptance plan. Cover unavailable sources, duplicate inputs, rejected drafts and a failed integration. Decide who sees the problem and whether a rerun could create duplicate work. Test the proposed stopping behaviour, not just whether a clean input produces a fluent output.
The reviewer needs enough context to make the decision. “Human in the loop” is incomplete unless the proposal names the person, what they inspect and what happens when they do not respond.
How should you compare fees and ongoing costs?
Compare written scopes with similar boundaries. Include subscriptions, usage, monitoring, maintenance and your team's preparation and review time. A lower build fee may be sensible, but it cannot be evaluated without knowing what has been excluded.
My first scoped pilots start from £1,750 over four to eight weeks. That public starting offer is not a market benchmark or a guarantee that every project fits it. The pilot cost guide sets out the questions to resolve before comparing a fee.
Will your team be able to run the result?
Ask who will operate the workflow after handover and have that person take part before the end. They need to understand the normal run, review requirements, common exceptions, pause control and route for help. Documentation should explain the actual delivered workflow.
Agree a review point for the pilot and what evidence would support continuing, changing or stopping it. Choose a consultant whose proposal helps you make that decision. The objective is an operating process your team understands, with useful proof and clear responsibility.