How to choose yourStart a projectfirst AI automation

The first automation you ship matters more than the next five, because it decides whether anyone lets you ship the next five. Pick a process that is too small and nobody notices. Pick one that is too political and you spend three months in meetings. Here is the method we use with clients on day one.

Score every candidate on four axes

Write down every repetitive process someone in the company complains about. Then score each one from 1 to 5:

• Volume. How many times per week does this happen? A task done twice a month is not a first project, no matter how annoying it is.
• Rule clarity. Could an experienced person write down how the decision is made in a page? If the answer is "it depends on feel", you will spend the project discovering the rules rather than automating them.
• Cost of being wrong. What happens if the system gets one case wrong? A mis-tagged support ticket is cheap. A mis-filed tax document is not.
• Data availability. Does the input already exist in a system you can read from, or does someone have to photograph it first?

Multiply volume by rule clarity, divide by cost of being wrong. The top of that list is your candidate.

The trap: automating the wrong half

Most processes have a boring half and an interesting half. The interesting half — the judgement call — is the part people describe when you ask them about their job. The boring half is where the hours are.

A claims handler will tell you the hard part is deciding edge cases. Watch them for a day and you will see forty minutes of judgement surrounded by five hours of opening PDFs, copying reference numbers and updating three systems with the same outcome. Automate the five hours. Leave the forty minutes alone until the five hours are done.

Define success before you build

Pick a number and write it down where other people can see it: this automation must save the claims team six hours a week by the end of month two. Without that, the project is evaluated on vibes, and vibes at month three favour whoever is loudest.

Instrument it from the first day in production. You want three counters: cases handled automatically, cases escalated to a human, and cases handled automatically but wrongly. The third is the only one that matters for trust, and the only one teams routinely forget to measure.

Ship narrow, then widen

Run the automation against one team, one document type or one region first. Narrow scope means the failure modes are small and legible, and the people affected are close enough to tell you what broke. Widening a working automation is cheap. Rescuing a broad one that nobody trusts is not.

The goal of the first project is not the hours it saves. It is the permission it earns you for the second one.