Delete the Tasks Automation Should Never Touch

When Automating Makes You Busier

A two hour reconciliation job moves to a script. The script runs fine. Yet every Monday morning someone opens the logs to check the output, and when a number looks off, opens the source file to find where it drifted.

The work did not disappear. It changed shape. Two hours of doing became twenty minutes of checking plus the occasional half day when something breaks. The average improved. The feeling did not. The task used to be over when it was over. Now it is over once someone confirms it is.

Most automation reviews go wrong right here. Everyone asks how many days it takes to build. Almost nobody asks how many hours per month it adds after that. In a quoting conversation only the first number is visible.

Two Numbers Settle It: Frequency and Exceptions

The savings side is easy. Time per run multiplied by runs per month. The subtraction side is where estimates fall apart. Take out the minutes a human spends on exceptions, the hours spent repairing the job when the upstream system changes, and the time spent verifying that the output is correct. Exceptions carry the most weight of the three. If two runs in ten pull a person back in, that person still carries the task in their head, and the saving shrinks from hours to keystrokes. A task with frequent exceptions is not an automation candidate. It is a rules problem wearing an automation costume.

Frequency is blunter. Something that comes around once a quarter is usually better left manual even at three hours a sitting. A script written for four runs a year is already broken by its third run, and repairing it takes longer than doing the work by hand would have.

Things Break on Somebody Else’s System

Automation rarely dies of old code. It dies because the other side moved. A supplier adds a column to the spreadsheet they send. An admin console gets redesigned. Two factor authentication appears at a login screen that never had it. The more a job leans on something outside your control, the more maintenance it quietly accrues.

So when picking candidates, ask whether the interface will still look the same in six months before asking whether it works today. Jobs that move through a documented API last. Jobs that read values off a rendered screen stop the moment someone ships a redesign. Internal systems sit in between, because at least you know when they change. The same task has a different lifespan depending on which door it walks through, and that lifespan is the denominator in the payback math.

Send the List, We Will Cut It First

If several tasks are on your mind, send the list as it stands. Weple’s workflow automation starts by deciding what to remove from it. We sort candidates by how often each one runs, how much exception handling creeps in, and how much it depends on systems neither of us controls, then build what survives. If the arithmetic says a task is cheaper left manual, we will tell you that instead.