x
An escalation rule is one written sentence answering: what does this system do when it doesn't know? You write it before you build anything, because it's the only part that determines whether the automation is safe — and the only part everyone skips.
Automations rarely fail in the middle. The middle is the easy case: the expected question, the standard reply, the thing you tested. They fail at the edge — the ambiguous request, the angry customer, the question that looks like one you handle but isn't. And at the edge, a system without an escalation rule does the most damage available to it, which is to answer confidently.
Twenty minutes, written down, before the build. That's the whole method.
Four lines. Each takes about five minutes and forces a decision you'd otherwise make badly under pressure.
Line 1 — The trigger. What does "doesn't know" actually look like here? Be specific and observable. Not "when it's unsure" — a system's confidence is not a reliable signal. Better: "any message mentioning a refund, a complaint, a deadline, or a number I haven't already published." Trigger on the topic, not on the machine's self-assessment.
Line 2 — The action. What happens on trigger? The good options are narrow: stop and hand to a human, or reply with a fixed acknowledgement that promises nothing. The bad option is "try its best," which is the default if you don't write this line.
Line 3 — The message. What the person actually receives. Write it now, in your voice, while you're calm. "That one needs me — I'll come back to you by Thursday." Written in the moment, this sentence tends to over-promise.
Line 4 — The tell. How do you find out it triggered? An email to yourself, a flag in a sheet, anything. An escalation you never learn about is just a slower failure. This line is the one most often left off, and it's the one that turns the whole thing into something you can improve.
Take the holiday autoresponder from yesterday's post. Its rule might read:
Trigger: any message containing a price, a date, a complaint, or the words urgent / legal / cancel. Action: no automated answer; hold. Message: "This is an automated reply. Your message needs me personally — I'm back on the 11th and will reply that day." Tell: forward to a folder I check once daily.
Four lines. It took less time to write than reading this section, and it converts the automation from a thing that might embarrass you into a thing with a known failure mode. That is the entire difference between an automation you can leave running and one you have to watch.
Notice what it doesn't try to do. It doesn't attempt to judge whether the complaint is serious or the deadline is real. Judgement is exactly what you're not delegating — a point worth sitting with, because it's the same reason politeness isn't accuracy.
Here's the checkable claim: every control framework worth the name puts the exception path before the happy path. Aviation checklists, clinical protocols, financial approval limits — all of them are, structurally, escalation rules. None of them describe what to do when things go well, because nobody needs telling.
Business automation inverted this, largely because the demos are all happy-path. You watch a tool answer a customer beautifully and start building, and the exception handling becomes something you'll "add later." Later arrives as an incident.
The other reason to write it first is that it changes what you build. A system with a defined boundary is a smaller, simpler system. You stop trying to make it handle everything, because you've already decided it won't — and the version that handles four things reliably beats the version that handles fourteen unpredictably. This is the same compression that makes five boring automations outperform one ambitious one.
Every time you're about to switch something on — an autoresponder, a scheduled report, an agent with access to a folder — stop and write the four lines. If you can't, you don't understand the automation well enough to run it unattended yet. That's useful information, arriving cheaply.
If you want the prompt set that runs these decisions end to end, the free 5-min read is here: 7 AI Prompts That Run a One-Person Business.
Related Decodes
TL;DR: An escalation rule is one written sentence answering what your automation does when it doesn't know — and it should be written before you build, not after something goes wrong. Use four lines: the trigger (topic-based, not confidence-based), the action (stop and hand over), the message (written calmly, promising nothing), and the tell (how you find out it fired). Twenty minutes at the start replaces an afternoon of damage control later.
