Insights

The processes you should not automate

By Darshan R Krishnan · 4 August 2026 · 6 min read

Most writing about automation is about what to automate next. This is about the opposite question, which I think gets asked far too rarely: what should you deliberately leave alone?

Not "can't be automated" — the list of genuinely impossible things shrinks every year. I mean processes where automation is technically achievable and still makes the business worse. These exist, they're more common than the discourse suggests, and recognising them early saves a lot of money.

Five categories I've come to watch for.

1. Processes whose real output is a relationship

Some work produces two things: a deliverable and a relationship. The deliverable is visible and measurable. The relationship isn't, so it doesn't appear in the process map — and it's the thing that gets destroyed.

A check-in call that produces a short status update is the obvious example. The status update is the stated output and could be generated automatically in seconds. But the call also surfaces the thing the client wasn't going to raise formally, maintains the habit of contact that makes bad news arrive early rather than late, and constitutes most of why they renew.

Automate the status update and you'll get a status update. You will also, six months later, have a client relationship that has gone quiet, and you won't connect the two.

The tell: ask what would be lost if this process produced its output perfectly but no human contact occurred. If the answer takes more than a moment, be careful.

2. Processes that are secretly training

Junior people learn by doing work that is, viewed narrowly, beneath them. Reviewing routine cases, preparing first drafts, handling standard requests. It's inefficient — that's exactly why it's the first thing flagged for automation.

But that work is how pattern recognition gets built. Someone who has personally worked through four hundred routine cases develops an instinct for the one that isn't routine. You cannot get that from a training deck.

Automate the entire bottom of the ladder and you get an immediate efficiency gain and a capability gap that shows up in three years, when you need senior people and discover you have no pipeline to make them from. By then nobody attributes it to the automation decision.

I'm not arguing for preserving busywork. I'm arguing that "this work is too basic for a person" and "this work is how people learn" are frequently true of the same process, and the second one has a much longer time horizon than any efficiency calculation you'll run.

3. Processes where the failure mode is silent and expensive

Some processes fail loudly. The output is obviously wrong, someone notices immediately, it gets fixed.

Others fail silently — the output looks entirely plausible and is wrong. A misclassification that routes something to the wrong place. A summary that omits the one material detail. A number that's off by an amount nobody would question.

For these, automation doesn't remove the human; it changes the human's job from doing to catching. And people are dramatically worse at catching errors in plausible-looking output than at avoiding them while doing the work. Vigilance decays fast, especially when the system is right 95% of the time — which is precisely when it's most dangerous, because trust builds and attention drops.

Before automating, ask: if this is confidently wrong, how long until anyone notices, and what does it cost by then? If the answer is "months" and "a lot," the automation needs to be designed around detection rather than throughput, or not built at all.

4. Processes that change faster than you can maintain them

An automation is a snapshot of how a process worked when you built it. If the process is stable, that's fine for years. If it changes every quarter, you've bought a maintenance obligation that may exceed what you were spending on the manual version.

This is easy to miss because maintenance cost is invisible at build time and shows up later distributed across many small updates that never get totalled. Nobody ever computes the annual cost of keeping an automation current. If you did, some of them would clearly be worse than the manual process they replaced.

Rough heuristic: if the underlying rules have changed twice in the last year, be honest about maintenance before you build. And build for changeability over efficiency — a slower, more configurable system beats a faster brittle one for anything volatile.

5. Processes nobody has questioned in five years

Not a "don't automate" so much as a "don't automate yet."

If a process has run unexamined for years, the chance that it's still the right process is not high. Business context changed, systems were replaced, the original reason may have dissolved entirely. What survives is a process that runs because it runs.

Automating it is the worst possible response. You'd be investing in permanence for something that hasn't justified its existence recently, and making it cheaper to run guarantees nobody will ever question it again.

Examine it first. A meaningful fraction of the time, the process can be simplified dramatically or removed outright — which is a far better outcome than automating it well.

The uncomfortable version

There's a commercial tension here I should name, since I run delivery at a company that builds these systems.

The incentive in AI services runs toward automating more. More scope, more build, more contract. Telling a client that a process should be deleted rather than automated is directly against short-term interest.

It's also the only way to be worth keeping around. A vendor who has told you not to build something is a vendor whose recommendation to build something actually means anything. Every implementation that quietly gets abandoned costs more in credibility than it earned in fees — you just don't see the invoice.

The test I'd apply, both as a buyer and a builder: does the case for automating this survive contact with the question "what would we lose?" If nobody's asked that question, it's too early to build.