How to choose the first process worth automating
Most automation projects fail because the wrong process was picked, not because the technology was wrong. Here is the filter we use before quoting anything.
Almost every automation project that goes badly went wrong before a single line of code was written. The team picked a process that looked painful rather than one that was actually a good candidate, and everything downstream inherited that mistake.
We run every prospective project through the same four questions. If a process fails two of them, we say so and suggest a different starting point — it is a much cheaper conversation than the one six weeks later.
1. Does it happen often enough to matter?
Frequency beats duration. A five-minute task done ninety times a week is a far better target than a two-day task done twice a year. The two-day task feels more painful when you are doing it, which is exactly why teams nominate it — but the annual saving is smaller and the edge cases are worse, because nobody remembers how it works.
A rough floor: if the task does not consume at least five hours a week across the team, the payback period usually stretches past the point where anyone still cares.
2. Are the rules written down, or in someone's head?
This is the question that kills the most candidates. If the process depends on a person knowing that this particular client always wants the invoice split, and that supplier's dates are in American format, then you do not have a process — you have an expert. Automating around an undocumented expert produces a system that is confidently wrong.
The fix is not to abandon the idea. It is to spend the first week writing the rules down. That document has value whether or not you automate anything, which is why we hand it over regardless.
3. What does being wrong cost?
Sort your candidates by blast radius. Drafting a reply that a human approves before it sends is low risk. Issuing a refund is not. Start where a mistake is embarrassing rather than expensive, prove the thing works, and move up.
4. Is the data already somewhere a machine can reach?
If the input arrives as a PDF attached to an email, that is workable. If it arrives as a photo of a screen sent over WhatsApp, you are signing up for an OCR project you did not plan. Check where the data actually lives before you scope the automation, not after.
The shape of a good first project
Put those four together and a good first candidate looks like this: it happens many times a week, the rules can be written down in an afternoon, a mistake is recoverable, and the data arrives in a structured or semi-structured form.
- Inbound enquiry triage — high volume, clear rules, a human still sends the reply
- Invoice and receipt extraction into your accounting system, with a review queue
- Weekly reporting that someone currently assembles by hand from three dashboards
- First-line support answers drawn from documentation you already maintain
The best first automation is boring, frequent and reversible. Save the ambitious one for when the team trusts the system.
The point of project one is not the saving. It is to prove to the people who have to live with the system that it behaves predictably. Get that right and the second project is a much easier conversation.