There is a category of automation that reproduces a human workflow exactly: it opens the same screens in the same order, types into the same fields, copies a value from one system and pastes it into another. It works, it is quick to build, and it is sold on a compelling premise — no integration needed, no changes to the underlying systems, just a robot doing what Fatima does every Tuesday morning. The trouble is what it preserves.
A human workflow contains three kinds of step, and only one of them is the work.
- The actual decision — which invoices to approve, which orders are at risk.
- The data movement, which exists because two systems do not talk to each other.
- The compensation: the double-check that exists because somebody once made a mistake, the spreadsheet that exists because a report does not have a column, the email that exists because a permission was never granted.
Automating the whole sequence preserves all three, which means the compensating steps become permanent. The double-check nobody needed is now performed by a machine ten thousand times a month, the spreadsheet is now generated automatically and still has a missing column, and the reason each of those existed is now harder to discover because no human is there to be irritated by it.
Separate the three kinds of step
The first exercise, before automating anything, is to watch the process being performed and label every step as decision, movement or compensation. This takes a morning and it is almost always revealing, because the proportions are not what anybody expects: in the processes we have mapped, the actual decisions are typically a small minority of the elapsed time, and compensation is frequently the largest category.
Having labelled them, the three categories get three different treatments. Compensation steps should be removed, by fixing the thing they compensate for — granting the permission, adding the column, removing the double-check that catches nothing. Movement steps should be replaced by an integration, so the data flows rather than being carried. And the decision steps are the only ones where the interesting question arises, which is whether a machine should make them at all.
That ordering matters, because removing compensation is the cheapest of the three and frequently removes the need for the rest. We have mapped a process of eleven steps where seven were compensation, and fixing a single report — adding one column that had been missing for three years — reduced it to four. Nobody automated anything, and the time saved was larger than the automation proposal had promised.
Why screen automation is fragile
Beyond preserving the wrong steps, automation that drives a user interface has a structural weakness: it depends on the interface not changing. A field that moves, a new consent dialog, a slower page that loads after the robot has already clicked — each of these breaks it, and none of them is a change anybody would think to announce, because from the perspective of the team that made it nothing was broken.
The failures are also quiet in a specific and dangerous way. A broken integration returns an error; a broken screen automation often completes successfully having typed a value into the wrong field, or having skipped a page that failed to load. The process reports success, the data is wrong, and the discovery happens downstream — which is the worst property an automated process can have.
The maintenance is the cost
So the honest cost of screen automation is not the build, it is the ongoing repair, and it scales with how many systems the robot touches and how often any of them changes. A robot spanning four third-party web applications is subject to four independent release schedules it does not control. We have seen a portfolio of these consume more engineering time in maintenance than the manual process consumed in labour, which is the point at which it should be retired and rarely is, because retiring it means admitting the original decision.
Which decisions a machine should make
For the decision steps, the useful question is not whether a machine can make the decision but what happens when it makes it wrongly. A decision that is cheap to reverse and cheap to get wrong — routing a ticket to the probable team, suggesting a category, ordering a list — can be automated with a modest accuracy and still be clearly worthwhile, because the cost of an error is a small correction.
A decision that is expensive or irreversible — issuing a refund, declining an application, sending a message to a customer — needs either a much higher bar or a human in the loop, and the useful middle path is to automate the recommendation rather than the action. The machine does the work of gathering and ranking, a person approves, and the approval step is one click rather than twenty minutes of assembly. That pattern captures most of the saving with almost none of the risk.
It also produces training data as a side effect, which is the part worth planning for. Every approval and every override is a labelled example, and after a few months you have an honest measurement of how often the recommendation was right — on real cases, graded by the people who do the job. That is a better evaluation set than anything you could assemble deliberately, and it only exists if the override reason is captured at the time.
| Step type | What to do with it | Why |
|---|---|---|
| A real decision | Automate the recommendation | Keeps the cheap approval, drops the assembly |
| Data movement | Replace it with an integration | It exists because systems do not talk |
| A double-check | Measure what it catches, then delete | Usually guards a fixed mistake |
| A manual spreadsheet | Add the missing column upstream | One report fix removes the step |
| An email asking permission | Grant the permission | The step is an access problem |
The exception handler is the system
Any automation of a real process will encounter cases it cannot handle, and the proportion is higher than the initial estimate because the people doing the work have been absorbing the exceptions invisibly for years. A process described as "the same every time" turns out, on inspection, to have a dozen variants that the operator handles without noticing them as variants.
So the exception path is not an edge case to be added later; it is a primary feature and often the larger half of the build. It needs a place for the stuck items to go, a view somebody checks, enough context attached to each one that a person can resolve it without re-deriving the whole case, and a way to put it back into the flow afterwards. An automation without this silently stops processing a growing proportion of its input.
And the exception rate is the number to report, not the automation rate. A process that handles eighty percent of cases automatically is a good outcome; the same process described as "fully automated" with a fifth of the volume quietly accumulating in a folder is a worse outcome described better, and the difference between those two framings is where most disappointment in this area comes from.
What the saved time is for
Automation proposals are costed in hours saved, and the hours are usually real, but the business case depends on something the proposal rarely states: what those hours become. If the team was at capacity and the hours go into work they could not previously reach, the value is straightforward. If the hours were slack, nothing changes financially and the project is a quality improvement rather than a saving, which is a legitimate goal described honestly.
There is a third case worth naming because it is the most common and the least discussed: the hours were spread thinly across several people as an interruption rather than concentrated as a task. Removing a ten-minute interruption that happened six times a day is worth considerably more than the hour it appears to save, because the interruption was costing the surrounding work as well — and that benefit is real and almost impossible to put in a spreadsheet.
Stating which of the three cases applies is worth doing before the work starts, because it determines what success looks like and who should be judging it. A project sold as a cost saving and delivered as a quality improvement will be assessed against the wrong number, and the team that built something genuinely valuable will spend the review defending it.
Write the rule down before the code
Most of the difficulty in automating a decision is that nobody has ever stated the decision. The person doing it has a reliable instinct built from four years of cases, and asked to explain it they produce three criteria and a shrug. Writing the rule down is therefore the bulk of the work, and it is work that pays for itself even if no automation follows, because an unstated rule is also an untrainable and unauditable one.
The method that works is to take thirty real past cases and have the expert decide each one again, out loud, while somebody writes down what they used. The first ten produce the obvious criteria, the next ten produce the exceptions, and the last ten usually produce one criterion nobody mentioned in the interview and which turns out to be the most predictive. That exercise is a day and it is the difference between automating the decision and automating a guess about it.
It also surfaces the cases where two experts disagree, which is the most valuable output of all. A rule that two competent people apply differently is not a rule yet, and automating it just picks one of them silently and permanently. Those disagreements are a decision for the business to make deliberately, and they are much cheaper to resolve on a whiteboard than in production.
The audit trail is the deliverable
An automated decision that cannot be explained afterwards is a liability wearing the costume of an efficiency. Somebody will eventually ask why this application was declined, this invoice flagged, this order held, and the answer has to be better than a confidence score. Recording the inputs, the rule version and the outcome for every decision is not compliance overhead; it is the thing that lets you keep the automation when somebody challenges it.
The rule version matters more than it sounds. A decision made in March under one threshold and reviewed in September under another is indefensible unless the record says which threshold applied at the time. That means the rules need to be versioned data rather than code constants, and every decision record needs to name its version — a small design choice at the start and an impossible retrofit later.
- The inputs as they were at decision time.
- The rule version that applied, by identifier.
- The outcome, and which branch produced it.
- Who reviewed it, if a human did.
- What changed it later, and on whose authority.
Inputs have to be stored as they were, not referenced. A record that points at a customer row describes that customer as they are today, not as they were when the decision was made, and in any dispute the two differ — the address changed, the limit was raised, the status moved. Copying the relevant inputs into the decision record looks like duplication and is the only version that can be defended.
Measure the step before removing it
Automation projects are usually justified with a number somebody estimated in a meeting, and that number is almost always wrong in the same direction: the step takes less time than people think and happens more often. Timing it for a fortnight before committing changes the business case more often than it confirms it, and it costs a spreadsheet and somebody’s attention.
Frequency beats duration
When those two numbers are measured rather than guessed, the ranking of candidates usually reorders. The twenty-minute task everybody complains about happens twice a month; the forty-second task nobody mentions happens two hundred times a day. The second is both the larger cost and the easier automation, and it is invisible precisely because it is too small to complain about.
Measuring also establishes the baseline you will need afterwards to know whether the automation worked. Without a before, the after is unfalsifiable, and automation projects are unusually prone to being declared successful on the strength of having shipped. A single number recorded for two weeks beforehand is what turns that into a verifiable claim.
What happens when the machine is wrong
Every automated decision will be wrong sometimes, and the design question is not how to prevent that but what it costs when it happens. A wrong recommendation that a person reviews costs a second of attention. A wrong action taken silently costs whatever the action was, plus the time to notice, plus the time to find every other case with the same cause. Those are different enough that they justify different designs.
Which means the reversal path has to be built at the same time as the decision, not after the first incident. For every automated action, somebody should be able to answer how it is undone, how you find all the records it touched, and who is allowed to do that. If the answer to any of those is a database query written under pressure, the automation is not finished regardless of how well it performs.
There is a useful staging here that costs little: run the automation in shadow for a fortnight, recording what it would have decided without acting, and have somebody compare it against what actually happened. The disagreements are the specification for the rest of the work, and they arrive before anything is at stake rather than after.
A sequence that usually works
The order we have settled on is: map the process and label the steps; delete the compensation by fixing what it compensates for; replace the movement with an integration; then, and only then, look at the decisions. By the time you reach the decisions there are frequently only two or three left, and the automation question has become small and specific rather than a programme.
The reason this order is worth insisting on is that each stage reduces the scope of the next, so the expensive work is sized against a process that has already been simplified. Doing it in the opposite order — automating first and cleaning up later — means paying to automate steps that were about to be deleted, and then being reluctant to delete them because they have just been paid for.
- Watch the process once and label every step.
- Delete compensation by fixing what caused it.
- Replace data movement with a real integration.
- Automate recommendations where reversal is costly.
- Build the exception path as a primary feature.
- Report the exception rate, not the automation rate.
The summary is that the word automation describes two quite different purchases. One of them copies a person, including their workarounds, and acquires a maintenance obligation tied to interfaces you do not control. The other removes the reason a step existed, which is permanent and usually cheaper. Both are sold with the same vocabulary, and the only reliable way to tell them apart is to ask which steps are being deleted rather than which are being performed by a machine.
