The Best Automation Decision Is Often to Delete the Step

No one sets out to build a process that needs six tools and a phone call. It happens one reasonable decision at a time.

A spreadsheet replaces something a person used to remember. A checklist is added because one case was forgotten. Someone writes a document for the situations the checklist cannot express, and a second spreadsheet appears for the requests the first one cannot hold. Every one of those steps was a fix. Together they became a job, and the job is not the work: it is managing the work.

The cost lands somewhere easy to miss. The task still gets done, so nothing looks broken. What has grown is the attention it takes, and it grows again each time someone new has to learn the process.

The obvious response is to automate the copying. That is usually the wrong way round. Automate a confusing workflow and you get a faster confusing workflow, with one more thing to look after. Before choosing a tool, there is a question that costs nothing to ask: which parts of this work should exist at all?

Watch the work before changing it

The instructions describe how the work is meant to happen. Watching someone do it usually shows something else: exceptions no one wrote down, information fetched from another system, small decisions that have become habit.

A recipe makes that gap easy to picture. It lists the steps it can list, and says nothing about the burner with one working setting, or the cupboard where the flour actually lives. The cook manages those things because they know the kitchen. The comparison has a limit (a kitchen is physical and a recipe does not change), but the useful part is the distance between what is written down and what is done.

So the first useful thing is not a design. It is a look at how the work really happens. What starts a task, and what has to be known before anyone can begin. Who decides what, and at which moment. Where time is spent waiting. What a correct result looks like when it arrives.

The purpose is not to judge the people doing the work. It is to find out where the effort goes, and why, usually because a step no longer serves the purpose it was added for.

Follow one request through

The following is an illustration of the approach, not a description of a deployed system: one request, moving through a process built along the lines described below.

A request arrives the way most of them do: as a message, not a form. Someone needs a summary of last month’s figures for a meeting, and writes that in one sentence, without saying which figures or by when.

It gets stored as it was written, before anyone interprets it. That matters later, because interpretations drift and the original does not.

A model reads it and suggests what is probably being asked for: a report, a recent month, some numbers. It also spots what is missing: which month, which figures, and when it is needed. It does not decide what to do about the gaps, and it does not choose who should handle the request.

Software puts those suggestions into a fixed shape, so the blanks are visible instead of guessed at, and then checks the things that have definite answers: does the file exist, is this person allowed to open it, is there already an open request for the same thing.

Only now does a person get involved, and only for the part that needs one. Someone says which month and which figures, and the request is ready to go.

From there it enters the process the team already runs, and when the report comes back it is checked against what was asked for at the start, not against whether the software ran or whether the model sounded confident. The result and the check stay with the request, so the next person can see what happened.

Almost nothing in that example is faster to click. What changed is who holds what. The person asking no longer needs to know how the team routes its work, and no one has to reconstruct the same context twice.

Ask three questions of every step

Seeing the work clearly makes three questions easier to ask. Can this step disappear? Can a rule carry it? Does it need a person?

Can it disappear? Entering the same information twice, an approval no one can remember refusing, an explanation repeated for each new request, a detail the system already holds somewhere else. These steps do not need to be faster. They need a reason to continue, and often there is none. Deleting one removes the maintenance, the training, and one more place to break. It is the cheapest improvement available, because the work is simply gone.

Can a rule carry it? Checking that a field is present, confirming a permission, routing by a known table, updating a status, converting a format. Where the same conditions should produce the same result, software should produce it, because software produces it the same way every time. That is what makes a failure reproducible and a fix checkable.

Does it need a person? Ambiguous requests, unusual cases, decisions that are expensive to undo, and anything where the situation matters more than the rule. These are the places where a person changes the outcome rather than merely approving it.

The order matters. The first group is the most tempting to automate, because something visible gets faster, and automating it feels like progress. It also preserves a step that should not exist, and adds a component that needs attention for as long as the process lives. Faster is not the same as better, and the second one is what the work is for.

Let software handle the clear rules

Where an answer already exists, software should give it. If a request must contain a field, its presence can be checked. If a file has to exist, the storage system knows. If someone needs access, the permission is a fact, not an opinion. None of that improves with interpretation.

A model is useful where the input is messy: a request written the way people actually write, with details buried, missing, or named differently each time. Reading that, and turning it into something the rest of the system can work with, is real work that ordinary software does badly. What comes out is a proposal, and a proposal is a good thing to have early and a poor thing to treat as an answer. I don’t think an AI response should automatically become a decision. The steps after the model are what turn a proposal into a result.

Two rules keep that boundary honest. The first is about evidence: a model saying that a file exists does not establish that the file exists, and a model saying that someone should have access does not establish that they do. Confidence is not a check, and being right once is not the same as being reproducible.

The second is about permission. A model should see only what the person asking is already allowed to see, and that boundary belongs in code, enforced before the text reaches the model. Asking an assistant not to reveal something is a request, not an access-control system.

Put people where the decision is hard to undo

Not every step deserves a checkpoint. Reviewing a cheap, reversible action adds delay without changing the likely outcome. Reviewing an irreversible one is often the last moment when a mistake is still cheap to catch. The question is not whether a person is involved, but whether their judgment changes the quality or the safety of the decision.

Failure needs the same care. Some errors can simply be retried; others need a person. Either way, the original request and the current state should survive, the message should say what happened in plain language, and there should be a next action to take. A silent failure that produces a plausible wrong result is harder to find than a loud one that produces nothing, and it is harder to find precisely because everything looks fine.

Verification is its own step, not a by-product of finishing. The question is not whether the work ran without errors, or whether the model sounded sure. It is whether what came out matches what the person asked for. That is a comparison, and someone has to make it.

A handoff carries the same idea further. It works when it brings its own context: what was asked for, how the system read it, what is still unclear, and why a decision is needed. Without that, every handoff turns into a small investigation, and the person receiving the work spends their time rebuilding what the sender already knew.

The part that outlives the build

A working automation is not the end of the work, because the conditions it was built for do not hold still. Rules change. An integration changes how it exchanges information. A model gets updated and reads some requests differently. Situations appear that the design did not anticipate.

A person performing a slow process adapts without anyone deciding to adapt. A rule keeps doing exactly what it was told until someone changes it. That difference is a reason to name an owner for every automated step, in advance, and to decide how a rule, a model version, or an integration gets changed when the world moves.

So the question after the build is not only whether the process is faster. It is whether someone unfamiliar with it can complete a typical request without an expert, whether mistakes surface before they spread, whether the decisions can be followed by someone who was not there, and whether anyone knows what it costs to keep running. A diagram cannot answer any of those, and neither can a successful demonstration. They show up in use, which is why they are worth naming before the build rather than after it.

The measure I care about is not whether a workflow uses AI. It is whether the next person can pick it up without a briefing, and whether the system makes its own failures visible when something goes wrong.

And sometimes the honest answer is that no system is needed at all: that a piece of work no longer has to exist. That is not a design, and it is the kind of engineering I find most rewarding.