Automation consultants: what to expect
Automation consultants should be able to tell you what not to build. The useful engagement begins with a paid, data-driven Discovery that maps the work bottom-up, assesses every step as retire, automate, assist or person, and returns a prioritised roadmap. A build follows that, and only where the diagnostic supports it. An engagement that arrives with a platform already chosen has answered the question before asking it.
What should automation consultants do first?
Establish what the work actually is. That means mapping the process bottom-up from the organisation's own data, usually timesheets and operational records, rather than from a workshop in which each function describes its intentions.
Only once the map exists is it sensible to ask what should be automated. The steps that should be removed, and the steps that must stay with a person, are found in the same pass, and both change what a build should be.
Why does a paid Discovery come before any build?
Because how much of a process will yield to specification is not known at the outset. That is a research question, and it is answered by doing the research, not by writing a fixed scope around an assumption.
A paid Discovery buys the answer to that question and produces an artefact that remains useful whatever is decided afterwards. It also removes the incentive problem in unpriced scoping work, where the diagnostic is given away and its author is paid only if a build follows.
What is returned at the end?
- the map of the work as it is actually performed;
- an assessment of every step: retire, automate, assist or person;
- the findings, expressed in commercial terms;
- a roadmap prioritised by commercial value, feasibility, data readiness, governance requirements and delivery complexity;
- the specification for each use case recommended; and
- the list of steps that could not be specified.
That last item is not a caveat. It is part of the result, and it is the part most often missing from proposals written before any data has been seen.
Who owns what is produced?
You do, including the specification and the reasoning behind it. Where a model is required, an open-weights model hosted on your own infrastructure and owned outright is one of the architectures available. A managed service, where one is agreed, is a convenience rather than a dependency.
How should an automation proposal be judged?
Three questions separate a diagnostic from a sales process.
First, what evidence was used. A proposal written from a workshop and a product demonstration is describing a tool rather than your operation.
Second, what the engagement is willing to conclude. If no possible finding would lead to the recommendation that less should be built, the finding was never in question.
Third, what you keep. The specification, the reasoning, the map, and where an open-weights model is deployed the model itself, should all remain yours at the end.
A fourth is worth asking of any provider: which steps would you leave with a person, and why. An answer that names none is not confidence. It is an assessment that has not been done. The same questions apply to an internal proposal, because where the diagnostic and the build are argued for by the same team the incentive is unchanged by whether that team is a supplier or a department.
What if we need a fixed scope?
Where a fixed scope and a guaranteed answer are needed at signature, we say so at the outset and help you find the right form of engagement. So would one that has already decided which platform it is buying and wants a diagnostic that agrees.
The work is conducted as research and reported as such. That is a strength when the question is genuinely open, and a poor fit when it is not.
Common questions
-
What is business process automation?
Running a step of a process without anyone present. The term covers everything from a scheduled transfer between systems to a model that drafts an output. What makes it worth doing is not the technique but whether the step survives the prior question, which is whether it should exist at all.
-
How do you automate a business process?
Map it from evidence, assess every step as retire, automate, assist or person, specify the steps that are to be automated, then build. The order matters. Automating before the map is drawn fixes the cost of steps that a wider view would have removed.
-
Can you give an example of business process automation?
Data arriving from a counterparty, matched against an internal record, with only the unmatched items presented to a person and the reason for each failure attached. The matching runs without anyone present. The exceptions do not, because the judgement is what that step is for.
-
Who is an AI automation consultant?
In practice, anyone offering to apply models to an operation. The title is not regulated, so the diagnostic is what should be judged. The useful ones begin from your commercial objective and your operational data, assess every step including the ones that should be removed, and are willing to report that a step cannot yet be specified.
-
What is the difference between automation consultants and an AI automation agency?
Mostly the starting point. An agency typically begins from a set of tools it implements. A diagnostic engagement begins from your commercial objective and your operational data, and may conclude that fewer steps, rather than new software, is the answer.
-
Is automation being replaced by AI?
It is being extended by it. Deterministic automation still handles the steps whose behaviour can be fully specified, and it should, because it is cheaper to run and easier to assure. Models extend the reach to steps involving language and judgement, and those steps carry a quality threshold, a human review point and an audit trail that a deterministic step does not need.
-
What are the leading RPA tools?
We do not endorse a vendor. The tool follows the specification rather than preceding it, and a good many assessments conclude either that a platform already licensed does what is required, or that the step should be retired and no tool is needed at all.
-
Will our data leave our infrastructure?
It need not. Open-weights models on your own infrastructure, ringfenced environments over SSH or VPN, zero-retention commercial APIs and anonymisation are all available, and the choice is yours.
-
What if the diagnostic concludes that little should be automated?
That is a legitimate outcome and it is reported plainly. Knowing which steps cannot yet be specified is worth more than a build that quietly fails a threshold nobody wrote down.