Every support team has escalation rules. Most of them live in somebody’s head, which means they are applied differently on Tuesday than on Friday, differently by the experienced person than the new one, and not at all at eleven at night.
Writing them down sounds like bureaucracy and is actually the opposite: it is what lets you stop deciding. A conversation either matches a rule or it does not, and nobody has to weigh it up while a customer waits.
This covers what a rule actually needs in it, how to decide the list, who owns it, and the four ways a good rule set goes quietly bad. For what should be automated in the first place, see customer support automation.
Key takeaways
- A rule has five parts: trigger, destination, deadline, holding message, and an owner. Most teams write only the first.
- The destination must be a named person or a rota. “The team” is not a destination.
- Every rule needs a fallback, or a conversation routed to someone unavailable just sits.
- Write the holding message in advance – one sentence, what happens and roughly when.
- Review the list by reading a month of escalations and marking each should/should not.
- Greedy keywords are the commonest drift: match on whole words rather than “contains”.
What a Rule Has to Contain
A trigger word on its own is half a rule, and the missing half is the part that makes it work.
A Trigger a Machine Can Evaluate
“When the customer seems frustrated” is not a rule, because two people will read it differently and a flow cannot read it at all. Usable triggers are keywords, a lookup result, a value threshold or a schedule.
Match mode matters more than people expect. Matching on a whole word rather than on the message merely containing the text is the difference between a rule that catches “cancel my order” and one that also catches “cancel my newsletter”.
A Destination With a Name
Routing to “support” means routing to nobody. A rule should name a person, or a rota that names a person per day. The test is whether, at any given moment, you could say out loud who owns the next escalation.
If you cannot, the rule will produce conversations that are marked handled and are not.
A Deadline and a Fallback
How long before this re-escalates, and to whom. Without it, a handoff to someone on holiday is indistinguishable from one that worked – the mechanics of which are in the AI-to-human handoff.
The Sentence the Customer Gets
Write it once, in advance, per rule. A refund escalation and an out-of-hours escalation deserve different wording, and composing either in the moment produces the vague “someone will be in touch” that makes people ask again in three other places.
Deciding What Goes on the List
Shorter than instinct suggests. A long list is usually a sign the flows are wrong rather than that the business is complex.
Start From Harm, Not From Topic
The question is not “is this important” but “what does a wrong automated answer cost here”. A wrong answer about opening hours costs nothing; a wrong answer about a refund costs money and a review.
Sorted that way the list writes itself: money, damage, legal, safeguarding, and anything where the customer has asked for a person.
Add Your Own Three
Every business has edge cases nobody else shares – press enquiries, wholesale, a product with a recall, a region with different rules. Three is usually enough and they are obvious to whoever answers the inbox.
Ask the person who currently handles overflow what they wish never reached a bot. That conversation takes ten minutes and produces a better list than a workshop.
Resist the Long Tail
If the list passes about a dozen rules, something is wrong upstream – usually flows that answer too confidently, so exceptions get patched as escalation rules rather than fixed.
A rule added to work around a bad flow is technical debt with a customer attached.
A Starter Set
Six rules that fit almost any business, with the parts filled in. Copy and adjust rather than starting blank.
| Trigger | Goes to | Holding message says |
|---|---|---|
| Asks for a person, any phrasing | On-duty agent | Putting you through now |
| refund / chargeback / dispute | Named owner for money | Someone will look at this today |
| damaged / broken / missing | On-duty agent | We will sort this – sending it to a person |
| Order value over your threshold | Named owner | Nothing – handle it silently and fast |
| legal / press / safeguarding | Named owner, no rota | We have passed this to the right person |
| No branch matched | On-duty agent | Let me get someone who can help |
Which of these fire most is also a map of what to automate next – the same signal described in DM ticket deflection.
Writing and Keeping the List
An hour to write, twenty minutes a month to keep.
- Ask whoever answers overflow what should never reach a bot. Ten minutes, and a better list than any workshop produces.
- Write each rule with all five parts. Trigger, destination, deadline, holding message, owner. A rule missing one is not finished.
- Name a fallback for every destination. Including for the named owners. People take holidays.
- Put it somewhere the team can read without asking. A document nobody can find is the same as no document.
- Audit monthly by reading, not counting. Mark each escalation should-have or should-not-have. The second pile is your drift.
- Fix greedy keywords first. They are the commonest cause of wrong routing and the cheapest to correct.
Doing It With DMpro
The mechanics available for expressing these rules.
Triggers and Match Modes
DMpro matches keywords on a whole word, on the message containing the text, or on an exact match, with case sensitivity optional. Word matching is the default and the right choice for most escalation rules – “contains” is what produces the greedy-keyword drift above.
A rule can also key on a webhook result, which is how a value threshold works: look the order up, branch on the number.
Deadlines and Fallbacks
A send step can carry an automatic follow-up if nobody answers, from sixty seconds to twenty-four hours, and flows branch on whether a reply arrived. That is the deadline-and-fallback mechanism in practice.
Team seats let you name real owners rather than routing to a shared pile.
What It Cannot Decide for You
Which rules you need. The product can express any rule you write; it has no opinion about your thresholds, and a default list copied from a blog post will be wrong for your business in two places you will not notice for a month.
When the Rules Are the Symptom
Two patterns where more rules is the wrong response.
Escalations Rising With Volume
If escalations grow in step with traffic, the flows are not covering what they should and every new rule is a patch. The fix is upstream: read what is escalating and build the answer.
If they grow faster than traffic, something changed – a product, a delivery partner, a policy – and the inbox found out before the dashboard did.
Everything Routes to One Person
Usually a language or a specialism, and it is a staffing question wearing a rules costume. Language in particular should not be an escalation trigger at all – multilingual customer support covers the alternatives.
If it is genuine specialism, the rota needs a second name on it before that person takes leave.
Nobody Reads the Holding Message
If customers consistently re-ask after an escalation, the holding message is not doing its job – usually because it promises “soon” instead of a number. Expectations are covered properly in social media response time.
Where This Connects
Three places the rule set touches the rest of the operation.
To the Numbers
Escalation volume and escalation reasons are two of the five numbers worth putting on a dashboard, and they are the two that tell you what to build next rather than how you did – customer support KPIs covers the full set.
Rules that never fire should be retired; rules that fire constantly are flows waiting to be built.
To the Clock
Every rule implies a response commitment, and overnight is where commitments go to die. Decide what the out-of-hours version of each rule is before you publish any hours – after-hours DM support covers the four honest models.
To the Tooling Decision
Once rules have owners, deadlines and fallbacks, you are describing assignment – and at some volume a shared inbox stops being able to express it. That threshold is the subject of shared inbox vs helpdesk.
The warning sign is the same one as everywhere else in this cluster: escalations sitting overnight because nobody was named.
Stop Deciding, Start Routing
An escalation rule that lives in someone’s head is applied differently on Friday than on Tuesday, and not at all overnight. Written down, it is just routing.
DMpro expresses the rules as triggers with real destinations, automatic deadlines and a fallback – and hands the whole conversation over so whoever picks it up already knows what happened.
Conclusion
Escalation rules are worth writing down for one reason: they let you stop deciding. A conversation matches or it does not, and nobody weighs it up while a customer waits.
Give each rule five parts – trigger, destination, deadline, holding message, owner – and a fallback for when the destination is unavailable. Six rules covers most businesses; past a dozen, the flows upstream are the real problem.
Then audit by reading rather than counting. A month of escalations marked should-have or should-not-have will show you more than any report, and the should-not-have pile is almost always a keyword matching too greedily.
Frequently asked questions
What should always be escalated to a human?
Money, damage, legal and safeguarding matters, anything over a value threshold you set, and any message where the customer has asked for a person. Plus a catch-all for anything no branch matched.
What makes a good escalation trigger?
Something a machine can evaluate identically twice: a keyword, a lookup result, a value threshold or a schedule. “When the customer seems frustrated” is not a rule.
Why does my escalation rule catch the wrong messages?
Almost always a greedy keyword. Matching on the message merely containing the text catches “cancel my newsletter” with a rule meant for “cancel my order”. Match on whole words instead.
Who should an escalation route to?
A named person or a rota that names someone per day, never “the team”. And every destination needs a fallback, or a conversation routed to someone on holiday simply sits.
How many escalation rules should we have?
Around six covers most businesses. Past a dozen, the list is usually patching flows that answer too confidently – fix those instead of adding rules.
How often should the rules be reviewed?
Monthly, by reading a month of escalations and marking each one should-have-escalated or should-not-have. The second pile is your drift, and it takes about twenty minutes.
