AI workflow automation: which processes to automate first

Ask three suppliers to quote for AI workflow automation and you can get three different builds under the same name. The difference decides the cost, the risk and how the thing gets tested, so settle which shape a process would take before you score it.

This guide is about choosing and sequencing the processes. The build itself, with audit logs, dry runs and rollback on every write to your systems, is what our AI integration and automation services cover.

Who builds it is a separate choice. An AI automation agency usually builds on a no-code platform and often runs the result for a monthly fee, while a consultancy starts from the business problem. We set out the difference between an AI agency and an AI consultancy, including what you own when the contract ends, in a separate guide.

Start the long list with the people who do the work, not with a vendor's list of use cases. The UK government's AI Playbook says the choice of use case must be led by business and user needs, pain points and inefficiencies, not by what the technology can do. That holds well outside government.

Then score each candidate from 1 to 3 on the nine criteria below, using measured figures wherever you have them. Risk is scored the other way round from the other two, so that 3 is always the better score: a 3 on risk means a wrong output is cheap, caught early and easy to undo.

Keep the three groups as three totals rather than adding them into one. A process scoring 9 on value and 3 on risk needs a different conversation from one scoring 6 on everything, and a single number hides the difference.

The scores rank candidates against each other. They are not a business case, and before a build is approved the chosen process still needs a measured baseline and a proper estimate of the return.

Some findings end the conversation for now, whatever the scores say. I check for these first, because any one of them can sink a project that looks excellent on paper.

The process with the highest value score is often the wrong first choice. A first build has two jobs: to return something, and to lay the groundwork every later automation reuses, meaning the connections to your systems, the logging, the habit of testing against past cases and the routes to a reviewer. A process that is easy to connect and safe to get wrong does the second job well, even when its value is only middling.

So I would sequence the list in rounds, re-scoring the rest after each one, because the first build changes what is feasible for everything after it.

Anthropic's engineering guidance draws the line clearly. In its terms, workflows are systems where models and tools are orchestrated through predefined code paths, and agents are systems where the model directs its own process and tool use. It recommends finding the simplest solution possible and adding complexity only when needed, and it notes that agents trade latency and cost for better task performance, with the potential for compounding errors.

OpenAI's practical guide to building agents reaches the same place from the other side. It suggests prioritising workflows that have resisted automation: decisions full of judgement and exceptions, rule sets that have become costly to maintain, and heavy reliance on unstructured data such as documents and conversation. If a use case does not clearly meet those criteria, it says, a deterministic solution may suffice.

My own test is simpler. If the people doing the work can draw the flowchart, build the flowchart and put a model in the boxes that need reading or judgement. Reach for an agent when the number and order of steps change from case to case, and a drawn path would need dozens of branches to cover what a person does. In the first year of an automation programme I would expect many more of the first kind than the second.

These three processes, from three different organisations, are invented to show the method. The organisations, volumes and scores are illustrative, and none of them is a client result or a benchmark. Each is scored from 1 to 3 on the nine criteria above, with risk scored so that 3 is safest.

Supplier invoice coding would go in the first round. A mid-sized distributor receives invoices as PDFs by email and codes each one to a ledger account and cost centre. An AI step reads the invoice, a deterministic check matches it to the purchase order within a set tolerance, and anything outside tolerance goes to a person. Years of invoices already coded by hand make the test set, and a miscoded line can be reversed with a journal. Its value is only middling, but for the distributor the build connects to the ledger and sets up the logging and testing its later automations reuse.

Delivery-change requests are a next-round candidate. A retailer's customers ask by email and chat to move a delivery, change the address or cancel, and both the wording and the path vary: check the order, ask the carrier, rebook, perhaps refund a delivery fee. Feasibility falls short of the first-round bar, so this belongs after a first build that has connected the retailer's order system. Before anyone builds an agent, map a few hundred past requests. If nearly all of them follow a handful of paths, build those paths as fixed branches with an AI step that reads the request; if they do not, a narrow agent with three or four tools fits, with any refund above a set amount sent to a person.

Hardship payment plans fail as full automation, and that is the useful finding. A utility's customers in financial difficulty ask for a payment plan. The decision is significant for the person, the rules leave room for judgement and the customer may be vulnerable, so the candidate trips the stop check on decisions about people before any score is added, and the scores agree. Rescoped, it looks different: an AI step assembles the case, summarising the account history and the customer's own statement, and drafts the letter, while a trained member of staff makes the decision. That preparation work is a candidate in its own right and should be scored again as one.

Some automations need a person to check every output before it goes anywhere. For high-risk work that is often right, and the fourth principle of the AI Playbook asks for humans to validate any high-risk decisions influenced by AI. The saving then depends on checking being much faster than doing the work, which is worth measuring before anyone counts it.

The failure I watch for is a review queue that is nearly always right. A reviewer who has approved ninety-nine cases in a row tends to read the hundredth less carefully, and the check turns into a signature. Two measures show whether that is happening: how often reviewers change an output, and how often a sample of approved cases turns out to be wrong.

The better design sends people the cases that need them. Put deterministic checks after the AI step, such as totals that must reconcile, fields that must match a record and limits that must not be exceeded, and send the failures plus a random sample to review. That is the pattern where the model proposes and a deterministic check decides, and it gives the reviewer a real job rather than a rubber stamp.

Public bodies carry one more duty. Central government departments, and the arm's length bodies within its scope, must publish records of the algorithmic tools they use in decision-making under the Algorithmic Transparency Recording Standard, and the AI Playbook encourages other public sector organisations to use it too.

Use one copy per candidate process. Fill in the evidence before the score, so every score rests on something another person can check.

If you have a long list and no agreed order, our AI Opportunity & Feasibility Sprint produces one. It is fixed scope and typically takes two to four weeks: we look at how the work runs today and what state the data and systems are in, score the candidates on value, feasibility and risk, and write the sequenced roadmap, the investment case and the governance conditions.

If the first process is already chosen, what follows is build work: the connections to your systems, the AI step, the checks around it and the logs that show what happened on every case. We take small fixed-scope statements of work as well as larger builds, a signed scope can start within a day, and if you already have a scoped job we can resource it on contract from the collective of associates who work with 1AYM, held to the same standard. Either way, the first step is a 30-minute call.