Generator
Escalation Runbook Generator
Handoff is usually specified as a button and nothing else. The runbook is the part that decides whether the visitor is helped: what fires it, who receives it, what they can see, and what the visitor was promised while they wait.
- Triggers, not intentionsConditions that can fire
- Names the receiverA rota, not “the team”
- Sets the promiseWhat the visitor was told
Work it out
Your numbers
Your system prompt
A runbook that promises a response time you cannot hit is worse than one that promises a slower time you always hit.
What the numbers mean
A trigger must be a condition, not an aspiration
“Escalate when the visitor is frustrated” cannot fire. “Escalate when the visitor asks twice and it is unresolved” can. Write conditions the system can evaluate.
Send the transcript, not a summary
The detail that caused the escalation is usually the detail a summary drops. The person picking it up should never have to ask the visitor to start again.
Name an owner per shift
Escalations sent to a shared inbox with no named owner are the ones that sit for two days. A rota is the whole difference between a runbook and a wish.
Repeated escalations on one topic are a writing task
If the same question escalates every week, no amount of staffing fixes it. Write the page, index it, and the trigger stops firing.
Questions
It is shorter for a small team, not unnecessary. One person still needs to know what fires a handoff and what the visitor was promised while they wait.
Then promise the one you can hit and say it plainly. A widget that says “we reply next working day” and does is more trusted than one that promises an hour and does not.
Once. If the visitor asks for a person, hand off immediately — arguing with someone who has asked for a human is the fastest way to lose them.
Want this run against your actual site?
Tell us the page your assistant lives on and the questions you care about. A person runs them and sends back the raw answers.