Stop Automating. Start Eliminating.

There is a pattern I see repeat across almost every company that starts working with automation: they take an existing process, map out the steps, and ask where AI can help. The result is a faster process. Sometimes much faster. But it is still the same process.

The harder question is not where AI fits in. It is why the process exists the way it does.

The invisible cost of inherited process

Corporate processes accumulate layers. An approval step added after a one-off problem in 2018. A weekly report that no one is quite sure anyone reads. A manual triage step that existed because the old system did not filter well, and the new system was never reconfigured to fix that.

When you automate these steps, they become cheaper to run. But they keep consuming attention, creating dependencies, and adding friction to the flow. Speed does not fix a broken structure.

A concrete example: a financial services firm I worked with had a commercial proposal approval cycle that averaged eleven days. There were four review levels. When we mapped two years of history, we found that the third level, responsible for legal scope validation, had rejected or materially changed proposals in fewer than 3% of cases. And in those cases, the changes were minor.

The solution was not to automate the legal review. It was to eliminate that step entirely for proposals below a set threshold, replacing it with a standardized checklist at the start of the process. The cycle dropped to four days. No new software was purchased.

The question no one asks

Every step in a process was created for a reason. The problem is that the original reason does not always remain valid. Systems change, teams change, market context changes. But the process stays because no one stopped to ask: if we were designing this today, would we do it the same way?

When I start a process diagnostic project, I use a simple framework for each step:

• What problem was this step created to solve?
• Does that problem still exist at the same intensity?
• What actually happens when this step fails or gets skipped?
• Is there another step in the flow that already covers this function, even partially?

Four questions. Typically, between 20% and 40% of steps do not survive that review.

A triage step that triaged nothing

Another concrete case: a high-volume e-commerce support operation had a manual triage queue where agents categorized each incoming ticket before routing it. The historical justification was that the old CRM had unreliable auto-categorization.

The CRM had been replaced two years earlier. The new system categorized tickets with over 90% accuracy. But the manual triage persisted by inertia, now serving mainly to catch the 10% of errors, which in practice consumed two full-time staff members.

The decision was to eliminate manual triage as a default step and create a small residual queue, reviewed once a day, for tickets the system flagged with low confidence. That queue represented less than 8% of total volume. The two people were reassigned to complex case handling, where their judgment actually made a difference.

That was not automation. It was recognizing that an entire step had become a ritual with no real function.

Reports no one read

A third example, more common than it seems: internal reporting. Every week, across dozens of companies, someone spends hours consolidating data, formatting spreadsheets, and sending reports to a distribution list that grew organically over the years.

I ran an exercise with a mid-sized company: we sent a short survey to every recipient of three weekly reports asking whether they opened them, how often, and what decision that data had informed in the past month. Two of the three reports could not be tied to any identifiable decision. The third was actively consulted by two people on a list of twelve.

We eliminated the two. The third became a simple dashboard, updated automatically, accessed on demand. The time previously spent producing those reports went back into actual analysis.

The logic behind elimination

Eliminating a process step requires a different kind of accountability than automating it. Automation is additive: you layer a tool on top and the process keeps existing. Elimination is subtractive: you take responsibility for saying something should no longer exist.

That is why most companies never get there. It is easier to approve a new tool than to retire an old approval.

The reasoning I follow is straightforward: before asking how to automate something, I ask what it actually costs to keep that step alive. Not just time, but the attention cost, the dependency it creates, the delay it injects into the flow. Once that cost becomes visible, the decision to eliminate usually becomes obvious.

AI is a remarkable tool for running well-designed processes faster and with fewer errors. But it does not fix the architecture. That is still human work, and it starts with the willingness to question what should not be there in the first place.