What an AI and automation consultant actually does
Mostly not writing code. Done properly, the job is discovery and plumbing: finding out how work actually moves through a business, deciding what should be built against what should merely be configured, connecting systems that were never designed to talk to each other, getting people to trust the result, and then (the part nobody advertises) keeping it all alive after the invoice is paid.
The title is unregulated, so it covers people who sell strategy decks, people who resell licences, and people who leave behind working automations with documentation a stranger could follow. This post describes the third kind, in enough detail that you can tell the difference in a meeting.
What are the stages of the work?
| Stage | What it looks like | What goes wrong without it |
|---|---|---|
| Discovery | Watching work happen: the inbox, the spreadsheet, the group chat | The consultant automates the process the owner described, not the one that exists |
| Process mapping | The real steps written down, exceptions included | The first edge case, the client who pays by cheque, breaks everything |
| Build vs configure | Deciding what existing tools already cover | Custom software where a setting would have done, paid for twice |
| Integration | Connecting the inbox, the accounts package, the job system | The retyping survives, so the automation saves nothing |
| Training and handover | People shown the system on their own work, not a demo | A working system nobody touches |
| Maintenance | Absorbing API changes, catching quiet breakage | Slow decay until a month of missed enquiries surfaces |
Three rows deserve expansion.
Build vs configure is where your money is protected. Most small-business problems do not need software written; they need tools you already pay for connected and configured properly, which costs less and breaks less. This is why we describe the work as automation, not software: writing code is the last resort, not the product.
Training and handover is the harder half of the job, because a working system nobody uses is worth nothing. Training sceptical teams is a discipline of its own: short sessions, real work, the loudest doubter recruited first.
Maintenance goes unadvertised because it is boring, and it decides whether the automation still runs in a year. Tool vendors change their interfaces, passwords rotate, the person who owned the workflow leaves. A consultant with no answer to "what happens when it breaks at 8am, and how would we even know" is selling a build, not a system.
When do you actually need one?
Three situations justify a fee:
- Systems must talk to each other. Once a flow crosses the accounts package, the job-management tool and the inbox, you are in integration territory, where consumer automation tools hit their ceiling.
- The data is regulated or sensitive. Customer personal data carries UK GDPR duties whoever does the work, and the ICO is clear that accountability stays with your firm. The build has to be documented and defensible, not just functional.
- There is no internal owner. An automation without a named person who cares becomes an orphan by Christmas.
And the honest inverse: if you have one obvious workflow, one or two consumer-grade tools and someone in the firm who enjoys tinkering, you do not need a consultant. Do that one yourselves and spend the fee later, on the plumbing.
What shapes do engagements take?
Three, commercially:
- A fixed diagnostic or audit. Defined questions, defined output, defined end.
- A project build. Scope agreed, delivered, handed over with documentation and your name on every account.
- A retainer. A few days a month for monitoring, fixes and a queue of small improvements.
What each costs varies too much by scope for a number here to be honest, and you should distrust anyone who quotes a precise saving before discovery, because they are guessing. The reliable signals are structural: a defined end, a written handover, and accounts owned by you rather than the consultant.
What should you ask before signing?
- Who owns the licences, accounts and logins? (The only acceptable answer is you.)
- What documentation is handed over, and can you see a redacted example now?
- What happens when it breaks, and how would anyone know it had?
- What security baseline do they work to? Naming the NCSC small business guide in the room is a fair test; it is the floor, not the ceiling.
- What have they refused to automate, and why? Someone with no examples will automate anything for anyone, including the steps that were quietly catching your errors.
Then make the first engagement small and measurable. The disciplines of a good pilot apply to consultants as much as to tools: one process, a start, an end, and a decision in the diary.
The trade, done well, is unglamorous: watching, mapping, wiring, teaching, maintaining. Nobody puts "we will sit with your office manager for a day" on a landing page, but that day is where the value comes from. AI Metric does this work, so discount our view accordingly, then apply the questions above to us exactly as hard as to anyone else.