The current wave of automation projects has an unusually high abandonment rate, and the cause is consistent. The projects begin with a capability looking for a problem: someone sees a demonstration, imagines an application and commissions a pilot before anyone has measured the work it is supposed to replace.
The alternative is unglamorous and effective. Start from the operational tasks that consume the most hours, examine what each one actually requires, and apply the simplest mechanism that can do it reliably. Sometimes that mechanism involves a language model. Often it does not, and recognising the difference is the main skill.
Start with the work, not the technology
Before evaluating any tool, spend a week measuring. For each candidate task, record how often it happens, how long it takes, who performs it, what inputs it requires and what happens when it is done wrong.
This produces two immediate benefits. It reveals that some tasks people complain about are infrequent and cheap, while genuinely expensive tasks are so routine that nobody mentions them. And it produces the baseline you will need later to prove whether the automation worked.
Three kinds of automation, in order of preference
Not all automation is the same, and the differences matter for cost, reliability and risk. Prefer the earlier options wherever they are sufficient.
1. Deterministic automation
Rule-based logic and system integration: when an order is approved, create the delivery record; when an invoice passes its due date, add it to the collection list; when a form is submitted, route it to the right queue. This is predictable, testable, cheap to run and easy to debug. Most operational value lives here, and it is routinely skipped because it is not exciting.
2. Assisted automation
A model proposes and a person confirms: a suggested classification, an extracted set of fields, a drafted reply. The person remains accountable, so an imperfect suggestion is a small cost rather than an incident. This is where language models earn their place in most operational settings.
3. Autonomous automation
The system acts without review. This is appropriate only where the action is low-risk, easily reversible and monitored, or where accuracy has been demonstrated over a substantial period of assisted operation. Starting here is how automation projects damage trust permanently.
Opportunities that are usually worth the effort
Across operational businesses, the same handful of patterns produce most of the value.
- Document intake: extracting structured fields from supplier invoices, delivery notes or purchase orders, presented for confirmation rather than posted silently.
- Classification and routing: deciding which team, queue or category an incoming request belongs to, so nobody triages a shared inbox by hand.
- Summarization for handover: condensing a long email thread or case history so the next person can act without reading everything.
- Internal knowledge retrieval: answering "what is our policy on this" from approved internal documents, with the source shown so the answer can be verified.
- Exception detection: flagging the transactions that look unlike the others so a reviewer examines twenty records instead of two thousand.
- Data entry between systems: eliminating retyping between tools that do not integrate natively.
- Draft generation: producing a first version of a recurring report or standard response for a person to edit.
Notice that most of these reduce the volume of work reaching a person, or improve what arrives, rather than removing the person. That is the realistic shape of operational automation today.
Where not to use AI
Some tasks should stay deterministic or stay human, and the reasons are practical rather than philosophical.
- Calculations. Arithmetic belongs in code, where it is exact, testable and auditable.
- Regulated decisions with legal consequences, unless a qualified person reviews and takes responsibility.
- Anything requiring a guaranteed identical answer every time it runs.
- Processes whose correct behaviour nobody can define, since automating an undefined process produces confident inconsistency.
- Tasks where an error is discovered late and is expensive to reverse.
- Workflows built on data you are not permitted to send to an external service.
If a rule can express it, write the rule. Probabilistic tools are for problems that resist rules, not for problems nobody has bothered to define.
Designing the human checkpoint
A review step is only useful if it is genuinely capable of catching errors. A checkbox that people click without reading is worse than no checkpoint at all, because it creates the appearance of control.
- Show the source. A suggestion accompanied by the document or record it came from can be verified in seconds.
- Make correction faster than redoing the work, or reviewers will bypass the system.
- Record every correction. Corrections are the dataset that tells you where the automation is weak.
- Escalate on low confidence instead of guessing, and make the escalation path obvious.
- Review the reviewers periodically: approval rates near one hundred percent usually mean nobody is actually reading.
Governance and data boundaries
Automation touching business data requires the same controls as any other system, and a few specific to this category.
- Decide explicitly which categories of data may leave your environment and which may not, and enforce that decision in the implementation rather than in a policy document.
- Keep credentials in a secret store, never in workflow definitions or prompt text.
- Log every automated action with enough detail to reconstruct what happened and why.
- Give every workflow a named owner responsible for its behaviour, its failures and its retirement.
- Define the failure mode before launch: does the process stop, queue for a human, or fall back to the manual path?
- Review active automations on a schedule. Workflows outlive the conditions they were built for.
Measuring whether it worked
Adoption is not success. A workflow can run thousands of times a month and still deliver nothing if people redo the work afterwards or spend the saved time correcting output.
- Time spent on the task, compared to the baseline you recorded before starting.
- The correction rate, and its direction over time.
- The escalation rate, which should be stable rather than steadily climbing.
- Errors reaching the end of the process, compared with the manual baseline.
- Cycle time from request received to request resolved.
- The total operating cost, including the platform, the model usage and the review effort.
Be willing to switch an automation off. A workflow that saves twenty minutes and costs thirty minutes of supervision is a loss regardless of how sophisticated it is.
A realistic first project
The purpose of the first automation project is not to transform the business. It is to establish whether your organization can specify, deploy, supervise and evaluate an automated workflow at all. Choose accordingly.
- Pick one task that is frequent, well-defined, low-risk and currently annoying to a specific team.
- Measure the current cost for two weeks: volume, time per item and error rate.
- Write down what correct output looks like, in enough detail that two reviewers would agree.
- Build the simplest version that works, using deterministic logic wherever it is sufficient.
- Run it in assisted mode with a human confirming every result.
- Record corrections and fix the top failure cause before adding any new capability.
- Compare against the baseline after four to six weeks and decide honestly whether to expand, adjust or stop.
A first project that saves a few hours a week and is genuinely trusted is a better foundation than an ambitious one that nobody uses. The organizations that get value from automation are rarely the ones that started with the largest idea; they are the ones that finished the small one and learned how to run it.