How to recognise a task worth automating, and one that isn't

Not every repetitive task is worth automating. Some take time, but happen too rarely, vary too much or are too complex to formalise to justify the investment. Others could be automated, but only after simplifying the process around them. Knowing the difference helps avoid spending an automation budget in the wrong place.

Signs of a good candidate

The task comes up regularly, with a sufficiently predictable frequency. An action performed once a quarter usually does not justify a significant automation investment, even if it takes several hours on that particular day. By contrast, a few minutes repeated every day or every week can add up to a significant volume over a year.

The logic behind the task is stable enough to be described. If the person performing it can clearly explain the rules they apply, that is a good starting point for automation. If the decision depends on case-by-case judgement that is difficult to put into words, the reasoning needs to be understood first before trying to automate it.

The task creates errors or inconsistencies, particularly when it is performed frequently or under pressure. Automation can apply the same rules consistently, provided those rules themselves have been properly defined.

Several people perform the same task in slightly different ways. This can reveal a lack of standardisation. Before automating, you therefore need to decide which rule should actually apply. Automation can then help make that rule more consistent from one execution to the next.

Signs of a poor, or premature, candidate

The logic changes frequently. If the rules evolve regularly, an automation may require significant maintenance and reduce the expected benefit. It may be better to stabilise the process before trying to automate it.

The volume is too low to justify the investment. Automating a task that takes fifteen minutes once a month is technically possible, but the cost of designing, testing and maintaining it may exceed the time actually saved.

The upstream process is not yet stable. Automating a poorly defined process does not necessarily make it more efficient. It can instead lock in rules that were never properly validated and make their consequences harder to change later.

The task requires significant contextual judgement. Some decisions depend on information that is difficult to formalise or on human judgement that varies with the situation. That does not necessarily make automation impossible, but it first requires a clear understanding of what can be handled by rules and what still depends on judgement.

How to actually decide

Before asking how to automate a task, it is worth asking whether it should still exist in its current form. Some tasks may be better removed, combined or simplified rather than automated as they are.

Then estimate the time actually spent on the task over a given period, rather than looking only at the duration of a single execution. A ten-minute task repeated fifty times a week represents a very different volume from a two-hour task performed once a month. Also take into account errors, manual checks and other steps that may or may not disappear through automation.

Finally, describe the logic on paper before writing any code. What are the inputs? Which rules apply? What result needs to be produced? What happens in exceptional cases? If these questions cannot be answered clearly enough, automation is probably not the first step. The process needs to be clarified first.

The takeaway

A task is a good candidate for automation when it occurs often enough, is based on logic that can be explained, and represents a real cost in time, errors or inconsistency. Other tasks should first be questioned, simplified or standardised. The goal is not to automate as many tasks as possible, but to automate the ones where the benefit genuinely justifies the effort.