Choosing your first task to automate

Which task recurs so often that your team feels the cost? That is a more useful starting point than asking what AI could do. Choose one task with a clear beginning, an end and someone who does the work today.

We look at how often that task comes up, how long it takes and who does it. That tells us what a first version should do. A list of forty opportunities does not answer those questions.

The first two signals are volume and repetition. Something that comes round daily or weekly rather than quarterly, and that takes the same steps in the same order every time: something arrives, somebody looks something up, copies it across and books it. The gain from an automation is the gain per run multiplied by the number of runs, and that second number does most of the work.

Then comes the question of whether the rules can be said out loud. Not somebody having a quick look, but: if the invoice number matches and the amount falls inside the margin, book it. Exceptions are fine, as long as you can name when you are in one. If you can explain it to a new colleague without sitting down beside them, you can put it into code as well.

It also helps if somebody can name the hours. If nobody in the company can say how long this work takes, that is information in itself: usually the work is spread across a lot of people, and then counting is the first step and building the second.

And there has to be somebody who wants it. A process without an owner produces no answers the moment a question comes up during the build, and those questions come. The best first case is one where the person doing the work today sits next to you now and again.

Count how often the task occurs each week and how many minutes someone spends on it. Twenty times a week, twelve minutes each time, is four hours. That is the most you could save, and some checking will always remain.

Then pick a number you can verify afterwards. Hours can be counted. More grip and less noise cannot, and a project sold on those ends in an argument nobody can win. Name that number in the free call, and you know what you will be looking at two weeks later.

A task spanning five departments and three disconnected systems is usually too large to start with. It may offer substantial time savings. But months can pass before anyone can use the software, while the assumptions change along the way.

Harder to spot is the process whose rules live in one person's head and differ per client. That can be built, but then the project starts with writing those rules down, and that is a different project with a different lead time. Say so up front and it is a choice rather than a disappointment.

And then there is the category with no process at all: an AI strategy, an innovation track, a pilot without an owner. What goes wrong there is almost never the model, but a question that was never made small enough. Of the AI pilots at large companies, 95 out of 100 return nothing, and companies that hand the build to a specialist succeed twice as often as companies that try it themselves (MIT NANDA, The GenAI Divide, 2025).

We agree which task to automate and give a price up front. Within two weeks, a working first version uses your real data in a separate environment where you can check its results.

The first version runs alongside the existing work. You compare its results with those of the employees doing the task today. It goes live only when the results match. You then choose the next task. That is usually faster to build because the connections are already there.

Two weeks is achievable with a clearly defined task: an agreed starting point, a few steps and an outcome someone can check.

The exception is part of that. If the system sees something that does not match what it expects, the case goes to a person with the reason attached. That is the design and not a shortcoming: a system that handles everything also handles the cases it does not understand.

Beyond that, the final check and anything that goes out or moves money stay with a person. And then there are the pieces of work where we establish together in the conversation that automating them costs more than it returns. We say that in the conversation, not at the handover.