Automation is usually sold as a general good: automate more, save more time. That framing produces two expensive mistakes in opposite directions.
The first is automating something that should not be — encoding a rule that turns out to be judgement, then spending years handling exceptions the automation created. The second is not automating obvious repetition because it never got prioritised, so a person keeps performing a task a machine could do reliably.
Telling them apart is not difficult, but it requires being specific about what a given task actually is.
The four conditions
A task is a good automation candidate when all four hold. Miss one and the economics usually collapse.
It is frequent. Automating something that happens twice a year costs more to build and maintain than it saves. Frequency is what pays back the build.
It is rule-based. The decision can be written down completely, including what happens in unusual cases. If the honest description contains "it depends on the situation", you have judgement, not a rule.
It is stable. The rules are not going to change every quarter. Automating a volatile process means maintaining the automation permanently, which can exceed the cost of doing the task.
Failure is detectable. When it goes wrong, somebody notices. Silent failure is the dangerous category — an automation that quietly does the wrong thing for six weeks is worse than a person doing it inconsistently, because nobody is checking.
That fourth condition is the one most often skipped, and it is the one that produces the worst outcomes.
What usually qualifies
In most operations, the same candidates appear:
- Recurring documents — invoices for the same customers on the same cycle
- Reminders — payment due, stock below threshold, expiry approaching
- Data movement between steps — a confirmed order becoming a dispatch instruction
- Threshold alerts — variance beyond a limit, a margin below floor
- Routine reconciliation — matching payments to invoices where the rule is unambiguous
- Status propagation — one update reaching everyone who needs it
The common thread: mechanical, high frequency, unambiguous, and visible when wrong.
What usually does not
Anything involving a judgement call about a person. Credit decisions, hiring, whether to make an exception for a long-standing customer. These can be supported by automation surfacing the relevant facts. Automating the decision itself encodes yesterday's judgement permanently and removes the accountability.
Processes with genuine exceptions. If a fifth of cases need human handling, automating the rest often produces a worse outcome — staff now handle only the hard cases with no routine work to maintain context, and the exception path is the least designed part of the system.
Anything changing quarterly. The automation becomes a maintenance obligation that outlasts its benefit.
Communication that carries relationship weight. Automated messages to a customer mid-dispute save minutes and cost considerably more.
A broken process. Automating a bad workflow produces a faster bad workflow. This is the most common failure we encounter — the automation is blamed when the underlying process was the problem.
The question that prevents most mistakes
Before automating anything, ask: what happens when this is wrong?
Not if — when. Every automation eventually acts on bad input or hits a case nobody anticipated.
If the answer is "someone notices immediately and corrects it", proceed. If it is "we would find out at month end", or "the customer would tell us", the automation needs a detection mechanism before it needs to exist.
An automation without a failure path is not a time saving. It is deferred, compounded work.
Automation is not the same as integration
Worth separating, because they get conflated in sales conversations.
Integration moves data between systems that already exist. It addresses the handoff problem.
Automation performs an action without a person initiating it.
Many businesses asking for automation actually need integration — the task feels manual because information is being carried between systems by hand. If the same figure is entered in three places, the fix is a shared record, not a robot performing the three entries faster. That is the argument in what a business operating system actually is.
Automating data re-entry preserves the architecture that made re-entry necessary.
Where AI changes this, and where it does not
The four conditions still apply. What has changed is the second one.
Language models can handle tasks that resisted rule-writing — reading unstructured documents, summarising, classifying loosely-defined categories. That genuinely widens the set of automatable work.
What has not changed:
Detectability still governs. A probabilistic system fails differently — plausibly rather than obviously — which makes failure harder to notice, not easier. The fourth condition becomes more important, not less.
Judgement is still judgement. A model producing a confident answer to a question that requires accountability has not removed the need for accountability.
A broken process is still broken. Applying a model to it makes it fast and wrong.
Our position is that a model should generate and summarise, and deterministic logic should decide anything consequential. In SYNTAX, that separation is explicit — logic computes assessment scores; the model writes the narrative. The same principle governs AI in operations software.
What we have seen
Across the ten systems we have delivered, the automation that pays is consistently smaller and more boring than what clients initially request.
Businesses arrive wanting comprehensive automation of a whole process. What changes the numbers is usually two or three narrow things: a reminder that fires reliably, a threshold alert that surfaces variance the same day, a document that generates itself.
The other consistent finding is that requests to automate a task are frequently requests to avoid confronting the process. When a task is painful, automating it removes the pain and preserves the cause. The first question we ask is whether the step needs to exist at all — and often the best automation is deletion.
That is why our first phase documents how the operation actually runs, including the workarounds. The method is in how Truffaire builds software.
Frequently asked questions
What should we automate first?
The task that is most frequent, most mechanical, and most visible when wrong. Usually a reminder or a recurring document. Start where failure is obvious, so you learn how automation behaves in your operation before trusting it with anything consequential.
How do we know if it is worth building?
Multiply the time saved by frequency, over a year, and compare against build plus maintenance. Most businesses forget maintenance. If it is close, it is not worth it — the clear wins are clear.
Will automation reduce headcount?
Sometimes, but the more common outcome is the same people doing different work. Where a role is largely mechanical repetition, that is a genuine conversation to have honestly rather than discover.
Can we automate approvals?
You can automate routing — getting the right item to the right person quickly with the facts attached. Automating the decision means encoding a rule you may not want to defend later. Route, do not decide.
What about low-code tools?
Good for the narrow, stable, detectable cases above. The failure mode is accumulating dozens of small automations nobody documented, which becomes its own maintenance problem within two years.
Where to start
List the tasks people perform repeatedly. For each, test the four conditions — frequent, rule-based, stable, detectable when wrong. Then ask whether the step should exist at all.
What remains after that filter is usually short, and it is where automation actually pays. Everything else is either judgement worth keeping human, or process worth fixing before it is worth automating.
SPEXA treats automation this way — narrow, surfaced, and reversible. If you want a read on which of your tasks qualify, get in touch.