Finding the job nobody should be doing: a method for business automation

Automation projects usually begin with a tool somebody saw, and then search for a problem it fits. That order produces dashboards nobody opens and workflow software that becomes another thing to update. The better order starts with a specific person doing a specific repeated thing, and a stopwatch. This is the method we use, including the arithmetic that decides whether a job is worth automating at all.

Look for retyping first

Every organisation has at least one place where a human reads a number from one screen, or a piece of paper, and types it into another. Retyping is the purest form of waste available: it adds no judgement, consumes attention, and introduces errors that are expensive to find later.

It is also the easiest thing to find, because the people doing it already know. Ask any team what the most annoying part of their day is and you will get an accurate answer immediately. You do not need a consultant to map your processes; you need to ask three people and believe them.

In a pathology laboratory the retyping was twenty numbers per CBC off an analyser slip, around eighty times a day. In a shop running both a counter and an online store, it was entering the same order twice, once for the customer and once for the accounts. Both were fixed by making the data arrive instead of being carried.

The four shapes automation takes

The 'listen' shape is the most underrated. Machines, payment gateways and other software are constantly emitting information that nobody is receiving. The analyser already knew the haemoglobin value; the laboratory was retyping it because no process was listening. Those projects are short and the effect is immediate.

The arithmetic that decides it

Before building anything, do this calculation honestly.

1. How many times a day does this task happen? Count, do not estimate.
2. How long does it take each time, measured with a stopwatch rather than remembered?
3. Multiply, and convert to hours per month.
4. What does that hour cost you, including the cost of the errors it produces?
5. Compare against the build cost plus a year of running it.

Two notes on step four. The error cost is usually larger than the time cost and almost always omitted: a transposed digit in a lab result or a GST filing costs far more than the seconds taken to type it. And if the task happens fewer than a handful of times a day, the honest answer is often that it is not worth automating, and a good vendor will tell you so.

A task done twice a day is a habit. A task done eighty times a day is a system waiting to be written.

What to automate last

Some tasks look automatable and should be left alone.

• Anything where the exception rate is high. If a third of cases need a human decision, automation adds a second path without removing the first.
• Anything whose rules are actively changing. Automate a process that is still being argued about and you will be rewriting it quarterly.
• Anything that is a relationship. The follow-up call that keeps a customer is not a template, and automating it is how businesses become annoying.
• Anything where being wrong is expensive and the check is a human reading it anyway.

Make the automation visible

The most common failure of a successful automation is that it breaks silently. An input format changes, a credential expires, a queue stops draining, and because nobody is doing the job any more, nobody notices for a fortnight.

Every automation we build is expected to say what it did. A counter of items processed, an alert when that counter is zero for longer than it should be, and a log that a human can read without a developer. When we built a WhatsApp delivery service, the design decision we care about most is the persistent queue: requests accepted while the session is down are written to disk and delivered on reconnect, so nothing is quietly lost. That is described in the case study.

A first project worth choosing

Pick the one that one person complains about every day, where the data already exists in digital form somewhere, and where you can count the occurrences without a study. That project will be short, the effect will be obvious to the people doing the work, and it will teach you more about your own processes than a mapping exercise.

Then do the next one. Automation compounds; a single ambitious project rarely does. If you want help choosing the first, tell us what the job is.

Frequently asked questions

How do I identify what to automate in my business?

Look for retyping. Find every place where a person reads data from one screen or document and types it into another, then count how often it happens and time how long it takes. Ask your team what the most annoying part of their day is; they will tell you accurately and immediately. Start with the task that is frequent, digital at both ends, and complained about daily.

How do I calculate the ROI of an automation project?

Multiply occurrences per day by the measured time per occurrence to get hours per month, cost those hours, then add the cost of the errors the manual process produces. Compare that annual figure against the build cost plus a year of running the automation. The error cost is usually the larger half and the one most often left out of the calculation.

What should I not automate?

Processes with a high exception rate, rules that are still changing, anything that is really a relationship rather than a transaction, and tasks where a human has to check the output anyway. In each case automation adds a parallel path without removing the manual one, which increases complexity rather than reducing work.

Why do automations stop working?

Usually because an input changed, a credential expired, or a queue stopped draining, and nobody noticed because nobody is doing the job any more. The fix is to make every automation report what it did: a count of items processed, an alert when that count is unexpectedly zero, and a log a non-developer can read.