Don't automate the human out. Automate everything around them.

The most expensive automation we ever cleaned up had removed the one person who knew what was going on

A few years back a company asked us to fully automate their refund approvals. Every refund used to hit a manager who either approved or rejected it. Too slow, they said. Kill the manual step. So someone, not us, wrote a rule: under a certain amount, approve automatically. It ran for three months before anyone looked closely.

In those three months it had approved refunds to customers who were already flagged for fraud, because the rule only looked at the amount. The manager it replaced would have caught every one of them in a second. He knew the names. The rule knew a number.

That's the trap with full automation. The machine does exactly what you told it, including in the cases where a human would have stopped.

Why "remove the human" is the wrong instinct

When people ask us to automate something, "fully" is almost always attached. No waiting, no bottleneck, nobody in the loop. And I get it. You're paying for a tool to do the work, so a person still clicking a button feels like the tool didn't finish the job.

But the goal was never to remove the person. It was to remove the boring part of what the person does. Those are different things, and telling them apart is most of what building a good automation actually is.

Most processes are ninety percent gathering, formatting, and moving data around, and ten percent judgment. The ninety percent is machine work. The ten percent, the part where someone looks at a weird case and says "no, not this one," is often the whole reason the process existed in the first place.

Can-be-automated is not the same as should-be

Technically you can automate anything. The real question is what a mistake costs when the machine gets an edge case wrong, and how long it takes anyone to notice.

Send the wrong newsletter to the wrong list? Annoying, forgotten by tomorrow. Send an automated contract termination to the wrong client? Different universe. Approve a payment with no human ever looking at it? A single bad call can cost real money, and you might find out weeks later.

So before we take a person out, we ask one thing: worst case, if this fires wrong, how bad is it and how quietly does it fail? "Not bad, and we'd see it instantly" means we automate straight through. "Bad, and nobody notices for a month" means we build in a human.

Where we almost always keep a person

Over time it's the same three places.

Money going out the door. Payments, credits, discounts, anything that spends or gives away actual cash. A second pair of eyes is nearly always cheaper than the rare expensive slip.

Anything a customer sees with your name on it. An email drafted by a model and sent to a client gets a human check, at least until the model has proven it nails the tone. A chatbot that hallucinates into an internal note does no harm. The same hallucination in a customer reply is a problem.

Anything you can't undo. Deleting records, cancelling contracts, deactivating accounts. Where there's no reverse gear, a person sits in the middle. Not because the machine is usually wrong, but because that one wrong call can't be walked back.

A bad approval step is worse than none

Here's the part people get wrong. The idea of a human checkpoint is fine. The execution is usually where it dies.

Build it as an email with a form nobody reads, and within a week the approver is clicking "approve" on reflex, because they trust the system and they're busy. Now you have a human who's technically in the loop and actually checking nothing. That's worse than no checkpoint, because it feels safe while doing nothing.

A checkpoint that works does three things. It shows the full context right there, so the person doesn't have to open three tabs to understand what they're deciding. It takes one click, ideally where they already are, in Slack or Teams, not in some portal they have to log into. And it only interrupts them when it genuinely needs to.

That last one matters most. If ninety-five percent of cases are obvious, the automation should handle those itself and only escalate the murky five. A person who has to confirm everything becomes the bottleneck you were trying to remove. A person who only sees the exceptions stays sharp.

The trick is teaching the automation when to ask

The best approval step is one that rarely triggers. Sounds backwards, but that's the whole game.

We build the automation to handle the normal case on its own and hand off only when it's unsure. Discount under ten percent, out it goes. Over ten, it asks. Invoice where the numbers reconcile, booked. Numbers that don't add up, onto a human's desk. The system decides the case and, just as importantly, whether it trusts itself on that case.

The share of things that still need a human shrinks over time, because you learn from the exceptions and tighten the rules. It doesn't shrink to zero. It's not supposed to.

The question we ask before pulling the human out

Is the machine doing a calculation here, or making a judgment?

A calculation has a right answer that follows from the data you already have. Let the machine own it. A judgment needs context that usually isn't in the data, it's in the head of someone who knows the business. Leave that with the person, and automate everything around it so the decision is as easy as possible to make.

Full automation is a great target for the path to a decision. For the decision itself, it's often the wrong one. The value isn't replacing the person. It's freeing them from everything that was never a decision in the first place.

If you're not sure which of your processes genuinely need a human checkpoint and which you can safely run end to end, take a look at our free Automations Check. We'll go through them together and mark the spots where a person is worth more than a rule.