Which processes
to automate first?

Measure first, do not guess

The most annoying process is rarely the one that takes the most time. Annoyance is memorable; something done twenty times a day for two minutes is not remembered at all.

For two weeks, have everyone note the repeating tasks: what, how often, and roughly how long. A rough estimate is enough — you do not need accuracy, you need an order. Such a list often shows that the most time is not being spent where you expected.

Then multiply. Fifteen minutes a day is about sixty hours a year per person. Ten minutes a week is about nine hours. Those two look similar until you do the arithmetic, and they differ sevenfold.

Four criteria for ranking

1. How many hours a year it costs. Frequency times duration. This is the only criterion that produces a number, which is why it comes first.
2. How stable the process is. A step that changes every month is a poor first candidate — you will automate it and immediately rework it. Start with what has looked the same for years.
3. How orderly the data is. If the same customer is named three ways in three systems, automation will not fix that, it will multiply it. Tidying the data is sometimes the whole first project, and that is fine.
4. What a mistake costs. A mis-keyed price on a quote and a mis-keyed internal note are not the same risk. Where a mistake is expensive, automation pays off at a lower hour count.

Rank by the first criterion, then remove anything that fails on the second or third. What is left at the top is your first project.

What makes a good first candidate

• Re-keying between two systems that both have an export. If a figure leaves one and enters the other by hand, and both have an interface or at least a file export, that is the most direct gain.
• Repeating emails with the same text and changing details. Confirmations, due-date reminders, status notifications.
• Reports assembled by hand every week or month from the same sources. You recognise them because the same person always does them and always puts them off.
• Data collection that arrives by email and is then re-keyed. A form that writes straight into the system removes both the re-keying and the mistakes made while re-keying.
• Deadlines somebody keeps in their head. A reminder that fires by itself is cheap and removes a quiet risk.

What to leave for later

Processes with many exceptions, ones where somebody has to exercise judgement, and anything where the answer to "by what rule is this done" is "it depends". Those can be automated, but only after the rule is written down and shown to hold. If no rule exists, the first job is agreeing one, and that is not a technical task.

What the first project looks like

Pick one process. Write it down step by step, including what is done when something is wrong. Agree what "finished" means and how you will know it is working correctly. Then the existing tools are connected, and for the steps off-the-shelf software does not cover, a custom solution is built.

After it goes live, run both ways in parallel for a while and compare the results. When they match, the old one is switched off. That parallel period feels like wasted time and is the only reliable way to avoid a silent error.

A realistic expectation

The first project rarely delivers the largest saving. It delivers something more useful: it shows where your data is untidy, who really does which step, and how long agreeing a rule takes. The second project therefore goes noticeably faster.

And plan for adjustment. The process will change — that is not a sign something was built wrong, but that the business is alive. A solution that cannot be adjusted is worse than one that is slightly simpler but can be.