How to work out what to automate first

Most people pick wrong. They pick the job that annoys them most, or the one that eats the biggest block of time. Both are reasonable instincts and both tend to produce a system that costs more than it saves.

Here is a better test. It takes about a week and costs nothing.

Write down the interruptions, not the tasks

For five working days, every time you do a piece of work that you have done before in exactly the same way, write one line: what it was, and roughly how long it took. Don’t tidy it up. Don’t batch it. One line, in the moment.

At the end of the week you will have a list that looks nothing like the list you would have written from memory. Memory returns the annoying jobs. The notebook returns the frequent ones.

The frequent ones are where the money is.

Score each line three ways

Go through the list and mark each entry:

1. How often does it happen? Per day is better than per week. Per week is better than per month. Frequency compounds; size doesn’t.
2. Could you write the rules down? Not “could a computer do it”, but could you explain it to a new starter in a paragraph. If yes, it is automatable today. If it needs judgement, it may still be automatable, but it is a harder and more expensive build.
3. What happens when it goes wrong? A misfiled document is recoverable. A wrongly-sent invoice is embarrassing. A wrongly-paid one is worse. High consequence doesn’t rule a job out, but it does mean you want a human approving the last step, and that changes what you build.

The best first candidate is high frequency, writeable rules, low consequence. It is almost never the job you were angriest about on Monday.

Two things that look like good candidates and aren’t

The annual job. Someone always suggests the year-end process. It takes four days and everybody hates it. But it runs once. You will spend longer building it than doing it, and by the time it runs again the process will have changed.

The job only one person understands. This one is tempting, because the key-person risk is real. But if nobody can explain the rules, nobody can check the automation is right either. Write the process down first, run it manually from the written version for a month, then automate it. The writing-down is most of the value anyway.

What “good” looks like after the first build

A first automation should be boring within a fortnight. If you are still checking it every morning after three weeks, it isn’t finished. Either the rules were wrong or the edge cases weren’t handled, and someone should be fixing that rather than you watching it.

That is, incidentally, the reason we run the systems we build. The first two months of any automation are when you find out what you got wrong about the process. Handing that over to the client is handing them the worst part.

---

If you want a hand with the list, send it to contact@zhorx.com. We will tell you which line we would start with and why, and if the honest answer is that none of them are worth automating yet, we will tell you that instead.