What business processes should you automate first?

Nearly every business has more automation candidates than budget. The question is not what could be automated — given enough time, almost anything can. The question is which one returns the most hours for the least risk, and which one teaches your team enough to make the second project easier.

The four tests a process has to pass

Before committing to anything, run the candidate through these four checks. A process that passes all four is a strong first project. One that fails two or more is a poor place to start, however tempting it looks.

1. It happens often

Automation converts a fixed build cost into a recurring saving, so frequency is what pays the bill. Twenty minutes saved daily is worth roughly eighty hours a year. A two-hour task that runs quarterly saves eight. Build for the first one.

2. The decisions are rules, not judgment

“If the invoice is under £500 and the supplier is approved, post it” is a rule. “Decide whether this client will be difficult” is judgment. Rules automate cleanly. Judgment needs a person — though the work around the judgment call, gathering context and preparing options, often automates well.

3. The data is already somewhere reachable

If the information lives in an inbox, a spreadsheet, a CRM or an accounting system, it can be read and moved. If it lives in someone’s head, in a filing cabinet, or in a system with no export, that has to be solved first — and that is a different project with a different budget.

4. Being wrong is cheap and visible

Early automations should fail safely. A mis-categorised expense gets corrected at month end. A wrongly issued refund does not. Start where mistakes are recoverable and easy to spot, then move into higher-stakes work once the approach has earned trust.

The five that most often pay off first

Across industries, the same handful of processes keep surfacing as the best opening move.

Invoice and document handling

Someone opens an email, reads a PDF, retypes the numbers into an accounting system, and files the document. It is high volume, rule-heavy, and the data is right there in the document. This is the most common first project we build, and usually the fastest to show a number — see invoice and document automation for how the extraction and approval steps fit together.

Lead response and follow-up

Enquiries arrive and wait. Speed of first reply is one of the strongest predictors of whether a lead converts, and it is almost entirely mechanical: acknowledge, qualify, route, remind. Cheap to build, and the effect shows up in revenue rather than only in hours saved.

Customer support triage

Not answering every ticket automatically — triaging them. Classifying, tagging, routing, drafting a reply for approval, and resolving the genuinely repetitive questions outright. The judgment stays human; the sorting does not. That division of labour is the whole design problem in AI chatbot development.

Recurring reports

If someone rebuilds the same spreadsheet every Monday, that is a script with a person standing in for it. Reporting automations are popular first projects because the output is easy to verify: either the numbers match last week’s manual version or they do not.

Onboarding and handoffs

New client, new employee, new order — each triggers a checklist spanning several systems, and each is where things quietly get dropped. Automating handoffs tends to improve consistency more than it saves time, which is worth having in its own right.

What to leave alone for now

Three categories are worth deliberately skipping on a first project.

• Anything genuinely broken. Automating a broken process makes it fail faster and more consistently. Fix or simplify it first, then automate the version worth keeping.
• Anything about to change. If you are switching CRM next quarter, do not automate around the old one.
• Anything nobody can explain end to end. If no one can describe the current process without saying “it depends”, that ambiguity will surface during the build — better to map it before committing.

How to choose in an afternoon

You do not need a formal audit to make a first decision. Ask the people doing the work to list every task they repeat weekly. For each one, note roughly how long it takes, how often it runs, and whether the steps are rules or judgment. Multiply time by frequency, drop anything judgment-heavy, and drop anything where the data is not already in a system. What survives is a shortlist, usually of three or four.

From there it is a question of sequencing rather than selection — which is what a workflow audit and roadmap is for, and it is the part worth being deliberate about. The first project sets expectations for every one after it.

A realistic first build

A single well-scoped workflow is typically live in two to three weeks: a few days to map the process precisely, a week or so to build and connect it, then testing against real work before it touches anything that matters. Processes crossing several systems, or needing a human approval step designed around them, take longer. If you want a sense of what a full implementation involves, business process automation walks through the stages.

Common questions