Automating processes: what to automate first, and what to leave alone

There's a version of this article that says automating reduces errors, saves time and improves the customer experience. It's true, and it's not very useful, because it doesn't help decide anything.

The real question isn't whether to automate. It's what, in what order, and what to leave alone. Automating the wrong thing costs money twice: once to build it, once to maintain it.

Before automating: look at the process

An automation doesn't fix a process. It runs it faster, without pauses, and without anyone noticing what was wrong.

A concrete example: if invoicing requires someone to manually check every order because customer data arrives incomplete, automating invoice issuance produces incorrect invoices at higher speed. The problem wasn't in issuing them — it was in how the data got captured.

How to choose what goes first

A simple rule helps, and it helps because it ranks candidates that would otherwise get chosen by whoever complains loudest:

Priority = frequency × time per occurrence × cost of getting it wrong

• Frequency. Something that happens a hundred times a month is worth more than something that happens once a year, even if the yearly one takes a full afternoon.
• Time per occurrence. How long it takes today, including the context switch: interrupting another task to copy data between two systems costs more than the minutes the clock shows.
• Cost of error. A typo on an internal list gets corrected. An error in a billed amount, a payment, or data sent to a government body has consequences.

The best candidates are processes that are frequent, with clear rules and expensive consequences. The worst are the infrequent ones that require judgment.

The usual suspects

• Moving data between two systems that don't talk to each other. Someone exports from one and imports into the other. It's the most common case and almost always the best return, because it's pure mechanical work.
• Payment reconciliation. Matching what the bank says against what the system says is repetitive, frequent, and expensive when it fails.
• Reminders and follow-ups. Collections, renewals, due dates. They depend on someone remembering, and that's the part that fails.
• Recurring reports. If someone builds the same report every Monday, the report should just arrive on its own.
• Customer or user onboarding. Creating accounts, assigning permissions, sending credentials, loading initial data.

What's better left alone

• Anything that requires judgment. Approving an exception, deciding on a doubtful claim, negotiating. You can automate what surrounds the decision — gathering the information, keeping the record — but not the decision itself.
• Anything that changes all the time. If the rules change every couple of months, the automation spends its life in maintenance.
• Anything that happens very rarely. A twenty-minute quarterly process costs eighty minutes a year. An automation costs more than that just to build.
• Anything nobody fully understands. Automating a black box just makes it a faster black box.

What separates a reliable automation from one that creates work

This is where it gets decided whether the project saves time or eats it. Almost every automation that ends up abandoned failed on one of these five points.

1. Idempotency

Running the process twice must produce the same result as running it once. Otherwise, a retry after a network error generates a duplicate invoice or a double charge. In practice: every operation needs a key that lets the system recognize "this already happened."

2. Explicit error handling

An automation is going to fail: the other system goes down, a field comes in empty, the API changes. The question is what happens then. Retry with increasing backoff where it makes sense, and when it no longer does, notify a person with enough information to act. What can't happen is failing silently, because then the problem gets discovered weeks later, through its consequences.

3. A record of what it did

What ran, when, with what data, and with what result. Without that, the question "why did this customer get two emails" has no answer.

4. Input validation

If the automated process consumes data from a form, a file, or a third party, it has to validate before processing and reject bad data early. A bad piece of data stopped at the entrance is an incident; the same data three steps further in is a manual correction across several systems.

5. The ability to step in

Being able to pause, reprocess a single case, and fix something by hand without fighting the system. Every automation needs a handle for when something goes sideways, and it's worth building it in from the start.

Where to actually start

1. Track for two weeks what repetitive tasks the team does and how long they take. Without that list, the choice is based on impressions.
2. Rank with the criterion above and pick one — the one with the best ratio of frequency to effort.
3. Write the process out in steps, including what happens when something fails. If that document is hard to write, the exercise already paid for itself.
4. Measure the baseline. How long it takes today, how many errors it has. Without this there's no way to know if it worked.
5. Build the minimum version that handles the main case, with edge cases routed to human review. Trying to cover 100% from day one is what drags these projects out until they get abandoned.
6. Run the automation in parallel with the manual process for a few iterations, comparing results, before trusting it.

The cost almost nobody budgets for

An automation is software, and software needs maintenance. When the bank changes its file format, when the vendor's API gets updated, when the business adds a new rule, someone has to adjust it. That's not an argument against automating: it's an argument for automating what justifies it, and against filling the operation with twenty fragile flows nobody remembers building.

In short

Automating well is mostly an exercise in selection. A frequent process, with clear rules and expensive consequences, automated with retries, logging and a handle to step in, pays for itself fast. An automation built on a process nobody understood first doesn't.

Let's talk about what's worth automating in your operation