People often start looking for a business process automation consultant when they realise the problem may not be the tool they bought, but what happens between the tools and the people using them. That is also why we would be wary of an engagement that opens with a product recommendation.
Here is the shape the work usually takes, so you can tell whether the proposal in front of you is genuine discovery work, or whether the solution was decided before the audit started.
The first phase is listening, not designing
The consultant should sit with the people doing the work and write down the process as it actually runs, in the order it runs, including the steps that are not in any documentation. What gets checked twice. Who gets asked when something is unclear. Which spreadsheet is open on a second monitor all day.
Expect them to ask for the exceptions specifically, because the documented happy path is rarely where the hours go. Exceptions have to be understood before the map is treated as finished, or the design ends up built around the documented path rather than the way the work actually happens.
Then the process becomes money
For the manual steps that look worth investigating, record the frequency, the approximate duration and the number of people involved, ideally from a week of tallies rather than from memory. Those hours can then be converted at a realistic loaded cost, so the output is a list of steps with a monthly figure beside each one. Error cost, delays and bottlenecks stay visible separately rather than being folded into the hourly number.
This is the part that makes the rest of the engagement arguable in a good way. Once the figures exist, you and the consultant can disagree about a number instead of about a feeling, and the disagreement is productive.
A recommendation that can be "do nothing"
The recommendation should distinguish at least between what you can fix without software, what is worth building, and what is better left alone. If every finding somehow becomes a build recommendation, ask whether the audit is really separating your priorities from the supplier's incentives.
An audit that ends with a setting change, a template and a scheduled report is a successful audit. So is one that ends with a clear recommendation not to automate anything this year because the process is about to change.
Build in slices, and measure again
Where the workflow allows it, start with the smallest slice that removes one real step. For anything carrying operational risk, running the new path alongside the old one for a defined period exposes cases that did not appear during discovery, and gives the team a chance to see how it handles a normal week, awkward cases included, before the old process is retired.
Then measure the same step again with the same tally method. Using the same method gives the cleanest comparison with the original estimate, and it is the number you will want the next time you are asked to justify one of these projects.
What you should own at the end
- The process map, in a format you can edit without the consultant.
- The measurements, with the assumptions written down, so a successor can check the arithmetic rather than trust it.
- The recommendation, including the steps that were judged not worth automating and why.
- The build plan, specific enough that another supplier could execute it. If it is not, you have bought a dependency rather than an audit.
- Production accounts, repositories and credentials belonging to your business, or sitting under accounts it controls, rather than transferred to you only at handover.
How these engagements go wrong
- A platform is chosen before the process is understood, and the rest of the project becomes an argument about fitting the work into it.
- The automation is built around a broken step instead of removing the step, which makes the mistake faster and harder to see.
- Nothing is documented, so the automation becomes a second thing only one person understands, which is the problem you hired someone to fix.
- Nobody measures afterwards, so the value is asserted rather than known, and the next project has to start the argument again.