When a business decides to automate something, the instinct is to pick the hardest, most visible task: the thing that would impress people if a machine did it. That is usually the worst place to start, because the hard tasks are hard for a reason: they involve judgement, exceptions, and someone's reputation if they go wrong.
The steps worth taking first are the ones nobody would defend in a meeting. Copying a number from an email into a spreadsheet. Renaming a file so the next person can find it. Sending the same three-line message every time a job reaches a certain state.
How to find them
Follow one job end to end and write down every point where information changes hands. Not what people say the process is. What actually happens, including the WhatsApp message that is technically not part of the process but without which nothing moves.
The four questions that find the candidate
- Does this step happen more than a few times a week?
- Does it produce the same shape of output every time?
- If it is done wrong, is it obvious immediately?
- Would anyone be upset if a machine did it?
Four yeses and a no on the last one is the step to automate. High frequency means the saving compounds. Consistent output means the rules can be written down. Visible failure means a mistake gets caught the same day instead of surfacing in an audit. And nobody defending it means you are not fighting a person while you build.
The best first automation is one that, if it broke tomorrow, would be annoying, not dangerous.
Why the middle and not the ends
The two ends of a process are where humans add most of their value. The start is where judgement happens: is this worth doing, what does the customer actually mean. The end is where the relationship lives: the call, the delivery, the follow-up.
The middle is transport. Information moving from one place to another, changing shape slightly on the way. Nobody was hired for their transport skills, and a machine moving data between two systems has no bad days.
Where AI belongs in this
A language model is good at exactly one part of the middle: the part where the input arrives in an unpredictable shape. A supplier email that puts quantities in a sentence one week and a table the next. A voicemail that needs to become a job note. Rules struggle with that; a model handles it well.
What it should not do is decide. Extraction, classification, drafting: yes. Approving a discount, releasing a payment, telling a customer something is fine: no. The boundary is simple: if being wrong costs money or trust, a person confirms it, and the system makes that confirmation take two seconds instead of ten minutes.
Do that once and the second one gets easier, because the connections are already built. Start with the hardest thing instead and you often end up with a demo that impressed everyone in the meeting and is not running six weeks later.