The most common reason a first automation project disappoints is not that the technology failed. It is that the wrong process was chosen. Teams tend to pick either the process that annoys the loudest person, or the one that looks most impressive in a demo. Neither is a reliable predictor of value.
Here is the method we use when we run a workflow audit, reduced to something you can apply yourself with a spreadsheet and a couple of hours.
Score candidates on four dimensions
List every process a team touches in a week. Aim for fifteen to thirty candidates — enough that patterns emerge. Then score each one from 1 to 5 on four dimensions.
1. Volume
How many times does this run per month, and how long does each run take? Multiply them. This is the only dimension where the number is objective, and it is the one people most often estimate from memory rather than measure. A process that feels painful twice a month is rarely worth automating before one that quietly runs two hundred times.
2. Variability
How often does the process deviate from its documented path? Low-variability processes — the same inputs producing the same steps — automate cleanly. High-variability processes can still be automated, but the cost sits in the exception handling, not the happy path. Be honest here: if the person running it says "it depends" more than twice while describing it, score it high.
3. Handoffs
How many times does the work change hands, systems, or formats? Every handoff is a place where information waits, gets re-typed, or gets lost. Handoff count is usually the best single predictor of how much time an automation will return, because the waiting between steps is often longer than the steps themselves.
4. Consequence of error
What happens if a step is done wrong and nobody notices for a week? This score works in the opposite direction: high consequence means proceed carefully, keep a human approval step, and invest more in testing. It does not mean avoid automating — payroll and invoicing are high-consequence and are automated everywhere — but it changes what a responsible implementation looks like.
Read the scores as a shape, not a total
Do not simply sum the four numbers. Read the profile:
- High volume, low variability, many handoffs, low consequence. This is the ideal first project. Fast to build, easy to verify, and the time saving is visible within a month.
- High volume, high variability. Worth doing, but scope it to the common path first and route everything else to a person. Trying to handle every exception in version one is how automation projects overrun.
- Low volume, high consequence. Usually leave alone. The effort of building it safely rarely pays back across so few runs. A better checklist often solves it.
- High volume, low handoffs, one system. Check whether the software you already own can do this natively before commissioning anything. A configuration change is cheaper than an integration.
Then check three practical constraints
A high-scoring process can still be the wrong first project if any of these is unresolved.
Does the data exist in a usable form?
Automation moves information. If the information currently lives in someone's head, in an email thread, or in a PDF that gets re-typed, you are not automating a process — you are first building the record the process needs. That is legitimate work, but it belongs in the scope and the estimate.
Do the systems have an API?
Most modern platforms do. Some older or industry-specific systems do not, or expose a limited one. Where there is no interface, the options are file-based exchange, database-level access with the vendor's blessing, or a change of platform. All three are workable; all three change the cost. Confirm this before scoping — our systems integration work usually starts with exactly this inventory.
Is there an owner?
Someone has to decide what happens in the ambiguous cases, and later, someone has to notice when the automation stops working. A process with no clear owner produces an automation nobody maintains. This is the constraint most often ignored and most often fatal.
Set the success measure before you build
Write down, in advance, what number should change and by how much for the project to be worthwhile. "Hours spent on this process per month" and "time from request to completion" are the two most useful, and both should be measured for a couple of weeks before the build so there is a real baseline rather than a remembered one.
This step gets skipped constantly, and its absence is why so many automation programmes cannot demonstrate value afterwards. The measurement does not need to be sophisticated. It needs to exist before the change.
Start with one
There is a strong pull toward doing several processes at once, on the theory that setup cost is shared. In practice the first project teaches you things about your own data and exceptions that change how you would build the next one. Doing three in parallel means making the same wrong assumption three times.
One process, measured, in production, with the exceptions understood — then the second. The sequence is slower on paper and faster in reality.
If you want a second opinion on which process to start with, that is roughly the first hour of any conversation we have. Tell us what your team repeats most and we will tell you whether it is the right place to begin.