How to Tell Whether a Task Should Be Automated

The standard advice on automation is to look for repetition. If you do something the same way more than a few times a week, automate it. It is reasonable advice and it produces a lot of automations that nobody wants and some that quietly cause damage.

Repetition tells you the potential saving. It says nothing about the risk, and risk is what determines whether automating is a good idea.

The two questions that matter more than frequency

If this runs wrong, how bad is it? Not how annoying — how bad. Sending a duplicate internal notification is annoying. Sending a duplicate invoice to a customer is a phone call, a refund, and a small dent in your credibility. Applying a wrong discount to every order for a week is a different category again.

If this runs wrong, how long before someone notices? This is the question almost nobody asks, and it is the more important of the two. A failure that is obvious within an hour is a nuisance. The same failure, discovered in six weeks, is a data cleanup project and a set of conversations with customers about why their records are wrong.

Multiply those two and you get the real cost of the automation being wrong. Compare that to the time saved. Frequency only tells you one side of the equation.

Three categories, and only one is simple

Tasks where being wrong is cheap and visible. Formatting, filing, routing an enquiry to the right inbox, creating a draft for someone to review. Automate these freely. If the automation misbehaves, a human sees the output before it matters, and correcting it costs seconds.

Tasks where being wrong is expensive but immediately visible. Sending a quote, scheduling an appointment, charging a card. These can be automated, but they need a confirmation step or a short reversal window. The automation does the work; a person or a delay provides the check.

Tasks where being wrong is expensive and invisible. Updating records in bulk, syncing data between systems, applying rules that change what a customer sees or pays. This is the dangerous category, and it is where most automation regret lives. Automate here only with monitoring that would actually catch a fault — meaning something that checks the outcome, not something that checks whether the job ran.

The failure mode specific to automation

Manual processes fail one instance at a time. A person makes a mistake on one order, notices, and fixes it. The error is bounded by the person's attention span.

Automated processes fail uniformly, on everything, until someone intervenes. That is usually presented as a reliability advantage, and for correct automations it is. For an automation with a wrong assumption in it, uniformity is precisely the problem: it applies the mistake consistently, at scale, without the small frictions that cause a human to stop and think.

This is why "it has been running fine for months" is weak evidence. It has been running the same way for months. Whether that way is right has not been tested by the running.

The retry problem, in plain terms

Anything that talks to another system inherits a specific hazard worth understanding before you build.

A request can succeed on the far end and still fail to report back. From the sending side, "it worked but I never heard" is indistinguishable from "it never arrived", so the sensible thing is to try again — and the result is the action happening twice.

The property that makes retrying safe is idempotency: the effect of multiple identical requests being "the same as the effect for a single such request" [1]. In practice it means each operation carries a key the receiving system remembers, so a repeat is recognised rather than re-executed.

The practical implication for anyone commissioning automation is a single question: what happens if this runs twice? If nobody can answer, the automation is not ready, whatever its logic does on the happy path.

Automating across a connection you do not control

Automations that reach into other services — a calendar, an inbox, a payment provider, a social account — run on delegated access. The framework everything uses is designed so an application can "obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf" [3].

Two consequences follow that matter for the automate-or-not decision.

The access can be withdrawn without you doing anything: a token expires, a password change invalidates a session, a provider tightens a scope. The automation then fails, and whether it fails loudly is a property of how it was built.

And the grant usually belongs to a person. An automation authorised by an employee stops when that employee leaves, at an unpredictable moment, in a way that will not be connected to their departure by whoever investigates.

Neither is a reason to avoid automating. Both are reasons to prefer automations whose failure is noisy, and to be wary of ones whose failure looks like nothing happening.

The tempting automations that are usually wrong

Anything that decides which customers matter. Scoring, prioritising, routing by predicted value. These automations encode a judgement, apply it invisibly, and remove the human moment where somebody might have noticed the judgement was wrong.

Anything that writes to a customer in your voice without review. The saving is small and the failure is public.

Anything that exists to make a report look complete. Automatically filling a field so a dashboard shows full compliance produces a dashboard that means nothing. This is the same instinct as collecting data speculatively "in case it is useful later" [2] — motion that resembles rigour.

The order of operations

Do the task manually until you are sure of the rule. Most automation failures are automations of a process nobody had actually pinned down; the automation forced a decision that was previously made case by case, and made it badly.

Write down the rule in a sentence. If you cannot, the process is not ready to be automated — that is a finding, not a delay.

Automate the boring middle. The trigger and the output are usually fine to leave with a person; it is the repetitive part between them that is worth the machine.

Then decide, deliberately, how you will find out when it breaks. An automation with no answer to that question is not saving you work. It is deferring it, with interest.