Automation

Where to start automating

How to find the one process worth automating first, and why the biggest annoyance is usually the wrong starting point.

Published 8 August 2026

Almost every company has a list of things that should work differently. The problem is rarely a shortage of ideas, but the order. Starting with the most visible problem often means starting with the most expensive one. In earlier work the gain almost always started with the dullest process, not the most conspicuous one. There is a better way to choose.

Do not start with the biggest annoyance

The biggest annoyance is usually also the most entangled process: it touches four departments, three systems, and a habit nobody dares change. Starting there means months of work before anyone notices anything. Start instead with work that happens often, has few exceptions, and is done by one person or team. That produces results sooner, and those results make the next piece easier.

Count the work, do not estimate it

For one week, ask the people doing it how often something occurs and how long it takes. Note it down as it happens, rather than reconstructing it afterwards. Almost always the time turns out to be distributed differently from what management assumes: the process everyone complains about costs two hours a month, while the step nobody mentions costs twenty because it happens twenty times a day.

Four candidates that almost always surface

Retyping data from one system into another, or out of an email into a system.
Sending status updates by hand: where is my order, has the invoice arrived, is the appointment confirmed.
Reports someone assembles monthly from several sources.
Checking whether something happened, instead of being alerted when it has not.

Do not automate a process that is wrong

If the process itself is crooked, automation mostly speeds up doing it crookedly. Walk through the steps once and cut what does not matter. In practice that exercise regularly removes a quarter of the actions, simply because nobody had ever asked why they were there. What remains is cheaper to build and easier to explain.

Make failure visible

Automated work disappears from view, which is exactly the point, until it stops. So always build in that someone hears when something did not succeed. An integration sitting broken for two days without anyone noticing costs more than the manual step ever did.

Frequently asked

Our processes are not documented anywhere. Do we need to do that first?

Not the whole company, no. Describe only the process you tackle first, and do it together with the people who carry it out. That usually costs a morning and produces insight straight away.

Can we do this with standard tools like Zapier or Make?

For simple chains, often fine, and then it is the cheapest route. It usually breaks down once exceptions appear, once a lot of data flows through, or once you want to see why something failed. That is the moment to build it properly.

How long does a first piece take?

A bounded automation between two systems is usually a matter of weeks, not months. Which is also why it makes a good starting point: you find out quickly whether the assumption held.

What if our people do not use it?

That is the real risk, and it is avoided by involving them from the start. People who helped shape how it works will use it. People who have it imposed will build around it.