Which processes are worth automating.

Most failed automation projects automated the wrong process competently. The criteria below identify the difference before any money is committed.

Assessment criteria

Four criteria. All four must be met.

  • Does it repeat? Something that happens two hundred times a month is worth attention. Something that happens twice isn't, however annoying it is.
  • Does it follow rules rather than judgement? If you could write down how the decision is made and hand it to a new starter, a machine can follow it too. If the answer is "you just get a feel for it", that's judgement — leave it alone.
  • Can you count the unit? Claims, invoices, bookings, applications, job sheets. If there's no countable thing, you can't measure whether it worked, and you certainly can't price it fairly.
  • Is the information already written down somewhere? Email, a form, a PDF, a system. If the knowledge only exists in someone's head, the first job is getting it out — not automating around it.

Three out of four isn't a pass. The one that most often fails quietly is the second — plenty of work looks rules-based until you watch someone experienced do it and notice all the small exceptions they're handling without thinking.

Suitable

Processes with the fastest payback.

Retyping between systems

Information arrives one way and has to be entered another. Boring, high-volume, and completely rules-based. Almost always the cheapest win available.

Applying a written policy

Checking something against terms, criteria or eligibility rules. A machine applies the same rules the same way every time, which is often more consistent than three different people on a busy Friday.

Chasing

Pursuing missing paperwork or updates. Nobody enjoys it, everybody forgets, and it's the easiest thing in the world to do reliably.

The same report, every week

If someone assembles the same pack from the same sources on the same day, that's an afternoon a week that doesn't need to exist.

Not suitable

Four decisions to keep with a person.

Not because automation is technically infeasible, but because the cost of an incorrect decision exceeds the saving from a correct one.

Anything safety-related

If a wrong answer could hurt someone, a person signs it. There is no efficiency argument that survives contact with that.

Final compliance sign-off

A machine can gather the evidence and flag what's missing. A person should still be the one putting their name to it.

Releasing money

Match the invoice automatically, flag the discrepancy automatically — but let a human press pay. The cost of that click is nothing; the cost of not having it can be enormous.

Decisions about people

Hiring, discipline, performance. Obvious, but worth stating plainly, because software vendors will happily sell you otherwise.

The pattern: automate the gathering, checking and preparing. Keep the human on the deciding and committing. Almost all of the saving lives in the first part anyway — the judgement was never the expensive bit.

Common failures

Why automation projects fail.

It gets trusted too early. Switched on before anyone checked whether it matched how the business actually decides things. The fix costs nothing: run it silently alongside your team first and compare, before it touches anything real.

Nobody can see what it did. A system that can't explain a decision can't be corrected, only argued with. Insist that every outcome records the reason behind it.

It never gets updated. Businesses change; rules drift out of date; the thing quietly starts being wrong. Whoever builds it should be responsible for keeping it current, and that should be in the arrangement from day one.

And the expensive one — the wrong thing got built well. Which is the whole reason this page exists, and why we measure before we build rather than after.

Contact

Describe the process you want to automate.

You will receive a fixed price and a build plan.

There is no charge for the initial call and no obligation. You deal directly with the engineer who builds the system.

Book a call