Which Business Processes Should You Automate First?

Before scoring anything, write down every process that currently causes a bottleneck — the ones where work visibly piles up waiting for one person, or where the same manual step happens dozens of times a week. Consider a garment trading company with three sales channels — a trade counter, distributors and a small e-commerce arm — trying to decide where to start; its candidate list looks like most SMBs': sales-order entry, payment reminders, stock reconciliation, and expense approvals, each with its own case for going first.

Talk to the people who actually do the work, not just their managers — the person entering orders knows exactly which step eats their morning, and that detail rarely survives being summarised upward. A candidate list built from actual complaints is more useful than one built from what looks impressive on a slide.

Four questions separate a good automation candidate from a tempting but risky one. How often does it happen (volume)? Does it follow the same steps almost every time, or does every instance look different (repetition)? Has the process itself been stable for the last several months, or is it being redesigned as the business grows (stability)? And what happens if an edge case is handled wrong while the automation is new (risk)?

A process that scores high on volume and repetition but is still being reshaped monthly is not ready — you'd be automating a moving target. A process that's stable and repetitive but touches almost nothing when it goes wrong, like formatting an internal report, is a safe place to build confidence even if the time saved is modest.

A process can score well on paper and still be a poor first choice if the data behind it is unreliable, or the systems involved don't talk to each other. If your customer records exist in three different spreadsheets with different spellings of the same company name, automating the follow-up emails built on that data will just send confused messages faster and more often.

Check two things specifically: whether the systems involved have any way to exchange data automatically (an API, an export file, a shared database) rather than only a screen a person reads, and whether someone can vouch that the underlying records are accurate enough to act on without a manual check first. If either answer is no, that's the actual first project — cleaning the data or connecting the systems — not the automation itself.

Resist automating the biggest process on the list first. A smaller, well-bounded pilot — one branch, one product line, one team — proves the approach works and surfaces the exceptions you didn't think of, at a scale where a mistake is cheap to catch and fix.

Give the pilot one named owner who is responsible for watching it during the first few weeks, checking its output, and deciding when it's trustworthy enough to expand. Without a named owner, a pilot tends to run unmonitored until something goes wrong, at which point nobody notices until a customer or an auditor does.

Before the pilot starts, record how the manual process actually performed — how long a batch typically took, how many errors were caught in a normal week, roughly how much staff time it consumed. Without that baseline, it's impossible to say afterward whether the automation genuinely helped or just felt faster because it's new.

After a few weeks of stable running, compare the same measures. If the pilot process is faster, more accurate, or freed up time without introducing new problems, it's ready to expand to the next candidate on your scored list — using the same criteria, not enthusiasm from the first success.