The wrong instinct

Most companies want to automate the thing that irritates them most.

Usually that is the most complicated process, with the most exceptions, crossing the most departments.

Which makes it the worst place to start.

Three reasons:

It is hardest to build, so it takes longest and costs most.

It has the most exceptions, so it is most likely to disappoint.

It is your first attempt, so you will make first-attempt mistakes on the highest-stakes project.

Start with the dullest high-volume task instead. You learn the tooling, prove the value, and build credibility for the harder ones.

Scoring candidates

Five questions per process. Answer them honestly.

How often does it run? Daily is excellent. Weekly is good. Monthly is marginal. Quarterly is not worth it.

How long does one run take? Multiply by frequency.

How rule-based is it? Can you state the logic, or does somebody decide?

How structured is the input? Consistent format, or whatever arrives.

How stable is it? Unchanged for a year, or changing monthly.

A process that is frequent, long, rule-based, structured and stable is your first candidate.

The saving, calculated honestly

Minutes per run × runs per month × the cost of that time.

Then subtract:

Build cost. Time or money.

Licence cost, if any.

Maintenance. For as long as it runs. This is the part people leave out.

A rough guide: if the annual saving is not several times the annual cost including maintenance, it is marginal.

Marginal automations get abandoned when whoever built them leaves — and then you have paid for the build and get nothing.

The savings people forget to count

Time is the obvious one. Three others often matter more.

Errors avoided. A person entering four hundred records makes mistakes. The cost of one wrong entry reaching a customer can exceed a year of time saved.

Delay removed. A process that runs overnight instead of when somebody gets to it. For order processing or stock allocation, hours matter.

Things that start getting done. The reconciliation nobody had time for. The supplier review that never happened. Automation often adds work that was being skipped rather than only removing work being done.

That third one is frequently the largest benefit and it never appears in the business case.

What to leave alone

Processes with judgement at the centre. Automate the gathering, leave the deciding.

Rare processes. Twice a month does not clear the fixed cost.

Unstable processes. Changing monthly means reworking monthly.

Contested processes. If two departments disagree about how it works, that is not a technology problem and automating it will not settle it.

Processes that should not exist. Ask before you build.

The three usual first projects

These come up repeatedly, and for good reason.

Document handling

Reading supplier invoices, receipts or forms into your system.

Why it works first: high volume, dull, and instantly verifiable — the document is right there, so you can see whether the result is right.

Low risk to adopt, because errors are visible immediately.

Data movement between systems

Records from one place into another, on a schedule or on an event.

Why it works: entirely mechanical, and somebody is currently doing it by hand.

Check first: does an API, an import function or a direct URL already do it? This question is asked too rarely.

Notification and routing

Getting information to the person who needs it, without somebody remembering.

Why it works: low risk — nothing is created or changed, only communicated. And it often surfaces problems earlier, which is worth more than the time saved.

Sequencing after the first

Once one works:

Do a similar one. Reuse what you learned and what you built.

Then something adjacent. A different process, same systems.

Then something harder.

Do not jump to the complicated one after a single success. Two or three straightforward automations build both capability and credibility.

Before you commit

Five checks.

Is the process documented and agreed? Including exceptions.

Does an existing system setting already do it? Check properly.

Who will own it? Name the person.

How will we know if it fails? If you cannot answer, fix that first.

Have we measured the baseline? Otherwise you cannot say afterwards whether it helped.

A “no” to any of these is a reason to wait, not a reason to proceed carefully.

The mistake worth naming again

Automating a process nobody questioned.

Before building anything, per step: why does this exist, who uses the output, what would break if we stopped?

Removing three of eight steps saves more than automating all eight, and costs nothing to maintain afterwards.

That is the highest-return work in any automation project, and it happens in a conversation rather than in a build.

The short version

Start with the dullest high-volume task, not the most annoying one.

Score candidates on frequency, duration, rules, structure and stability.

Calculate the saving including maintenance — that is what separates a real case from an apparent one.

And count the savings people forget: errors avoided, delay removed, and work that starts getting done because it is no longer manual.