Automating real work

How to choose the first thing worth automating

Most first automations fail on selection, not engineering. Four tests that separate a task that will survive contact with real use from one that quietly gets abandoned.

2026-06-30 · 4 min read

Most first automations do not fail because the code was wrong. They fail because the task was a bad candidate, and no amount of engineering rescues a bad candidate.

Four tests, applied before you write anything, in the order that kills the most candidates soonest.

1. Can you count it now?

If you cannot say how many times this happens a week and how long it takes, you will not be able to say afterwards whether you helped. That is not just an evaluation problem — it is a survival problem, because the automation that nobody can prove saved anything is the automation that gets switched off when it breaks.

Countable: "Forty invoices a week, about three minutes each." Not countable: "We spend ages on admin."

If the number does not exist, spend a week getting it before you build. That week is not a delay; it is the only baseline you will ever be able to take, and once the automation exists the pre-automation number is gone forever.

2. Does one person own it?

Find the person who does this task today. Not the manager who described it — the person whose Tuesday it actually is.

If nobody owns it, nobody will report that it broke, and nobody will adopt it. If three people own it in three different ways, you are not automating a task, you are negotiating a standard, and that is a much bigger job wearing a smaller job's clothes.

One owner also gives you the only usage metric that matters: are they still using it in a month.

3. What does being wrong cost?

Sort the candidate into one of three buckets, honestly:

• Wrong is cheap and visible. A draft reply that someone reads before sending. A summary in a daily digest. Errors get caught by the human already in the loop, at no cost. Start here.
• Wrong is cheap but invisible. A tagging job whose output nobody inspects. Errors accumulate silently and you discover them at scale. Only take this on with probes running against the output — see evaluating AI output.
• Wrong is expensive. It sends money, deletes records, or emails a customer directly. Not a first automation. Not because it cannot be done, but because the first one is where you learn what you did not know, and you should not learn it there.

The strong first candidate is nearly always "wrong is cheap and visible", and it is nearly always something that produces a draft for a human rather than a final action.

4. Is the input actually structured?

Ask to see the last twenty real inputs. Not a description of the inputs. The actual twenty.

This is the test that saves the most weeks, and the one people skip most often, because the answer is uncomfortable: the inputs are worse than described. There is a photo of a receipt taken at an angle. There are two invoices in one PDF. One is a forwarded email chain with the actual content seven replies down. One is in Welsh.

You are not looking for a reason to abandon the project. You are looking at the twenty documents your system will actually receive, so that the thing you build handles those instead of the tidy example the client sent first. A pipeline built for the tidy example fails in week one and is never trusted again.

The shape of a good candidate

Put the four together and a good first automation looks like this:

Task: categorise and draft a reply to inbound support email. Volume: ~60/week, ~4 minutes each = 4 hours/week. Owner: Priya, who does it every morning. Cost of wrong: Priya reads every draft before sending. Zero. Inputs: 20 real emails collected; 3 are forwarded chains, 1 is an attachment-only complaint.

Everything on that card is a fact somebody could check. Notice how much of it is not technical — which is the point. The engineering was never the risky part.

Then measure the after, the same way you measured the before

Four weeks in, take the same measurement: how many, how long. Two things happen when you do.

The first is that you find out whether it worked. Often the answer is "half" — it handles 40 of the 60 and the other 20 still get done by hand, which is a 2.7 hour weekly saving rather than 4, and worth knowing precisely because the next improvement should target the 20 rather than the 40.

The second is that you now have an artefact — a before number, an after number, a named owner who will say it helped — and that artefact is what gets you the second project. It is worth more than the code, which is why Ship one automation ends with the evidence rather than with the deployment.