Hiring an AI automation consultant: what you should get

What should an AI automation consultant deliver?

A useful engagement ends with working software and a measured result, not a slide deck. The deliverables are a ranked list of candidate processes, a scoped build for the first one, access to the code and configuration, and a way to see accuracy and volume afterward.

If the consultant cannot tell you which system the output will be written to, the project is not scoped yet.

Ask for a sample deliverable before signing. A one-page process assessment with volumes, systems and a recommended first build shows how the consultant thinks. Ask also whether the same people who advise will write the code, because handoffs between advisors and builders lose detail.

Expect questions in return. A good consultant asks how a task is done today, who checks it, what a mistake costs, which systems hold the source data and who has admin rights to them. If the first call is mostly about tools, the work will start in the wrong place. Expect also a plain statement of what will not be automated, because some steps need judgment, relationships or sign-off that should stay with a person.

How to rank your candidate processes

Score each process on volume, current labor, error cost, and whether the destination system has an API. A process with moderate volume and a clean API often beats a larger one that lives in a desktop application with no integration path.

Do not rank by novelty. Boring processes such as invoice entry, order status emails and intake forms usually have the clearest inputs, the clearest outputs and the easiest measurement.

• Volume: how many times per week the task happens
• Labor: minutes per instance and who does it
• Risk: what a wrong output costs and who catches it
• Access: API, webhook, export or none

Where small firms stand

Census Bureau data shows under 20% of firms with four or fewer employees reported AI use, while 37% of firms with at least 250 employees did. The smaller you are, the fewer peers you have to compare notes with, which is one reason outside help is common for the first build.

Consider a clear boundary on scope. A first engagement that covers one process, one system connection and one measured outcome is easier to judge than a company-wide transformation plan. If the result is good, the next process uses the same patterns and costs less to build.

Red flags in a consulting proposal

Be careful with proposals that name a tool before they name a process, promise percentages of time saved without seeing your data, or leave out integration and monitoring. Ask who owns the prompts and code at the end, which model providers are used, and what happens when a provider changes a model version.

Ask about failure. A serious consultant can describe a case where a model got something wrong and the control that caught it. Then ask what happens at your company when the provider changes the model behind an API name. The answer should involve pinned versions and a saved test set.

Check references where you can, and ask for a technical walkthrough of a comparable system, even with names removed. Someone who has built these integrations can explain how they handled authentication, retries and bad input in detail.

What you own at the end

You should receive the repository or workflow definitions, a list of credentials and where they are stored, prompt files under version control, and a runbook for failures. That lets your next developer or Vascoh pick it up without reverse engineering.

Ask for a plain-language description of what the automation does for staff on a normal day and on a bad day. If the bad-day description is missing, the project has not been thought through.