How To Choose The First Workflow To Automate With AI

The first workflow you automate with AI will determine whether your organisation does a second one.

Choose wrong — something too broad, too political, or too dependent on a system nobody understands — and the project drags, the sceptics win the argument, and AI quietly becomes a thing your company tried once.

Choose right and you get a result in weeks, a team that trusts the tooling, and the political capital to do something more ambitious.

Here is a practical way to pick.

Score candidates on five axes

List every repetitive process your team does. Then score each one from 1 to 5 on these five dimensions.

1. Volume and frequency. How often does this happen? A process that runs 50 times a day will prove value fast. A quarterly report, however painful, gives you almost no feedback loop.

2. Rule structure. How much of the decision is mechanical? “Extract these six fields from this invoice” is highly structured. “Decide whether this customer is worth keeping” is not. Start where the rules are visible.

3. Data accessibility. Can the agent actually get the inputs? If the data lives in a system with no API and no export, you will spend the whole project on plumbing. That may be necessary work — but it is not a good first AI project.

4. Tolerance for error. What happens when the output is wrong? A mis-sorted internal ticket is recoverable. A wrong payment is not. Start where mistakes are cheap, and only move to high-stakes work once you have real reliability evidence.

5. Human pain. Does anyone actually care? Automating something nobody minds doing generates no goodwill and no budget. Automating the task that makes a good employee want to quit generates both.

The scoring trick that matters

Add the five scores up, then weight tolerance for error twice. It is the axis teams most often underrate, and the one that turns a promising pilot into an incident.

A workflow that scores 5,5,4,1,5 is not a 20. It is a workflow with a fatal flaw. Do it later, when you have monitoring and a track record.

The ideal first candidate looks boring: high volume, mechanical rules, accessible data, cheap mistakes, and visibly annoying to the people doing it. Invoice field extraction. Ticket triage. Answering the same twelve questions from a support inbox. Data entry between two systems that should already talk to each other.

Boring is the point. You are not trying to impress anyone — you are trying to build the evidence base and the operational habits that make the ambitious project possible.

Do not start with the process you most want to fix

This is the most common mistake, and it is an emotional one. The process that frustrates leadership most is usually the most complex, the most cross-functional, and the most politically loaded. It is exactly the wrong first project, because failure there is public and permanent.

Start adjacent to it. Automate one clear sub-step. Ship it. Then use that credibility to attack the larger problem with better information.

Define “done” before you start

For the workflow you pick, write down three numbers in advance:

• Volume handled — how many items per week will the agent process?
• Human touch rate — what fraction will still need a person, and is that acceptable?
• Cost per item — what does one processed item cost in model and infrastructure spend?

If you cannot state these before you begin, you will not be able to tell whether the project succeeded. And “we think it’s working” is not a result you can take to a budget holder.

The minimum viable automation

Ship the narrowest version that removes real work. Not the version that handles every edge case — the version that handles the common case reliably and escalates the rest to a human cleanly.

Then watch it for a month. The escalation log is your roadmap: every item a human had to handle is a candidate for the next iteration, in priority order, with real evidence of how often it occurs.

That is how automation compounds. Not one grand project, but a series of small, boring, verifiable wins — each one funded by the credibility of the last.

A note on tooling

The tooling decision is genuinely less important than the workflow decision, and teams often invert this. Buying a platform will not save a badly chosen first project. A well-chosen first project will succeed with modest tooling and give you the information you need to choose better tooling later.

Pick the workflow first. The technology is the easy part.