"Automate everything" is popular advice and bad advice in roughly equal measure. Some processes genuinely benefit from automation. Others are too variable, too infrequent, or too important to get wrong to hand over to a system without close supervision. The useful question isn't whether to automate, it's which processes to automate first, and in what order.

The three factors that actually determine priority

Time saved. How much recurring human time does this process consume, multiplied across how many times it happens per week or month? A five-minute task done twice a day adds up faster than an hour-long task done once a month.

Complexity. How many decision points and exceptions does the process involve? A task that follows the exact same steps every time is a much better automation candidate than one that requires judgement calls on a case-by-case basis.

Risk. What happens if the automation gets it wrong? Automating a task where an error is easily caught and cheaply fixed is very different from automating something where a mistake reaches a customer or affects a financial record.

The processes that usually score well

The processes that usually shouldn't be automated, at least not fully

A practical way to score your own list

Write down every repetitive process your team handles. For each one, rate time saved, complexity and risk on a simple scale, and prioritise high time savings, low complexity, low risk first. Those are the fast wins that build momentum and free up time to tackle the harder cases. Processes with high time savings but also high complexity or risk aren't off the table, they just need more careful design, proper error handling, and usually a human checkpoint built into the workflow rather than full removal of human involvement.

What good automation looks like once it's built

Reliable automation isn't just a system that works when everything goes right. It includes error handling for when inputs are missing or malformed, logging so you can see what happened after the fact, and alerts so someone finds out immediately if something breaks instead of discovering it a week later when a report is missing. Automation without those three things isn't finished, it's a liability waiting to surface at an inconvenient time.

Start with one process, not ten

The teams that get the most out of automation rarely start with an ambitious, sweeping overhaul. They pick the single highest-scoring process from their list, build it properly with error handling included from day one, run it alongside the manual process for a couple of weeks to confirm it behaves correctly, and only then retire the manual version. That pattern, one process at a time, verified before the next one starts, is slower at the outset but avoids the common failure mode of automating five things at once and losing track of which one broke when something inevitably does.