When repetitive work deserves software — and when it deserves a rule

There is a task in almost every business that eats half a day a week and that nobody can attach a customer to. Retyping orders from a notebook into a spreadsheet. Rebuilding the same report by copying last month's file and editing six cells. Sending the same four emails when an order arrives. It is boring, it is obviously waste, and the obvious conclusion is that it should be software.

Sometimes it should. Often it should not. The difference is not how many times you do it.

Repetition is the symptom, not the diagnosis

The advice usually given is to automate anything you do three or more times. That rule treats every repeated action as the same kind of problem, and produces software nobody uses. Three different things get called repetitive work:

• Mechanical work. The input is fixed, the output is fixed, and the steps do not change. Copying a delivery note into a register. A total that has to match a physical count.
• Judgement with mechanical edges. The decision changes each time — whether to extend credit, which supplier to call — but the gathering, the arithmetic and the recording around it do not.
• Work that exists because of an old constraint. Three signatures on a purchase order because one order went wrong in 2019. A daily export nobody has read since the person who asked for it left.

Only the first is a software candidate. The second is a candidate for automating its edges and leaving the decision with a person. The third should be removed, and building software for it is the most expensive way to keep it.

Four questions that separate them

Answer these before asking anyone for a price. They cost an hour.

1. Is the output a rule or a decision? If two competent people doing the task correctly can produce different results, it is a decision. Software can support a decision; it cannot make one that has not been made.

2. How often does the exception happen? A rule with two exceptions a year lives in a note on the wall. A rule with twenty exceptions a week is a requirement — and software that cannot express the exception gets bypassed, so the team keeps the spreadsheet and the automation becomes a second place to check.

3. What does the task cost per month, and what would keeping the automation cost per year? The first number is easy and it is the one people quote. The second is the honest one: an owner, a dependency, a failure mode, a deploy. A task that takes twenty minutes a month costs four hours a year, and a script will cost more than that to keep.

4. Who changes it when the rule changes? If the answer is "whoever wrote it, if they are still here", you are buying a dependency rather than a tool. That can still be right, but price it as one.

The case for not automating

Four reasons to stop, roughly in the order we meet them.

The rule has not been agreed. Two people disagree about what a confirmed order is, or when stock counts as reserved. Software does not settle that. It turns the disagreement into an error message, in front of a customer, at the worst possible moment. Write the rule down, run it on paper for a month, then build.

The exception is what you sell. If your largest customers negotiate price, the negotiation is the margin. Automating the calculation removes the conversation. Automate the preparation instead — the purchase history, the stock position, the floor below which the sale is not worth taking — and leave the last step to a person.

The step should not exist. Deleting a step is cheaper than automating it, and it is not the smaller achievement. A process written clearly enough for a new employee is often the whole fix.

The volume is too low to pay back. This is question three, and it is the most common reason a sensible-sounding automation should be refused.

There is a fifth case that looks like automation but is really a data problem: the input arrives on paper, by phone, in a message. Automating the step after that writes the mess into a database more reliably. Fix the form first — one page, fixed fields, one place it lands.

What a better rule looks like

Automation is one answer among several, rarely the cheapest. The right choice is the lowest form that survives the exceptions you actually have.

Form	Right when	What it costs to own
A written rule	The exception is rare and the cost of a mistake is small	A paragraph, and someone noticing drift
A better form	The input arrives unstructured and gets re-typed	The people filling it must accept it, which is the real work
A checklist	Sequence matters and skipping a step is the failure	Review, and occasional argument about which steps are real
A script	Inputs and outputs are fixed, the run is short, one person uses it	One owner, and a way to notice it stopped
A scheduled job	Same as a script, and nobody should have to remember	Time zones, partial failures, and silence when it dies
A tool with a person in it	Judgement matters, mechanics do not	Interface design, plus the cost of the judgement staying human
A system	Many people, shared data, rules that will change	Everything above, over years

Each row down is a larger commitment, not a better outcome. Moving up without a reason is how a business maintains a platform for a task three people do.

A better test: write the page of instructions you would give a new employee. If it contains a decision — "check whether the customer is late, then decide" — the build is a tool that supports a person. If it contains only steps and the fields they read, it is a script.

The failure mode of automation is silence

The cost of automation is not building it. A manual process that gets skipped is visible: the report is missing and someone asks. An automated one fails quietly and is discovered a month later when a total does not reconcile.

Three habits prevent most of that:

• The output must land where a person reads it, on a schedule they would notice missing.
• Failure must be loud and attributed. Something should say which job failed, on which run, and what it was supposed to produce.
• The code must be readable by someone other than its author. An automation only one person can change is a subscription to that person.

Where this advice stops

All of this assumes operational work inside a business: paperwork, recording, reporting, follow-up. It does not transfer to a production line or a regulated process where volumes are measured and the sequence is fixed.

It also assumes the process will stay roughly as it is for the next year. If a new branch, product line or acquisition is three months away, automating now freezes the version you are about to replace.

And the cost estimate in question three is an estimate: a way to compare two options with one method, not an accounting figure.

The honest version of the advice is unglamorous. Most repetitive work should get a better form and a written rule. A smaller share should get a script. Very little of it should get a system — and the ones that should are usually the ones that decide whether the month closes correctly.