The first automation decides whether there is a second one. Pick something frequent, rule-shaped and low-stakes and the business sees the benefit inside a fortnight. Pick the hardest, most political process in the company and the word "automation" acquires a reputation internally that takes a year to shift.
Three questions, in this order
- 1.How often does it happen? Daily beats monthly. A task done fifty times a week pays back a build in weeks; one done quarterly may never pay back at all.
- 2.Can you write the rule down? If you can describe it as "when this happens, do that" and the exceptions are countable, it is a candidate. If describing it takes an hour and ends in "it depends", it is not, yet.
- 3.What does being wrong cost? Wrong record in a spreadsheet: low. Wrong message to a customer: higher. Wrong clinical or financial decision: not a candidate at any frequency.
The best first project scores high, clear and low. The temptation is always the thing that annoys someone most, which is usually the messiest and least rule-shaped process in the building.
What usually wins
- Moving the same information between two systems, which almost every business does by hand somewhere and nobody has ever written down.
- The first reply to an inquiry, which is frequent, time-sensitive, and mostly the same few answers.
- Reminders and confirmations: a fixed trigger, a fixed message, a real reduction in no-shows.
- The report somebody assembles manually every week from three places.
- Follow-up sequences, which fail mainly because a human has to remember them.
What to leave alone
Some things should stay manual permanently, and naming them at the start is what stops a project from sprawling.
- Judgment calls where being wrong is expensive. Pricing exceptions, clinical questions, anything legal.
- The relationship parts. The call after something went wrong is not a workflow.
- Processes that change every month. Automating a moving target produces maintenance, not saved hours.
- Anything where the exception is the point. If nine in ten cases are special, there is no pattern to encode.
Rules first, AI only where interpretation is needed
Most useful systems are mostly rules with a model at the two or three points that genuinely need interpretation: reading an unstructured message, summarising a call, classifying what a request is about.
A model placed where a rule would do makes a system slower, more expensive and much harder to debug. When a rule misbehaves you can read it, and when a model misbehaves you are reasoning about a probability. Order the stages so the cheap deterministic checks run first and only what survives them reaches anything that costs money per call.
Build the failure paths, not just the happy one
The version where everything works is the quick part. The engineering is in what happens when an API is down, a rate limit hits, a field is empty, or the same event fires twice.
Decide the safe state before building: does it retry, queue, or stop and alert? A workflow with no defined answer will pick one on your behalf, and the one it picks is usually losing the record quietly.
Run it in parallel before switching anything off
Keep doing it the old way alongside the new system until the outputs match. It is duplicated effort for a fortnight and it is the difference between finding a flaw as a discrepancy and finding it as an angry customer.
It also means "it did not work" is survivable: the fallback is how you were already running, not a stopped business.
Something has to be watching it
An automation that fails loudly is an inconvenience. One that fails silently is worse than not having it, because everybody has already stopped checking.
Build a separate monitor that reads the system's state on a schedule and alerts a named person when a queue stalls, a stage stops producing, or errors spike. We learned this the expensive way on our own pipeline, which sat idle longer than anyone noticed before a watchdog existed.
The honest version of the payback question
You can estimate it: how many times a week, how many minutes each, what an hour of that person's time is worth. That gives you a number good enough to decide with, and it will be wrong in both directions. Some tasks turn out to be more frequent than anyone thought, and some automations create new small work nobody predicted.
What it will not capture is the part people report most often afterwards, which is not hours saved but the thing that stopped being forgotten.
