Automation or Another Admin? An Honest Comparison

The comparison people actually make

The decision usually arrives in a specific form: the team is drowning, and there is enough budget for one of two things. An extra pair of hands is familiar, available in six weeks and easy to reverse. A software project is unfamiliar, takes longer to arrive and feels irreversible. Most owners choose the hire, and quite often they are right.

But the comparison is rarely made properly, because the two options are costed on different timescales. A salary is an annual number that recurs quietly; a build is a one-off number that lands with a thud. Put both on a three-year horizon and the picture changes.

Three-year cost, side by side

Fully loaded means salary plus employer NI, pension, holiday, equipment, software seats, management time and recruitment. For a £26,000 salary that lands nearer £34,000 in practice.

Where hiring genuinely wins

This is not a piece arguing that people are obsolete. There are categories of work where a hire is straightforwardly the better purchase.

• Work needing judgement under ambiguity — a difficult customer, a supplier negotiation, a case with no precedent.
• Work that is a relationship — the person your best account phones directly.
• Work that changes shape every month. Automating a moving target wastes the build.
• Physical work, obviously, and anything requiring presence.
• Low volume. Four invoices a week does not justify a project, whatever the enthusiasm.

Where automation wins outright

The mirror image: high frequency, low judgement, high error cost, stable for at least a year. Re-keying, matching, routing, chasing, formatting, notifying. Software does these at 3am on a bank holiday, never gets bored on the four-hundredth record, and applies exactly the same rule every time.

There is a quality argument as well as a cost one. Human error on repetitive data entry runs at roughly 1% even with careful people. That is not carelessness — it is what attention does over hours. A correctly built automation does not have that failure mode, though it has others.

The middle path most people miss

The framing of “hire or automate” is usually false. The best outcome we see is a smaller version of both: automate the mechanical 70% of the workload, then hire part-time or reallocate an existing person into the judgement work that is left.

One client planned two admin hires. They spent £14,000 automating order intake and invoice matching, hired one person instead of two, and moved that person onto account management. The second salary was never spent and revenue per head went up.

The risks nobody mentions on either side

Automation carries real risks and it is dishonest to pretend otherwise. A build can be late. An integration can break when a supplier changes a format. Knowledge concentrates in whoever built it, which is a new single point of failure unless the handover is done properly.

Hiring has its own: recruitment takes two to four months, a bad hire costs six months of salary and morale, the knowledge leaves when the person does, and holiday still has to be covered. Neither option is safe. They are differently risky.

How to decide in one afternoon

1. Write down the tasks you would give the new hire, with weekly hours against each.
2. Mark each one M for mechanical or J for judgement.
3. Total the M hours. If they exceed about 40% of the role, automation is genuinely competing.
4. Price the automation for the M block only, not the whole role.
5. Compare that price with three years of salary, and decide whether the J hours alone justify a hire.

Frequently the answer is a smaller automation and a smaller hire, which is exactly the outcome the either/or framing hides.

Frequently asked questions