Where AI Should Not Make the Decision: Designing Approval and Escalation

The most common mistake in operational automation isn't automating too much — it's treating automation as a single on/off switch instead of a set of specific decisions, each of which needs its own answer to the question: does this need a person? Some parts of a workflow are entirely mechanical. Others involve judgment, relationships, money, or risk that a person should own. Good design treats those differently rather than automating a whole workflow uniformly because the easy 80% of it worked well.

One useful lens is reversibility and stakes. A decision that's easy to undo and low-stakes if wrong — sending a reminder text, logging a request, drafting a first pass at a document — is a reasonable candidate for automation, even with occasional mistakes, because the cost of a mistake is small and correctable. A decision that's hard to undo or carries real consequences if wrong — issuing a refund, committing to a delivery date, telling a customer their issue is resolved when it isn't — needs a person, even if the system could technically generate an answer.

An approval step only works if it's actually usable — a manager who has to read a wall of text to approve a routine action will eventually stop reading and just click approve, which defeats the purpose. Good approval design surfaces exactly what's being decided, why the system is recommending it, and what happens if the person does nothing, in a form that takes seconds to evaluate for the routine case and stands out clearly for the unusual one.

It also needs a default that fails safe. If a decision needs approval and nobody approves it in time, the system should hold, not proceed on its own logic. Silent timeouts that resolve in the system's favor are how trust in an operational system erodes.

Escalation is often treated as an afterthought — "if it's unusual, flag a human" — without specifying which human, how urgently, or what happens if that person is unavailable. A workable escalation path names a specific role (not just "someone"), a maximum acceptable delay, and a fallback if the first person doesn't respond. Without those specifics, escalated issues tend to sit exactly where automation was supposed to prevent things from sitting: in a queue nobody owns.

Every automated action that touches a customer, an employee, or money should leave a record: what happened, when, based on what input, and whether a person reviewed it. This matters for two reasons that are easy to underrate before something goes wrong. First, when a customer disputes something, the business needs to be able to reconstruct what actually happened rather than guessing. Second, a system that can be audited is a system that can be improved — patterns in what gets escalated, overridden, or corrected are the clearest signal for where the rules need adjusting.

It's tempting, especially early on, to automate as much as possible to show fast progress. The better sequence is closer to the opposite: start with a narrow, low-stakes slice, let it run with visible logging and a person still glancing at outputs, and expand the automated scope only as trust is earned and edge cases get discovered. Businesses that automate broadly on day one tend to discover their exceptions the hard way — through a customer complaint or an internal fire drill — instead of through a deliberate review.

The goal isn't to maximize how much a system does on its own. It's to make sure the business can say, clearly and specifically, where a system acts and where a person does — and to make that boundary something the business controls and can move, rather than something buried in a vendor's default settings.