What to automate first when everything looks automatable

When a company decides to automate, the candidate list writes itself and it is long. Someone mentions the month-end report, someone else user provisioning, someone else reconciling CRM against billing. They all sound like good ideas and none of them has a number next to it.

That is the real problem: not a shortage of candidates, but a shortage of criteria for ranking them. Here is the method we use.

First, the arithmetic

Before evaluating tools, measure. For each candidate process, three figures:

• Frequency. How many times a month it happens.
• Duration. How long it takes each time, actually measured rather than recalled. Asking whoever runs it to time three executions usually reveals it takes twice as long as everyone assumed.
• Error rate. How often something has to be redone each month, and what each correction costs.

Frequency times duration gives you hours per month. It is an uncomfortable number to look at, and it is exactly what you need to decide.

Second, feasibility

An expensive process is not always automatable. Three questions filter it:

Are the rules explicit? If someone can write down on one page what to do in each case without using the phrase “it depends”, the process has rules. If the answer for half the cases is “María handles those, she has a feel for it”, not yet.

Do the systems have a way in? An API, a scheduled export, database access, even automated email that can be parsed. There is almost always a route; when there genuinely is not, it is better to know before budgeting.

Will the rules still be the same in six months? A process whose rules change every quarter produces a workflow that has to be rebuilt every quarter. Maintenance eats the saving.

Third, picking the first one

With cost and feasibility on the table, the choice nearly makes itself. But it is worth resisting the pull toward the most expensive process, which tends to be the most complex and the most critical too.

The first workflow should meet three conditions: a clear and measurable saving, moderate complexity, and tolerable consequences if it fails. Automating invoicing as your first project means starting where an error shows up in a customer’s accounts. Automating the consolidation of an internal report offers the same learning at a tenth of the risk.

The point of the first workflow is not to maximise savings. It is for the organisation to learn to operate automated processes — to watch them, correct them, and trust them — before something critical rides on top.

What almost nobody measures, and should

The cost of concentrated knowledge. When a process depends on one person, the cost is not just their hours: it is that the process stops when that person is off sick or on holiday. That risk rarely makes it into the calculation and is often the strongest reason to automate.

The cost of latency. A report consolidated by hand every Monday means six days of decisions made on stale data. Hours saved is the visible part; deciding on yesterday’s data instead of last week’s is usually worth more.

When should you not automate?

There are three cases where the right answer is to leave it alone.

When the process happens a few times a year, however many hours it eats each time. When the process is about to change because the system underneath it is being replaced — automating on top of something that is going away is money burned. And when the process, looked at closely, turns out not to need to exist; sometimes the act of mapping it reveals that it runs on inertia and nobody uses the output.

That last case is more common than you would expect, and it is the best possible outcome of a diagnostic: eliminating a process costs less than automating it.