Choosing which process to automate first is a prioritisation problem, not a technical one. The decision rests on understanding what each process currently costs the business in time, errors and delay, and weighing that against how clearly the process can be defined by the people who carry it out.

A process that runs frequently, follows predictable steps and involves moving data between systems or people is usually a stronger candidate than one that happens rarely, relies heavily on individual judgement or has never been written down. The reason is straightforward: automation works best when the rules are known and the inputs are consistent. If a process changes every time someone runs it, the system will either produce wrong results or require constant rework.

Before ranking candidates, establish a baseline for each process. That means recording how often it runs, how long it takes, how many people are involved, what errors occur and what the downstream consequences of those errors are. Without this baseline, there is no honest way to compare one process against another or to measure whether automation delivered a return later.

Automation decisions to resolve before building

Why the first choice matters

The first automated process sets the tone for how the organisation views this kind of work. A quick, visible win builds confidence among staff and stakeholders. A protracted, over-engineered first project does the opposite and can stall further investment for months or years. The goal at this stage is not to solve the business's deepest structural problem. It is to prove the approach works on something that matters enough to care about but is contained enough to complete.

Selection criteria that actually separate candidates

When you have a shortlist of processes, apply these filters in order:

  • Process clarity. Can the people who perform the task write down every step, decision point and exception without ambiguity? If the answer is no, the process needs mapping and stabilising before automation is sensible.
  • Volume and frequency. A process that runs dozens of times per day offers more cumulative saving than one that runs monthly, even if the monthly process takes longer each time.
  • Error rate and cost of failure. Processes where manual mistakes lead to financial loss, compliance breaches or customer complaints carry higher automation value. Quantify what one error costs in rework, refunds or reputational damage.
  • Handoffs between people or systems. Processes that require someone to copy data from one system to another, or to email a file and wait for approval, are strong candidates because the handoff itself is where delays and errors concentrate.
  • Data availability. The system needs reliable inputs. If the data currently lives in spreadsheets that are incomplete or inconsistent, the automation will fail at runtime regardless of how well the logic is built.
  • Exception frequency. If more than a small fraction of runs require manual intervention or judgement, the automation will not deliver the expected time saving and may frustrate users who constantly have to step in.

Typical early-automation candidates in UK business systems

In customer portals and CRM deployments, common first choices include new-customer onboarding workflows where information moves from a web form into the CRM, triggers a verification step and generates a welcome email or document pack. The steps are predictable, the data comes from the user, and the process runs every time a new account is created.

In back-office operations, invoice approval chains are frequently chosen. An invoice arrives, is matched against a purchase order, routed to the correct approver based on department and value, and flagged if amounts do not match. The rules are clear, the volume is usually high and the consequences of delay are tangible.

Document workflows where a contract or compliance form moves between draft, review, approval and signed states also suit early automation, particularly when audit logs are required. The system can record who approved what and when, which is difficult to maintain reliably on paper or in email threads.

Processes that usually should wait

Processes that depend on nuanced commercial judgement, such as pricing bespoke contracts or assessing credit risk for unusual cases, are poor first candidates. The logic is hard to codify, exceptions are common and getting the rules wrong carries direct financial risk. These may become automation targets later, once the organisation has experience and the edge cases are better understood.

Similarly, processes that touch a system with poor or undocumented data structures should be deferred until the data problem is addressed. Automating access to unreliable data simply produces unreliable outputs at speed.

Automating a process that is not understood

The single most common mistake is automating a process before it has been mapped accurately. When different team members describe the steps differently, or when the documented process does not match what happens on the floor, the resulting system will either be wrong from day one or will require extensive rework during testing. Map the process first, resolve the discrepancies, then automate the stable version.

Confusing automation with improvement

Automation makes a process faster and more consistent. It does not fix a process that is fundamentally wasteful or misaligned with business objectives. If a report is generated daily but nobody reads it until the weekly meeting, automating its generation saves a few minutes but does not address the underlying redundancy. Question whether the process should exist at all before deciding how to run it.

Underestimating exception handling

During selection, teams often focus on the happy path and gloss over what happens when something goes wrong: a supplier sends an invoice in the wrong format, a customer's address fails verification, an approver is on leave. The effort of handling exceptions can easily exceed the effort of building the main flow. When evaluating a candidate process, ask what proportion of runs deviate from the standard path and what those deviations look like.

Ignoring the change-management burden

Staff who have performed a task manually for years may resist a system that changes their routine, removes perceived control or raises concerns about job security. If the first automated process is introduced without explanation, training and a clear channel for feedback, adoption will be slow and the project will be judged a failure regardless of its technical quality. Factor in the time needed to bring users along.

Checks before automating the process

  • Can you state the current time and error cost of the process in concrete terms, not vague impressions?
  • Has the process been mapped by the people who actually perform it, not just by managers?
  • Are the data inputs available in a structured, reliable form?
  • Is the process stable, or is it likely to change significantly in the next six months?
  • Can you define what success looks like numerically before the build starts?
  • Have you identified who will own the process once it is automated, including responsibility for handling exceptions and updating the rules?

Answering these questions honestly will not guarantee a flawless first project, but it will filter out the candidates most likely to become expensive distractions. The processes that remain are the ones where the business need is clear, the logic is knowable and the risk of failure is contained. That is the right starting point.