Every business has a person who is really an integration. They receive something in one system, retype it into another and send an email to say they have done it. They do this forty times a week and they have never mentioned it because it is just the job.

Finding those people is the whole of business automation. What follows is a method for doing it properly rather than automating whatever was most recently annoying.

Step 1: find the candidates

Ask a specific question rather than a general one. What could we automate gets you nothing. These get you a list:

  • What do you do every day that feels like typing something twice?
  • Where do you copy information from one screen into another?
  • What would not happen if you were off for a week?
  • What do you chase people for?
  • What do you have to remember to do, rather than being prompted?

That last question is the most productive. Anything held in somebody's head is both a candidate for automation and a risk sitting quietly in your business.

Step 2: score them honestly

Four criteria. Score each one to five.

Frequency. Daily scores five, monthly scores one. Frequency compounds, and a small saving on something that happens forty times a week beats a large saving on something quarterly.

Duration. How long each occurrence takes. Measure it rather than estimating, because estimates are consistently wrong in both directions.

Systems touched. More systems means more manual copying and more room for error, so more value in automating. It also means a harder build.

Rule clarity. Can the process be written as unambiguous if-this-then-that steps? If the answer involves it depends and you get a feel for it, score it low. Judgement does not automate, and pretending otherwise is how automations produce wrong outcomes at speed.

Multiply frequency by duration for the size of the prize. Use rule clarity as a gate rather than a score — anything below three is not ready regardless of how big the prize looks.

Step 3: fix the process before automating it

The most expensive mistake in this field is automating a broken process, because you now have a broken process that runs faster and is harder to change.

Before building anything, ask three questions about the process as it stands:

  • Does every step need to happen? Approval steps in particular accumulate. Somebody approves something in ninety-nine per cent of cases and nobody has asked why for four years.
  • Is it in the right order? Processes grow by accretion and frequently collect data late that would have prevented work if collected early.
  • Does the output get used? Reports produced weekly and read by nobody are common. Do not automate them. Stop them.

It is normal to find that a candidate process should be deleted rather than automated. That is the best possible outcome and it costs nothing.

Automating a process nobody has questioned in five years is how businesses end up with a very efficient way of doing something pointless.

Step 4: build the first one properly

Pick the highest-scoring candidate with clear rules. Not the biggest one — the first automation is as much about proving the approach as about the saving.

What "properly" means in practice:

It tells somebody when it fails

The single most important design decision. An automation that silently stops is worse than no automation, because everybody assumes it is still running, and nobody is doing the task.

Failures go to a named person, by a route they will actually see. Not an unmonitored mailbox.

Somebody other than the builder understands it

Write down what it does, what triggers it, what it touches and how to run the steps manually if it is down. One page. This is what stops an automation becoming a liability when the person who built it changes job.

It has a manual fallback

For the day the platform has an outage or a supplier changes an API. Knowing the manual route exists is what lets people trust the automated one.

It is measured

How many times it ran, how many failed, how much time it saved against the baseline you recorded in step two. Without this the renewal conversation in a year has no evidence in it.

Step 5: expand deliberately

One process at a time, each fully finished before the next starts. Businesses that announce a programme of twenty automations complete two.

Somewhere around the third or fourth you will hit the real constraint, which is almost never the automation platform. It is that two systems cannot talk to each other properly, and the person has been the integration. At that point the conversation becomes system integration, and that is where the larger savings sit.

What good looks like after a year

Five or six processes running unattended. Each documented, each alerting on failure, each with a manual fallback nobody has needed. A measured saving somewhere between four and fifteen hours a week across the business.

Not a transformation. A business that has quietly stopped doing several things by hand and has the evidence to show for it.

If you would like a hand finding and ranking the candidates in your business, our business automation team runs exactly this exercise and will tell you honestly which processes are worth the money and which should simply be stopped. Get in touch.