Which business process should you automate first?

Most automation projects start with the wrong question. Someone asks where the business could use AI, a workshop produces twenty ideas, and the list dies because nothing on it has an owner, a baseline, or a way to tell whether it worked. The question is too broad to answer and too vague to disprove.

A better question is narrower and slightly boring: which repeated decision costs you the most attention? Attention, not headcount. The processes worth automating first are the ones where a person reads something, applies a rule they could explain in a sentence, and moves the result somewhere else. Those are cheap to describe, cheap to check, and they give back the hours that were disappearing into nothing in particular.

Four tests a process has to pass

Before you score anything, filter. A candidate that fails any of these four is not a first project. It may still be a second or a third one, once the first has paid for the plumbing.

1. It repeats at a known frequency — daily, weekly, or every time a specific event happens.

2. Its inputs already exist in a system you can read from, not only in an inbox or in someone's head.

3. A wrong answer is cheap to catch, because a person sees the output before anything irreversible happens.

4. Someone can name the outcome in one sentence, without a diagram.

Frequency is what turns a small saving into a real one. Ten minutes saved on something that happens twice a year is not worth a fortnight of engineering; ten minutes on something that happens forty times a day is a different business entirely. Frequency also hands you evaluation data for free — by the end of the first month you have hundreds of real examples to check the system against, rather than three.

Inputs that already live in a system are the difference between a two-week build and a six-month one. If the invoices arrive as email attachments, they are readable. If the rule that decides which supplier is approved lives only in one person's memory, you are not automating a process, you are writing one down for the first time. That is worthwhile work, but it is different work, and it should be scheduled as such.

Reversibility decides how much you have to trust the system on day one. A drafted reply that a person approves before it sends is a good first project. A payment released without review is not, however confident the model sounds. Start where a mistake costs a correction rather than a refund and you can ship months earlier, because you are no longer waiting for a level of certainty nobody can give you.

The one-sentence test is the one people skip. If two managers describe the outcome differently, the disagreement is not a detail to resolve during the build; it is the reason the build will fail. Write the sentence down and get it agreed before anyone writes code.

Score the candidates

Once you have three or four survivors, rank them with arithmetic you can finish in an afternoon. For each candidate, multiply how often it happens in a month by the minutes it takes each time, weight the result by what a mistake costs, and divide by how hard the integration looks.

Volume per month, times minutes per run, times an error weight, divided by an integration effort. Error weight might be 1 for "someone fixes it later", 2 for "a customer notices", 3 for "money or compliance". Integration effort might be 1 for a system with an interface you already use, 3 for one with a database you can read, 5 for a screen you have to drive or a vendor you have to ask. Those bands are illustrative, not a benchmark. Pick your own, keep them to a single line each, and use the score only to rank candidates against each other — never as an estimate of hours or savings.

The point of scoring is not accuracy. It is that the ranking is written down and everyone can see which assumption they disagree with. When somebody argues for their favourite project, they now have to argue with a number, and usually with the integration effort — which is exactly the conversation worth having before the work starts rather than after.

Three shapes this takes in practice

First projects tend to take one of three shapes. None of them is exotic, and each one is defined by its pattern rather than by any single company that has run it.

Document extraction in finance operations

Invoices, receipts and statements arrive as files and photographs, and somebody retypes the numbers into an accounting system. The pattern reads the document, produces structured fields with a confidence score on each, and routes anything below the threshold to a person. It passes all four tests: it repeats constantly, the inputs are files you already receive, the output is checked before it posts, and the outcome sentence is short — every invoice reaches the ledger without retyping.

Guest and customer messaging in property and hospitality

The same twenty questions arrive through five channels, often at hours when nobody is at a desk. The pattern drafts replies from a known set of facts — the check-in time, the parking rule, the cancellation policy — and hands anything outside that set to a person with the context attached. What makes it a good first project is the failure mode: a slow reply rather than a wrong commitment.

Support answers drawn from your own content

Your help center, your past tickets and your product notes already hold most of the answers; they are simply not findable at the speed a customer expects. The pattern retrieves the relevant passages and drafts an answer that cites them, so an agent can open the source in one click and check it. It is a good first project precisely because the content is the hard part and you already own it.

What to do in the first two weeks

Two weeks is enough to find out whether your first candidate is real. Spend them like this.

1. Write the outcome sentence and get the person who owns the process to agree to it in writing.

2. Collect a hundred real examples with their correct answers, including the awkward ones people leave out of a sample.

3. Measure the baseline — how long the process takes today and how often it is wrong — before anything changes.

4. Build the smallest version that handles the common case and hands everything else to a person.

5. Run it beside the team for a week without switching anything off, and compare its output to theirs.

At the end of the fortnight you either have a system that agrees with your team most of the time and a short list of where it does not, or you have learned that the process was less defined than anyone believed. Both are useful. Only one of them is a project.

The mistake to avoid

The expensive mistake is automating a process nobody agrees on. It looks like a technical failure later — the model is wrong, the integration is flaky, nobody will adopt it — but it began as a definition problem. Two teams held two versions of the rule, the build encoded one of them, and the other team's exceptions arrived as bug reports.

The fix is unglamorous and takes a day. Put the people who touch the process in one room, walk through ten real cases, and write down what the answer should have been in each. Where they disagree, that disagreement is the specification, not an edge case. Fix the definition first and the build gets shorter.

So pick one process. Make it the one that repeats most often and matters least when it is wrong, and prove the whole loop end to end: read, decide, check, write back. The second project is far easier than the first, because by then the plumbing exists and, more importantly, so does the habit of measuring whether any of it worked.