What business processes should you automate first?

Start with friction, not with software

The starting question is not which tool to buy. It is where work currently stalls, gets redone, or waits on someone remembering. Those points are visible without any technology decision at all.

Sit with the process for a week and count. How many times did a record get typed twice? How many follow-ups happened late because nobody had a list? How often did someone ask another person for a status that a system already knew?

Friction identified this way is measurable, which means the result of automating it will be measurable too.

Good first automation candidates

The strongest first projects tend to be unglamorous. They are the connective tissue between systems that nobody owns because it was never designed — it accumulated.

• Lead routing — assigning an enquiry to the right person by rule instead of by whoever notices first.
• Follow-up reminders — scheduled prompts derived from record state rather than from memory.
• Data synchronisation — one record created once and reflected wherever it is needed.
• Status updates — a change in one system propagating to the places people look.
• Report generation — recurring reports assembled from the source data on a schedule.
• Notifications — targeted alerts when a threshold is crossed, not a daily digest nobody reads.
• Document preparation — quotes, contracts and onboarding packs populated from existing records.
• Repetitive approvals — routine sign-offs queued with the context attached, so the decision takes seconds.
• Content handoffs — moving drafted work through review, publication and distribution states.
• Account provisioning — creating the accounts, permissions and workspaces a new customer or employee needs.

None of those requires a model, and most require no new software. They require a defined trigger, a defined action, and somebody willing to own the exceptions.

The best candidate often crosses two or more systems

A task contained inside one application is usually already supported by that application's own features. The expensive work is between systems, because no vendor is responsible for the gap.

That gap is where the copying, the re-keying and the reconciliation live. It is also where data quietly diverges: the CRM says one thing, the billing system says another, and the spreadsheet is the only place both are true.

If several of those gaps exist at once, the problem may be larger than any single workflow. That is the argument made in from fragmented stack to integrated platform, and it changes the sequence: you close the most-crossed seam first, then the next.

Automate stable processes before unstable ones

A process that changed twice this quarter will change again during the build. Every change becomes rework, and the automation is blamed for the churn it inherited.

Stability does not mean perfection. It means the shape of the process — the trigger, the sequence, the finish — has held steady for long enough that you can describe it without hedging.

Unstable processes are not permanently disqualified. They are simply later, after the shape settles.

Avoid automating broken processes

If a process produces inconsistent outcomes today, automating it does not fix the inconsistency. It makes it consistent in the wrong direction and removes the human intuition that was quietly correcting for it.

Repair usually costs less than people expect: naming an owner, agreeing the states a record can be in, and writing down what happens when something falls outside them.

Risk, reversibility and approval

Two processes can be equally repetitive and carry completely different consequences. Sending an internal reminder and issuing a refund are both rule-based; only one of them moves money out of the business.

Ask three questions about every candidate: what does a wrong run cost, can it be undone, and would anyone notice within a day. A candidate that is cheap, reversible and visible is a good first project even if it is imperfect.

High-consequence work is not excluded — it is designed differently, with a person on the committing step. That pattern is covered in human approval gates in automation.

A practical automation scoring framework

Scoring turns an argument into a ranking. Rate each candidate from 1 to 5 on the criteria below, using the same definitions for every process, and compare totals rather than opinions.

Two entries deserve care. High error cost lowers the score rather than raising it, because expensive mistakes belong behind an approval gate. And a process with no approval requirement scores higher only if that is genuinely true — not because nobody has thought about it yet.

What not to automate first

• Poorly defined processes — where no two people describe the same sequence.
• Rare edge cases — the quarterly exception that takes an afternoon and cannot be generalised.
• High-risk irreversible decisions — anything that cannot be recalled once it has run.
• Workflows with unclear ownership — automation needs someone accountable for its exceptions.
• Processes changing every week — the build will be obsolete before it ships.

Each of these can become a good candidate later. The disqualification is about sequence, not about permanent unsuitability.

Sequence the second and third projects while you build the first

The first automation teaches you where your data is weakest and which system is hardest to work with. Capture that while it is fresh: the second project is usually cheaper because it reuses the identifiers, credentials and monitoring you established in the first.

A sequence also protects the programme politically. Delivering three modest workflows that visibly work earns more room than one ambitious project that is still being explained six months in.

Choosing correctly is the cheapest part of the work and the part most often skipped. We map the current process, score the candidates and agree what stays manual before anything is built as part of automation and business systems engagements.