Most teams do not lose entire days to one large task. They lose them in twenty-minute fragments: copying details between two systems, chasing an approval that has stalled, rewriting the same email for the fifth time, checking whether an order actually shipped. Automation earns its place when it removes those fragments, and disappoints when it is sold as a replacement for judgement rather than a way of protecting it.
Where automation genuinely pays off
Good first candidates share three traits. The task is repetitive, it follows rules you could write down for a new starter, and mistakes are costly but detectable. When all three are true, the process is usually both safe to automate and easy to justify, because you can describe the improvement in interruptions avoided rather than in vague efficiency gains.
- Data movement between systems that do not talk to each other, such as an accepted quote becoming an invoice.
- Intake and triage: reading inbound forms and email, then routing each item to the right queue with context attached.
- Scheduled reporting that gathers figures automatically so a person interprets them instead of assembling them.
- Notification and escalation, so a stalled item surfaces before a customer has to ask about it.
- Draft generation for routine correspondence, quotations and summaries that a human reviews and sends.
Each of these has a defined trigger and a defined outcome, which is what makes them testable. If you cannot describe the trigger and the finished state in a single sentence, the process probably needs clarifying before it needs automating. Ambiguity that confuses the people doing the work will confuse the software just as reliably.
The difference between rules and models
Traditional automation executes rules, and it is excellent at volume, speed and consistency. Ask it to classify an unstructured enquiry or interpret a supplier document that arrives in a slightly different layout each time, and it fails. That ambiguity is exactly where language models are useful: reading a free-text message, extracting the fields that matter, or reducing a long thread to a short brief for whoever picks it up.
In practice the two work best together. A model extracts the supplier, date and total from an invoice; a rules engine validates that the total matches the purchase order and that the supplier is approved; anything below a confidence threshold or outside tolerance is routed to a person with the extracted values shown next to the original document. The model absorbs variation while the rules carry the guarantees, and the reviewer sees exactly what the machine proposed.
A sensible way to start
- Map the process as it is actually performed, including the workarounds people have quietly invented to survive it.
- Measure the baseline honestly: how long it takes, how often it goes wrong, and who gets interrupted when it does.
- Automate one step end to end rather than half of five steps, so that you can tell whether it worked.
- Add logging, alerting and a way to switch the automation off without losing the work already in flight.
- Review after a month with the people doing the job, then decide whether to extend, adjust or revert it.
Where these projects go wrong
Automation rarely fails because the technology was not clever enough. It fails because nobody owned the workflow after launch, because edge cases failed silently for weeks while the dashboard stayed green, or because the process was flawed to begin with and the tool faithfully accelerated the flaw. Buying a platform before understanding the process simply moves the confusion into a more expensive place.
Build the audit trail first. Every automated action should record what triggered it, what it decided, which rules or model version were involved, and what happened next. That record is what lets you answer a customer question, satisfy an auditor and improve the workflow without guessing. It is also the difference between troubleshooting in minutes and reconstructing history from memory.
Automate the process you actually have, or you will simply do the wrong thing faster.
Pick one painful, well-understood workflow. Instrument it, automate the repetitive part, keep a person accountable for the outcome, and measure the change in interruptions rather than the change in headcount. Teams that start that way tend to keep going, because the second and third candidates become obvious once the first one runs quietly in the background.
