Automate it, or hire for it

The four tests

Run the work through these in order. The first clear answer wins — you do not need all four to agree.

Test	Automate	Hire
Is it written down?	Yes, and it rarely changes	No, or it changes weekly
What does a mistake cost?	An internal re-run	A customer, a permit, a deal
How often?	Daily or hourly	A few times a month
Does it need judgement?	Rules cover the cases	Exceptions are the job

The fourth is the one people over-estimate in both directions. “It needs judgement” is often a way of saying the rules were never written. “It’s just data entry” is often a way of saying nobody has noticed the five exceptions handled by one person’s memory.

The cost comparison that is usually wrong

An automation looks free after it is built. It is not. Over two years it carries monitoring, the upstream change that breaks it, the person who understands it leaving, and the quiet failure nobody notices for a month. A fair comparison prices build plus two years of maintenance against fully loaded salary for two years — and a nearshore hire changes that arithmetic enough to flip some decisions that looked obvious. The salary side is worked out in what a U.S. hire really costs.

The honest third answer

Most real cases are both, in an order. A person owns the work, writes down what they do, and automates their own worst hour. That sequence beats either extreme: an automation built by someone who has never done the job encodes assumptions nobody checks, and a hire who never automates anything scales linearly with your volume.

It is also why the two roles we place most often into this gap — an operations assistant and an AI operations specialist — are usually hired in that order, not the reverse.

Where automation reliably loses

Anything that ends in a phone call with an unhappy person. Anything requiring a licence or a stamp. Anything where the input is a human being changing their mind. Chasing a supplier whose answer quietly moved from “on schedule” to “we’ll confirm next week” is a judgement job wearing an admin job’s clothes.

Where hiring reliably loses

Copying data between two systems that have APIs. Assembling the same document from the same fields. Watching for a condition that a rule can watch for. If you are paying a person to be a slow integration, you are paying for turnover as well — nobody stays in that job.

How to run the count, in two weeks, without a project

Every argument on this page collapses once you have numbers, and the numbers are cheap. For ten working days, the two or three people closest to the work keep a single line per task: what it was, how long it took, and whether anything went wrong. No tooling, no time-tracking software, no approval. A shared sheet is enough.

At the end you sort by total hours and read the top eight rows. Three things are usually true and all three are useful. The most expensive task is rarely the one anyone complained about — complaints track irritation, not hours. Two of the top eight turn out to be the same task described differently by two people, which is a process problem an automation would have cemented in place. And at least one row is something nobody should be doing at all, which is the cheapest saving available to you: it costs a decision, not a build.

Only then does the automate-or-hire question have an answer, because now each row carries hours per month and a cost of being wrong. Run the four tests above against the top eight rows rather than against the whole job, and the decision usually stops being one decision and becomes three small ones.

What actually breaks an automation in year two

Almost nothing fails for an interesting reason. In practice it is one of four:

Cause	How it shows up	What prevents it
Upstream change	A vendor renames a field, adds a required column, or deprecates an endpoint	Alerting on zero-result runs, not just on errors
Silent failure	It runs, returns nothing, and reports success for a month	An expected-volume check: warn when output drops instead of stopping
Owner gone	One person understood it and has left	Documentation written for the next person, plus a manual fallback
Scope drift	Exceptions get bolted on until nobody can predict its behaviour	A rule that a fifth exception means the process goes back to a person

Notice that three of the four are operational rather than technical. That is the argument for owning the automation portfolio with a person rather than a project, and it is the whole reason we describe this engagement around maintenance instead of around launches.

A short list of things worth automating first

If the count above is more process than you want right now, these are safe places to start because a mistake costs an internal re-run and the hours are real: assembling the same document from the same fields; copying records between two systems that both have APIs; chasing a status nobody has updated; turning a form submission into a routed task with the context attached; and producing the weekly report someone currently rebuilds by hand. None of these are exciting. That is the point — the exciting projects tend to rank badly once hours are attached.

Common questions