What to automate first in admin work

Admin is where a company's repetitive tasks pile up — and, at the same time, where a mistake can cost the most: it touches invoices, collections, payments and obligations to third parties. So the relevant question isn't whether to automate — there are almost always candidates — but what to automate first. Choosing the first task well determines much more than that one saving: it determines whether the team trusts the next automation or, with good reason, quietly works around it. This article offers an ordering criterion, not a task catalogue: the conditions the first candidate must meet, where those conditions tend to hold, and what should stay with people even when it's repetitive.

The usual mistake: starting with what hurts most

The instinct is to automate the heaviest task first — the one everyone hates. It's usually the worst candidate, for a reason that appears the moment you turn the question around: that task hurts precisely because it's full of exceptions, edge cases and decisions nobody has ever written down. What makes it miserable for a person is exactly what makes it hard for a machine.

Starting there produces a recognisable pattern: the attempt drags on, the result covers half the cases, the team spends more time babysitting the automation than they ever spent on the task, and the conclusion left hanging in the air is "this automation thing doesn't work". It works fine — it was just started from the wrong end.

Three conditions for a good first task

The first task you automate should meet three conditions at once:

• High frequency. It repeats daily or weekly. Not only because the saving shows up sooner: an automation that runs often gets tested often, and its failures surface early, while people are still watching. A quarterly task takes a year to prove itself.
• Clear rules. The whole procedure can be written down without a single "it depends". The honest test: if the person doing the task occasionally has to ask someone, or resolve cases by feel, the rules aren't clear yet — they live in someone's head, which is a different thing.
• Low cost of error. If it fails, the failure is easy to spot and cheap to fix before it leaves the building. The first automation should touch nothing where a mistake reaches a customer, the bank or a public authority before someone inside notices.

All three at once — and this matters: two out of three doesn't qualify. Frequency and rules without a low cost of error means taking a real risk in order to learn; frequency and low cost without clear rules means freezing ambiguity into the system; rules and low cost without frequency means effort that neither pays off nor teaches anything.

Where those conditions tend to hold in admin

No universal recipe — every admin function is its own — but the three conditions tend to coincide in tasks like these:

• Sorting and filing what arrives. Invoices from regular suppliers, notifications, statements: documents with a stable format that someone currently drags into folders and trays by hand.
• Reminding, not managing. Alerts for due dates, outstanding payments, renewals. The reminder is pure rule and calendar; the follow-up isn't. Automating the alert and leaving the handling to a person is a clean boundary.
• Entering the repeated record. Creating the same type of record with the same fields, many times a week, is pure rule; the special cases get set aside and stay with a person.
• Answering the identical question. Queries that arrive over and over with the same answer — where is my invoice, what's your account number — can at least get a prepared first reply.

What these tasks share: nobody will miss doing them, nobody will argue about the rule, and a failure gets fixed the next morning without ever leaving the building.

What stays with people

Just as important as the candidate list is its opposite. These stay with people, however repetitive they are:

• Anything with judgement inside. Deciding whether a good customer gets an extension on a payment isn't a rule — it's a relationship. Automation can prepare the information; the decision, no.
• Anything carrying relationship weight. Chasing an overdue invoice from a customer of many years can be triggered by an automatic internal reminder; the message that customer receives deserves a person choosing the tone.
• The exceptions. Every automated process needs a clear exit for the odd case, and that exit is a person with judgement. If exceptions have no owner, they end up inside the machine — badly.
• The repetitive but high-stakes. Repetition doesn't make something harmless. Payments go out every week, and they're the last thing that should ever run without human eyes on them.

The useful distinction isn't "manual versus automatic" but where the cut goes: the machine prepares, reminds and executes what's rule-bound; the person decides, signs and deals with people.

The order is a strategy, not a queue

Choosing the first task this way has an effect beyond the saving: every automation that works buys trust for the next one, and every task prepared for automation forces rules out of people's heads and onto paper. That writing-down work is valuable in itself: after the first two or three, some tasks that looked impossible to automate no longer do — not because the technology changed, but because putting them in order was the missing part. And if no task in your admin function meets all three conditions today, that is the real finding: the work ahead isn't automation, it's putting the processes in order first.

Three questions to pick the first one

1. Does it repeat often enough for the saving to show and the failures to surface early?
2. Can the person who does it write down the complete rule without a single "it depends"?
3. If it fails one day, would you see it inside before anyone outside notices?

The task that gets three yeses is the first. It won't be the most glorious one; it will be the one that makes all the others possible.