Most businesses that try automation do not fail because the technology is weak. They fail because the first project was the wrong one: too vague, too sprawling, or dependent on data nobody could reach. A bad first pick leaves a team sceptical of automation for years.
This business process automation guide gives you a simple way to decide which process to automate first. You will score each candidate on four factors, compare the results and choose a pilot that is small, measurable and likely to work.
Step 1: List candidate processes, not departments
Start by writing down real, repeatable tasks. “Finance” is not a process. “Matching supplier invoices to purchase orders” is. A good candidate has a clear trigger, a clear end point and someone who owns it today.
Ask your team three questions:
- What do you do again and again that feels like copying, checking or chasing?
- Where do tasks wait for a person to forward them?
- What work gets delayed when someone is on leave?
Aim for 8 to 15 candidates. Typical examples in workflow automation for small business include lead capture and follow-up, invoice entry, order confirmation, appointment reminders, stock alerts, payment reminders, onboarding paperwork and weekly report compilation.
Step 2: Score each process on four factors
Give each candidate a score from 1 (poor) to 5 (excellent) on the factors below. Keep the scoring quick. You are ranking options, not producing an audit.
Volume and frequency
How often does the task happen, and how much time does it take each time? Automation pays back through repetition. A task done 200 times a month at five minutes each is a stronger candidate than a complex task done twice a quarter.
- 1: a few times a month or less
- 3: daily, a handful of instances
- 5: many times a day, or a sizeable block of someone’s week
Use your own estimates from a short time check. Ask the person doing the work to note instances and minutes for one or two weeks. Do not rely on guesses from people who do not do the task.
Rule clarity
Can you explain the process as “if this, then that”? Rule-based work is easiest to automate reliably. If the answer depends on gut feel or on a senior person’s judgement, it is harder.
- 1: outcome depends on unwritten judgement
- 3: mostly rules, with occasional exceptions that a person resolves
- 5: steps and decisions can be written on one page
Note that modern AI can handle some messy inputs, such as reading free-text emails or extracting fields from varied documents. Even so, you still need a clear definition of what a correct result looks like. A useful design is to let automation handle the clear cases and route unclear ones to a person.
Error cost
What happens if the automation gets it wrong? This factor works in reverse for a first project: lower error cost scores higher. A wrongly worded internal reminder is a nuisance. A wrong payment to a supplier or a wrong tax filing is expensive.
- 1: mistakes are costly, legal or hard to reverse
- 3: mistakes are costly but caught by a review step
- 5: mistakes are cheap, visible and easy to fix
This does not mean high-stakes processes should never be automated. It means they are poor first projects, because you have not yet built trust in your setup or your testing habits.
Data access
Can the automation actually reach the information it needs, and can it put results where they belong? Check whether the data sits in a system with an API or export, in a shared spreadsheet, in email attachments, or only on paper and in people’s heads.
- 1: data is on paper, scattered or locked in a tool with no integration option
- 3: data is digital but inconsistent, or needs cleaning first
- 5: data is structured, in tools that connect, and the same format every time
Data access is the most common hidden blocker. A process can look perfect on paper and then stall because the key records live in a system nobody can connect to.
Step 3: Total the scores and apply a sanity filter
Add the four scores for each process. The maximum is 20. Sort the list from highest to lowest. As a rough guide, processes scoring 15 or above are strong pilots, 10 to 14 are worth revisiting after some preparation, and below 10 should wait.
Then apply a few checks before you commit:
- Owner: is there one person who understands the process and can approve changes?
- Stability: is the process likely to stay the same for the next six months? Do not automate something you are about to redesign.
- Visibility: will a result be noticed by the team or customers? An early visible win builds support.
- Size: can a first version be live in weeks, not quarters? If not, cut the scope to one step or one case type.
If two processes tie, choose the one with the lower error cost and better data access. Those two factors cause the most trouble later.
Step 4: Define success before you build
A pilot is only useful if you can tell whether it worked. Before any build starts, record a baseline for the current process:
- Average time per instance and total hours per week
- Error or rework rate, as best you can measure it
- Turnaround time from trigger to completion
Then set one or two targets, such as “cut handling time per instance by a stated amount” or “respond to every new enquiry within a set time”. Review after a few weeks of live use against your own baseline. Avoid quoting savings figures you have not measured.
Also decide the exception path: what happens when the automation is unsure? A named person and a simple queue are enough.
A quick operations automation checklist
Before you approve your first project, confirm each item:
- The process has a clear trigger and end point.
- It runs often enough to matter.
- Rules can be written on one page, with exceptions listed.
- A mistake is cheap to fix, or a human reviews the output.
- The needed data is digital, accessible and reasonably consistent.
- One owner is accountable and available for testing.
- A baseline is recorded and a success measure is agreed.
- The scope fits a first version delivered in weeks.
- There is a fallback if the automation fails.
If most boxes are ticked, you have a sound candidate. If several are not, fix those gaps first, such as tidying a spreadsheet or writing down the rules. That preparation is itself progress.
Conclusion
Good automation prioritisation is less about ambition and more about fit. Score your candidates on volume, rule clarity, error cost and data access, pick a small process with an owner and a baseline, and prove the value before you widen the scope. Each success makes the next project easier to justify.
If you would like a second opinion on your shortlist, Ecloud Software can help you score candidates and design a practical first project. Book a call and bring your list of processes.
