Definition
Automation priority is the practice of scoring candidate processes on volume, variability, effort, and risk, so that limited capacity goes to the work with the best return rather than the work that shouted loudest.
Why the first automation is usually the wrong one
Most businesses automate whatever generated the loudest recent complaint. That is a reasonable instinct and a poor selection method, because the loudest process is rarely the most expensive one. Frequency beats intensity: a mildly annoying task performed two hundred times a week costs far more than a genuinely painful one performed monthly.
Picking well matters more than it seems, because the first project sets the political weather. One that visibly works buys support for the next five. One that stalls makes every subsequent proposal harder, regardless of merit.
The four factors worth scoring
Volume. How many times a week does this happen? This dominates the return calculation, and it is the factor most often estimated wrongly, usually low, because nobody counts the small interruptions.
Variability. Are the steps identical each time? Highly consistent work is cheap to automate. Work with many exceptions is expensive and often better left alone until the process itself is simplified.
Effort per instance. Minutes per case, honestly measured, including the context-switching cost, which is real and rarely counted.
Consequence of error. What happens if it goes wrong, and how quickly would you find out? Low-risk, visible errors make good first projects. High-risk or silent errors need more controls, which means more time and more cost.
Multiply volume by effort to get the prize. Weigh that against variability and risk to get the difficulty. The best first candidate is high on the first pair and low on the second, and it is almost never the process people nominate first.
The disqualifiers
Some candidates should be removed from the list regardless of how well they score:
Nobody has mapped it. If the steps live in two people's heads and they disagree, you have a process mapping problem. Automating it locks in one person's version.
It is about to change. A system migration, reorganization, or policy revision in the next two quarters means you would be automating something that will not exist.
The process should not exist. A surprising number of automation candidates are steps that were added to compensate for a problem elsewhere. Fixing the cause removes the work entirely, which beats automating it.
Nobody owns the outcome. Without a person accountable for the result, there is nobody to define correct behaviour or notice when it stops working.
How Automathing approaches it
We score candidates before scoping any build, and we count frequency deliberately because it is the factor most consistently underestimated. We also actively look for the fourth disqualifier, meaning work that exists only to compensate for a problem upstream, because removing a process outright beats automating it every time. The first project we recommend is usually not the one the client arrived with.
Frequently asked questions
What should we automate first?
The highest-frequency, lowest-variability task that crosses at least two systems and whose errors are visible and cheap to correct. In most businesses that is data entry between systems or a recurring report someone assembles by hand. It is rarely the process that prompted the conversation.
How do we measure the current cost of a manual process?
Time it properly rather than asking for estimates, since self-reported durations are consistently wrong in both directions. Multiply minutes per case by weekly volume by loaded hourly cost, then add the costs that hide: rework when it goes wrong, delay while items wait in a queue, and the context-switching tax on interruptions.
Should we automate a process we are planning to change?
No. Wait for the change, map the new process, then automate. Automating something that is about to be replaced spends effort on a system with a known expiry date and often makes the migration harder.
How many processes should we automate at once?
One, until it is working and measured. Sequential delivery produces a visible result faster and teaches you things about data access, exceptions, and who actually owns what, all of which make every subsequent project cheaper. Parallel automation projects in a business that has not done one before tend to finish together, late.