Deciding what to automate

How to decidewhat to automate

Deciding what to automate is a shorter conversation than most people expect. Four signals say a workflow is worth building against, two say leave it alone, and one map settles the rest. It is written out here in full, with nothing to register for.

Four signals

What makes a workflowworth building against

01

It happens on a schedule or a trigger

Something starts the work: an email lands, an order posts, a date passes. Work that begins because a person noticed is work whose volume you cannot yet measure.

02

The decisions can be written down

Not "the team knows what to do". If the rules can be stated, the exceptions can be named, and someone can say what happens in each, the process is describable enough to build against.

03

The inputs arrive in a consistent shape

The same fields in roughly the same places. Variation is fine and expected; unbounded variation means the first piece of work is standardising the input, not automating the process.

04

Someone can say what it costs today

Volume, time per item, people involved, rework rate. An estimate is enough to start. Without one there is no baseline, and without a baseline there is nothing to price an outcome against.

Two signals to stop

When the answer isleave it alone

Saying this early is cheaper for everyone than discovering it in month three, and it is the part of the method that makes the other four signals worth trusting.

It is about to change anyway

A process being redesigned, a system being replaced or a regulation arriving next quarter. Automating the version that is going away buys a migration, not a saving.

It happens rarely and costs little

A quarterly task that takes an afternoon does not repay a build, an operating arrangement and the attention of keeping it correct. Say so early; it is cheaper than finding out in month three.

The map

Five things to drawbefore estimating anything

01

The trigger

What starts the work, and how the system finds out. Almost every automation that fails in production fails here first.

02

The systems touched

Every place data is read from or written to, including the spreadsheet nobody mentions in the first conversation.

03

The decisions

Each point where a person chooses, what they are choosing between, and what information they use to choose it.

04

The waiting

Where work sits because it is queued behind a person, an approval or another system. Waiting is usually the largest number on the map and the one nobody has measured.

05

The exceptions

The awkward cases. One real exception tells you more about the process than ten clean examples, and the exception path is what decides whether the build is four weeks or twelve.

Before it runs unattended

The safety questionsworth settling first

A useful automation has an explicit uncertainty path: below a confidence threshold, the item queues for a person rather than proceeding on a guess. If nobody has decided what that threshold is, the system does not yet have one.

Anything where a wrong answer carries a material consequence: money leaving, a commitment made to a customer, a record a regulator will ask about. Approval gates are a design decision, not a fallback.

An upstream system will be unavailable at some point. The question is whether the work waits safely and resumes, or is silently lost, and that is answered when the system is built rather than when it happens.

It should be, for as long as the new one has not proven itself on real volume. A cutover with no way back is a decision you only get to make once.

A named response path, agreed before launch. If the answer is "the operations manager notices in the morning", the system is not operated, it is merely deployed.

The engagement that builds this

Or compare all six engagements →

In practice

Processes that passedthe same test

Read next

The rest ofthe method

Have one in mind?

Describe the workflow.We will tell you if it is worth it.

Bring one process and roughly what it costs today. If the answer is that it should be left alone, that is the answer you get.