What should you automate first?

Almost everybody picks wrong on the first attempt, and they pick wrong in the same direction: they start with the biggest, most visible process in the business. It is the one with the most steps, the most people involved and the most money attached, so it feels like the one worth fixing.

It is also the one where being wrong is most expensive, where the requirements are least stable, and where you will spend three months in meetings before anything runs.

A good first candidate has four properties. It happens often enough that you notice it. It follows the same steps nearly every time. It is annoying rather than dangerous, so a mistake costs an apology rather than a customer. And one person can describe it end to end without calling a meeting.

That combination usually points at something unglamorous: the report somebody rebuilds every Monday, the inquiries that get re-typed into a second system, the reminders that go out by hand. Nobody puts these on a strategy deck. They are exactly where the week goes.

Frequency times irritation, divided by blast radius. Something that happens daily, irritates the person doing it, and cannot hurt anybody if it gets one wrong is a better first build than something quarterly, tolerable and load-bearing.

You are not trying to save the most time on the first build. You are trying to learn how automation behaves in your business while the stakes are low, so the second and third builds can be ambitious.

Sometimes the honest answer is that a process should not exist. If three approvals are required because of an incident nobody remembers, automating all three is faster paperwork rather than less of it.

Writing a process down usually exposes at least one step that survives only because nobody has looked at it. Deleting that step is cheaper than any software, and it is the first thing we look for.