The first deliverable of any competent business process automation engagement is a ranked list of what to automate and what to leave alone. Here is the method for producing that list — written out in full, so you can run it yourself before paying anyone.
We are an automation firm publishing our own diagnostic. The reasoning is straightforward: clients who arrive having done this work get better outcomes, scope faster, and waste less of everyone's money. Clients who arrive without it usually want us to automate whichever process annoyed someone most recently, which is rarely the right one.
What BPA Consulting Actually Is — and Is Not
The term gets applied to three different services. Knowing which you are buying prevents most of the disappointment in this category.
- Diagnosis. Mapping how work actually flows, where time and money leak, and what to fix in what order. The output is analysis and a plan.
- Implementation. Configuring or building the automation. The output is working software.
- Platform placement. Selling and deploying a specific vendor's product. The output is a licence and a rollout.
All three are legitimate. The problem arises when a firm sells the first while economically dependent on the third — a diagnosis performed by someone who earns on a particular platform tends to conclude that the platform is the answer. Ask directly whether the firm receives compensation tied to any tool it recommends. Not because that disqualifies them, but because you should be able to weigh the advice accordingly.
Step One: Inventory the Work, Not the Software
Most teams start by listing their systems. Start by listing work instead — the recurring things people do that produce an outcome.
A practical way to do this in a week without disrupting anyone: ask each team to write down every recurring task they perform, how often, roughly how long it takes, and what triggers it. Not a formal process map. A list.
Two rules that make the result useful:
- Capture the work-around, not the official procedure. You want what people actually do, including the spreadsheet they keep because the system does not do what they need. That spreadsheet is the most valuable artifact in the building.
- Count the corrections. Time spent fixing errors, chasing missing information, and re-entering data is usually larger than the task itself and is almost never recorded.
Step Two: Score Each Candidate Honestly
Now rank. Four factors, and the fourth is the one firms skip.
For a vertical where this scoring produces unusually clear answers — high volume, high determinism, and poor existing tooling — see workflow automation for behavioral health. Score each 1–5 and multiply rather than add. Multiplication is deliberate: a process that scores 5 on volume and 1 on determinism is not a good candidate, and adding would hide that. The best first projects score at least 3 on everything.
The Processes That Look Automatable and Are Not
Four patterns we see repeatedly, each of which consumes budget and produces frustration:
Work whose difficulty is the exceptions. If 70% of cases are straightforward and 30% require judgment, automating the 70% may not help much — because the human still has to review everything to find out which bucket each case is in. Unless the sorting itself can be automated reliably, the reviewing cost remains.
Work that is really a communication problem. “We spend hours chasing approvals.” The chasing is a symptom; the cause is that approvers have no incentive or reminder. Sometimes automation helps. Often a changed expectation helps more, and costs nothing.
Work performed inconsistently. If three people do it three ways, automating encodes one version. Standardize first — this is internal work, it is free, and it frequently reveals that the process is smaller than everyone believed.
Work that exists because of a data problem. People re-key between systems because the systems do not talk. Automating the re-keying is a patch; connecting the systems is the fix. The patch is cheaper today and more expensive by year three.
What a Real Engagement Should Produce
If you do hire a firm for diagnosis, you should end up holding something useful independent of whether you continue with them. Specifically:
- A written inventory of recurring work with measured — not estimated — time consumption.
- The scored ranking, with reasoning, including what was deliberately excluded and why.
- For the top candidates: what the automated version looks like, what it depends on, and what it will not fix.
- A cost range for each, with the assumptions stated.
- An explicit list of things to fix internally that require no software at all.
That last item is the tell. A diagnosis containing no unpaid, do-it-yourself recommendations is a sales document. Every honest assessment of a real business turns up several things that are simply process or accountability problems.
How to Tell Whether It Worked
Agree the measurement before the work starts, because agreeing it afterwards is an argument.
The trap is measuring activity — transactions processed, workflows executed — which always looks impressive and proves nothing. Measure the thing you were trying to change:
- Hours on the process, sampled the same way as the baseline. This requires having taken a baseline, which is why the inventory step matters.
- Error and rework rate. Frequently the larger benefit, and routinely unmeasured.
- Cycle time from trigger to completion, which is what customers actually experience.
- Whether people stopped using their workarounds. The most honest signal available. If the old spreadsheet is still being maintained, the automation did not fit the real process.
When to Do It Yourself Instead
The diagnostic above is genuinely doable internally, and you should do it internally when: your organization is small enough that a few people understand all the work; you have someone with the time and standing to ask uncomfortable questions across departments; and your candidate list is likely to be solved by configuring products you already own.
If you do decide to bring someone in, how to hire an automation consultant covers the questions and the red flags. Bring in outside help when the process crosses departments that do not agree with each other, when you have failed at this before and do not know why, or when the answer likely involves building something and you need to know what before committing budget.
Where WorkflowUnity Fits — Plainly
We are a US-based custom software firm building on AWS, and we receive no compensation from any software vendor — which is why the diagnostic above is published rather than sold, and why our recommendations regularly end with “configure what you own” or “fix this internally first.”
Whether building is justified at all has its own four gates. When a diagnosis does conclude that something should be built, that is the work we do: scoped phases, code and cloud accounts in your name from day one, and a small paid first phase so you can test us cheaply. If your top-scoring candidates are all solvable with products you already have, we will tell you that, and there will be no invoice attached to the telling.
Frequently Asked Questions
What is business process automation consulting?
It covers three distinct services that are often confused: diagnosis, meaning mapping how work actually flows and ranking what to fix; implementation, meaning configuring or building the automation; and platform placement, meaning selling and deploying a specific vendor's product. All three are legitimate, but a diagnosis produced by a firm compensated on a particular platform tends to conclude that platform is the answer — so ask directly about vendor compensation.
How do I decide which processes to automate first?
Score each candidate on four factors and multiply rather than add: total hours consumed per month, determinism (whether the rules can be written down completely), data availability (whether the information already exists in a system rather than needing human gathering), and stability (whether the process will still be the same in two years). Multiplication is deliberate — a high-volume process with low determinism is a poor candidate, and adding would hide that. Good first projects score at least 3 on every factor.
Which processes should not be automated?
Four patterns waste money reliably: work whose difficulty lies in the exceptions, where a human must still review everything to sort cases; work that is really a communication or accountability problem wearing a process costume; work performed inconsistently by different people, which must be standardized first; and work that exists only because two systems do not talk, where connecting the systems is the real fix and automating the re-keying is a patch that gets more expensive over time.
What should a business process automation assessment deliver?
A written inventory of recurring work with measured rather than estimated time consumption; a scored ranking with reasoning including what was excluded and why; for top candidates, what the automated version looks like and what it will not fix; cost ranges with stated assumptions; and an explicit list of improvements requiring no software at all. That final item is the integrity test — an assessment with no unpaid do-it-yourself recommendations is a sales document.
How do you measure whether automation actually worked?
Agree the measurement before work begins. Avoid activity metrics like transactions processed, which look impressive and prove nothing. Measure hours spent on the process sampled the same way as your baseline, error and rework rates, cycle time from trigger to completion, and most tellingly whether people abandoned their workarounds. If the old spreadsheet is still being maintained, the automation did not fit the real process.
Can I do the automation diagnostic myself?
Often yes, and you should when your organization is small enough that a few people understand all the work, you have someone with the time and standing to ask uncomfortable questions across departments, and the likely answers involve configuring products you already own. Bring in outside help when the process crosses departments that disagree, when you have failed at this before without understanding why, or when the answer probably involves building something and you need scope before committing budget.