Choosing your first AI automation: a four-step method

Most organisations have work that people re-key, sort or answer by hand every day. The best first AI project takes some of that work off them, and proves that it did. Pilots usually fail not because the technology does not work, but because the problem was poorly chosen, the measurement was vague and nobody owned the result. This article offers a practical way to pick that first automation and show that it works.

Look for the boring work

The best candidates are tasks that are repetitive, high-volume and currently done by people who would rather be doing something else: classifying incoming documents, extracting fields from forms, drafting routine replies, routing requests to the right team. These tasks have clear inputs and outputs, which makes them measurable.

A four-step method

1. Measure the baseline. How long does the task take today, how often is it wrong, and what does an error cost?
2. Define success before building. For example: handle 70 of every 100 cases automatically with fewer errors than the manual process, and route the rest to a person.
3. Prototype on real data. Use a representative sample, messy cases included, and evaluate honestly against the baseline.
4. Design the human loop. Decide what happens when the system is unsure, how people correct it, and how corrections improve it.

(opens the full-size image in a new tab)

A worked example: supplier invoices

Here is how the method might look for a finance team that types supplier invoices into its accounting system. The numbers are illustrative, not results from a real project.

• Baseline. The team times a normal week. Suppose keying an invoice takes about four minutes, and a spot-check finds a wrong amount or supplier on a few invoices in every hundred, each of which takes time to trace and correct later.
• Success. Before anything is built, the team agrees a target such as: extract the supplier, invoice number, date and total from most invoices with fewer errors than manual keying, and send anything uncertain to a person.
• Prototype. The system runs on last month's invoices, faded scans and unusual layouts included, and every extracted field is compared with what was actually entered. That comparison, not the demo, decides whether to continue.
• Human loop. Fields that fail a check, such as a total that does not match the line items, go to a reviewer, whose corrections are logged and used to improve the rules and prompts. Our guide to document AI covers these checks in more detail.

If the prototype misses the target, the team has spent a few weeks and learned something specific. If it meets it, the same measurements become the case for rolling it out.

What usually goes wrong

• Choosing a problem because it is interesting rather than because it is costly.
• Skipping the test set, so nobody knows whether the system is actually better.
• No owner for the outcome once the project team moves on.
• Underestimating integration: a model that is not connected to the tools people use changes nothing.

Governance that does not slow you down

Send only the data each task needs, to services whose terms you have checked (see keeping your data private when you use AI). Be clear with staff and customers about where automation is used, log decisions for review, and keep a person accountable for the process. These are not obstacles; they are what makes a system trustworthy enough to be used.

Starting small is the fast route

One well-measured automation that saves real hours builds the confidence, data and skills for the next. A large transformation programme without that foundation rarely survives contact with reality. Pick the boring work, measure it, and let the results argue for the next step.

If you would like help choosing and proving a first automation, our AI solutions and automation service works through this method with you.