What we automate first when a team is drowning in manual work
A practical way to find the first workflow worth automating — before tools and model choices enter the conversation.
The instinct is to automate the thing that annoys people most. That is usually the wrong place to start: the annoying step is often rare, messy and full of judgement calls.
We look for a different shape instead — something that happens every day, takes a predictable input and produces a predictable output.
Start with the queue, not the tool
A useful automation candidate usually leaves a queue behind it: unread requests, invoices to classify, orders to copy or records waiting for a status change.
Write down where the queue starts, who touches it and what marks an item as finished. If the team cannot agree on that path, software will only make the disagreement run faster.
Score the work on four signals
Frequency comes first. A small task repeated every day can be a better target than a painful task that happens once a quarter.
Then check consistency. The input does not need to be identical, but the team should recognise the same few patterns and know what a correct output looks like.
Next, look at the cost of an error. If one wrong decision can create a financial or legal problem, keep a person at that decision point.
Finally, check whether the source data is accessible. An automation cannot be reliable if its input lives in screenshots, private chats or a spreadsheet nobody owns.
Define the exit before the happy path
Every automation needs a clear way to stop and ask for help. That can be a confidence threshold, a missing field or a rule that sends unusual cases to a review queue.
The review screen matters as much as the automated step. It should show the original input, the proposed result and the reason the item needs attention.
If nobody can describe the step in two sentences, it is not ready to be automated.
Measure one complete cycle
Before building, follow a small sample from arrival to completion. Count the human touches, waiting time and corrections. This gives you a baseline without inventing a return-on-investment figure.
After launch, measure the same cycle again. The useful result is not how many model calls ran. It is how much work left the queue and how often a person had to repair the output.
A good first automation
The best first project is narrow enough to inspect, common enough to matter and reversible when it fails. It proves the workflow before the team connects more systems or hands over more decisions.
Once that loop is stable, the next candidate becomes easier to judge. You now have real operating data instead of a promise about what AI might do.
