How to decide what to automate first

What makes a process a good first candidate?

Three things at once. It repeats often enough that the time adds up. It follows roughly the same steps every time, so the automation does not need to handle endless special cases. And it gets skipped under pressure, which means automating it recovers work that is currently being lost rather than merely speeding up work that already happens.

A process that is frequent and identical but never skipped is still worth automating eventually. It is just a worse first project, because the improvement is harder for anyone to feel.

Why does the forgetting test matter so much?

Because a first automation has to earn trust, and trust comes from a visible result. If you automate something that already happened reliably, the team experiences a small time saving and a new system to learn. If you automate the follow-up that half the time never went out, the team experiences work appearing that used to fall through.

The second one gets you a second project. The first one gets you a shrug.

Which processes usually qualify?

In practice, three keep coming up for small businesses. Post-meeting follow-up, because it is frequent, structured, and the first thing dropped on a busy day. Intake, because the same questions get asked every time and the answers need to land in a system. And routine inbound calls, because booking and rescheduling are highly repetitive.

This is a pattern rather than a rule. The right first project is whichever process in your business meets all three tests, and finding it is the point of mapping the work before building anything.

What should you not automate first?

Anything where the steps genuinely change every time, anything that needs judgment you cannot articulate, and anything touching a system nobody can get access to. Also, anything where the person who does it today is not part of the conversation, because they know the exceptions and the automation will meet all of them.

Compliance-sensitive and money-moving processes are worth doing eventually and worth doing carefully. They are poor first projects because the tolerance for error is near zero.

How do you know it worked?

Decide the measure before building, and prefer counting over estimating. How many follow-ups went out this month against last month. How many records were updated without anyone typing. How many calls were answered rather than missed.

If you did not record the number before, you cannot claim an improvement afterwards. Writing down the current state is genuinely part of the work, and skipping it is why so many automation projects have no evidence they helped.

The three tests, applied