How we choose the first process to automate

The process everyone nominates first

A year of automation work opens with the same question, where to start, and by the time anyone puts it to us the answer has usually been picked already. It is whichever process the team finds most irritating. Three of the things that landed in January describe what goes wrong after that choice gets made: Deloitte's enterprise survey, UiPath's January release notes for Agents, and a benchmark paper built on a ServiceNow environment.

A process becomes annoying when each instance takes concentration, or when it lands in the same week as month end. Neither of those tells you how well it will automate. What the complaint leaves out is whether there is enough volume to repay a build, whether the rules can be written down, and whether the systems involved expose an interface a program can use.

Deloitte published the 2026 edition of its State of AI in the Enterprise survey on 21 January, based on more than 3,000 executives involved in their organisation's AI work. Two figures held our attention. Only 25 per cent had moved 40 per cent or more of their AI pilots into production, and 37 per cent reported surface level use with minimal change to the underlying business process. We read both as describing AI work that has not yet changed how a process runs day to day. They are self reported numbers and we would not lean on the exact percentages, though the direction of them matches what we see on site.

Before we commit to a build we measure five properties on the candidate: how often the process runs, how much of it is judgement, which systems it touches, what a wrong run costs, and who owns it. The rest of this is what each one tells us.

Volume, and how the runs split

Ask for a volume estimate and you get a number from memory, and it is usually wrong, because the runs people remember are the painful ones. We pull the count from the system holding the record: row counts from the ERP table, ticket counts from the service desk, message counts in the shared mailbox. Frequency also sets how much testing in production is available to you, since a monthly process gives twelve observed runs a year and a year end reconciliation gives one.

Then we look at how those runs distribute across paths, counting how many go start to finish the same way and naming the special cases the rest divert into. Build cost is driven by the number of distinct paths, and the time saved by how many instances run each month. On those two numbers a process with several hundred runs a month and three paths is a better first build than one with forty runs and fifteen paths, and we will say so even when the forty-run process is the one everybody wants gone.

How much of it is judgement

We walk the process and mark each step deterministic or interpretive. Deterministic steps have one correct output for a given input: look up a customer by ABN, calculate GST, post a journal line through the accounting system's API. Interpretive steps need something read and understood: working out which purchase order a supplier's email refers to, classifying an inbound message, pulling line items out of a PDF whose layout changes per supplier.

The ratio of deterministic to interpretive steps determines how the automation can be tested, and testing is where the build effort concentrates. Python with a fixed input produces a fixed output, so deterministic steps can be covered by a test suite built from historical records. Model steps need a labelled set of real examples, a measured accuracy per field, and a confidence threshold below which the run stops and queues for a person. A candidate with a few interpretive steps inside an otherwise deterministic flow needs a smaller labelled set and fewer thresholds than one where most steps are interpretive.

Two January releases show what measuring a model step involves. UiPath's January 2026 release notes for Agents describe an Optimize feature that uses evaluation results to suggest prompt improvements to the agent definition, and a Files tab in agent runs with trace spans available for download. Optimize, the Files tab and the trace spans are evaluation and run inspection features, which is the tooling an interpretive step needs before it runs on a schedule. We would not put an interpretive step on a schedule without something of that shape behind it, whoever ships it. The Register's 13 January report on Anthropic's Claude Cowork research preview lists Anthropic's own caveats for that product, including monitoring for suspicious actions that may indicate prompt injection. If the interpretive steps in your process read inbound content from outside the organisation, that exposure is yours as well, and we put it in the assessment alongside accuracy.

The systems it touches

We list the systems the process reads from and writes to. For each one we find out whether there is a documented REST API covering the operations needed, how it authenticates, whether there is a sandbox, and what the rate limits are.

Where the API exists, the automation is ordinary integration work with tests and error handling. Systems without one leave driving the user interface as the fallback, which carries a maintenance cost proportional to how often the vendor changes the screen. UiPath selectors break when the DOM changes, and Power Automate desktop flows against a Citrix session break when the resolution or theme changes. Choosing a screen-driven process as the first build is a decision to take on that maintenance, and we would rather have that argument before the build than during it.

The other question is what happens inside the target system after a write, and the most interesting paper of the month lands here. World of Workflows, posted to arXiv on 29 January 2026 by a team at Skyfall AI, built a benchmark on a ServiceNow environment carrying more than 4,000 business rules and 55 active workflows, then ran 234 tasks. The authors report dynamics blindness: frontier models failed to anticipate the cascading side effects of their own actions and produced silent constraint violations. That result comes from one environment and how far it generalises is unsettled, so we are not treating it as a general law about models. We do treat it as a reason to check what a write triggers in the specific system being automated, listing the business rules, triggers and workflows that fire on the tables the automation writes to.

What a wrong run costs, and who owns it

We write down what a wrong run does for each candidate. An incorrect value in an internal report gets corrected when someone fixes the value. An automation that emails a customer, releases a payment file to a bank, or lodges something with a regulator needs a defined recall process, and we want that confirmed before the build starts rather than discovered during it. Holding outbound steps for approval covers most of this, and a contained failure mode lets the first build run alongside the manual process while outputs are compared.

Clifford Chance's 30 January briefing on Australia's National AI Plan 2025 describes a whole-of-economy strategy covering national data centre principles alongside emerging frameworks for privacy, cybersecurity and responsible AI. For a first automation the practical step is to work out which existing obligations the process already sits under. Our own rule is blunt: we keep the first build away from health records, credit information and anything carrying a statutory deadline.

The process also needs a named owner who can answer questions on exception rules, sign off the decision table, and accept the output as correct. When the owner is recorded as a team name, the build stalls the first time an exception needs a ruling, because no individual has the standing to give one. We ask for the person's name, and we keep asking until we get one.

How we run the selection in practice

Recording all five properties for five or six candidates is an afternoon of work with the people who run the processes: runs per month from the source system, distinct paths, systems and whether each has an API, what a wrong run costs, and the owner's name.

We write the chosen process out as a step list before the build starts: inputs, outputs, the decision rule at each branch, and what happens to each known exception. A process that cannot be written down in this form usually has rules nobody has agreed yet, and agreeing them is part of the build.

The first build also establishes the shared parts every later automation uses: run logging, where run history is stored, how approvals are queued, how test data is refreshed, and how a failed run is retried. Building those on a high volume process with few paths and a contained failure mode means they are already tested when a harder process reaches the front of the queue. That is why we would rather the first build be a high volume process with few paths than the one generating the most complaints.

Two parts of this we cannot shortcut. There is no reliable way to estimate the interpretive share of a process without walking it step by step, so that part of the assessment stays slow. Whether the World of Workflows result reproduces outside a service desk environment is unestablished, so we keep the check narrow and list the triggers on the tables we write to.