The most consequential document in an AI BDC deployment is the one describing what the system must not do, and in most stores it does not exist as a document at all. It is a configuration screen somebody filled in once — which means it records what a person imagined rather than what customers actually say.
This guide covers why it should be a document, the template structure, how it gets revised, who owns it, where it fails, and what to measure.
Why a document rather than a setting?
Because a setting has no owner, no version and no history, and this particular list needs all three.
It is a commercial decision, not a technical one. What the system may say about price is a question for whoever is accountable for the store, not for whoever configured the platform.
It changes. Customers phrase things in ways nobody anticipated, and the list that worked in month one is incomplete by month two.
It has to be auditable. When something goes wrong, the question is what the rule was at the time, and a configuration screen shows the current state rather than the state on the day in question.
It outlives the vendor. Switch platforms and the list should transfer. A configuration does not.
The template
Escalation rules — structure
Section Contains Owner and version A named person, a version number, a date Hard triggers Conditions on which the system always stops. Enumerated Trigger patterns The actual phrasings customers use, per trigger Behaviour on trigger What it says, and to whom it hands Handoff payload The four or five items the transfer must carry Out-of-hours behaviour What happens when the trigger fires at 11pm Review log Date, who reviewed, what changed, why The third section is the one that separates a working document from a wish list. "Price questions" is a category; "how much is it", "whats ur best price", "what would my payment be", "can you do any better" is a trigger pattern, and only the second kind can be implemented.
The sixth section is the one everybody forgets. A complaint at 11pm cannot be transferred to anyone, and the rule has to say what happens instead.
The triggers themselves
Twelve or so, in three groups — the same structure as in voice transfer rules, and it holds across channels because the boundary is about commitment and judgment rather than about medium.
Commitment: price, payment, trade value, payoff, availability it cannot verify, delivery dates, discounts.
Judgment: complaints, legal mentions, safety concerns, hardship, disputes about something previously said.
Capability: repeated failure to understand, explicit request for a person.
What belongs in your document and not in a generic one is the phrasing, drawn from your own transcripts, and the out-of-hours behaviour, which depends on who you have.
How does it get revised?
From transcripts, on a schedule, by a named person.
Week 1–4: weekly. Read every escalation and a sample of non-escalations. The non-escalations are where the misses hide — a price question the system answered will not appear in the escalation log.
Month 2–3: fortnightly. The rate of new patterns falls quickly.
Ongoing: monthly, folded into the call and thread QA that should be running anyway.
Every revision gets a line in the review log: date, reviewer, what changed, and the transcript that prompted it. That log is the most valuable part of the document after a year, because it is the record of how customers actually behave at your store.
Who owns it?
A named person with commercial authority, not the vendor and not whoever configured the platform.
In practice this is the GM at a single store or the operations lead in a group. The test is simple: the owner is whoever would have to unwind a commitment the system made. If that person has not read the document, nobody meaningful has approved it.
Where does it fail?
1. It does not exist. The overwhelming default. The rules live in a configuration screen.
2. Categories without phrasings. Unimplementable, and it produces a false sense of coverage.
3. Written once. The list from month one is incomplete by month two, guaranteed.
4. Reviewed only on escalations. The misses are in the calls and threads that did not escalate.
5. No out-of-hours rule. The hardest case, left undefined, which means the system improvises at the worst moment.
6. Implemented as instructions. The document can be perfect and still fail if the triggers are advisory rather than capability limits — the enforcement question in agent autonomy.
7. No owner. Which means no approval, and no one to revise it — and the transcripts it should be revised from come from the staged source rollout. The tasks it governs are inventoried in the automated BDC.
What should you measure?
| Metric | How to compute | What it tells you |
|---|---|---|
| Escalation accuracy | Triggers that fired ÷ should have, from transcripts | Whether the list is complete |
| Missed triggers per review | New patterns found, per session | Should fall over time, never to zero |
| Commitment violations | System said something binding | Should be structurally zero |
| Days since last revision | From the review log | Over 60 means nobody is reading |
| Out-of-hours escalations handled | Promised callbacks actually made | The hardest case |
| Document version age | Versions in the last quarter | A static document is an unread one |
Row two is the health check. A review that finds no new patterns in the first month means the review is not happening properly, because customers reliably produce phrasings nobody anticipated.
Row three should be zero by construction. If it is not, the problem is enforcement rather than the document.
Frequently asked questions
What are AI BDC escalation rules?
The enumerated conditions on which the system stops and hands to a person, together with the phrasings customers actually use for each, what the system says when it escalates, what the handoff carries, and what happens when a trigger fires outside staffed hours.
Why should escalation rules be a document rather than a setting?
Because they are a commercial decision with an owner, they change as customers reveal new phrasings, they need to be auditable after the fact, and they should survive a change of vendor. A configuration screen has no owner, no version and no history.
What is the difference between a category and a trigger pattern?
A category is "price questions". A trigger pattern is the actual set of phrasings — how much is it, what is your best price, what would my payment be, can you do any better. Only the second can be implemented, and only the second comes from reading real transcripts.
How often should the list be revised?
Weekly for the first month, fortnightly through months two and three, then monthly folded into regular quality review. Every revision gets a log entry recording the date, the reviewer, what changed and the transcript that prompted it.
Why review non-escalations too?
Because the misses are there. A price question the system answered instead of escalating never appears in the escalation log, so reviewing only escalations systematically hides exactly the failures the review exists to find.
Who should own the escalation document?
Whoever would have to unwind a commitment the system made — typically the GM at a single store or the operations lead in a group. If that person has not read it, nobody with authority has approved what the system is allowed to say.
What happens when a trigger fires after hours?
That has to be written down, because it is the hardest case and the one most often left undefined. With nobody to transfer to, the workable behaviour is taking complete details, stating clearly when someone will respond, and ensuring that actually happens.
Can a good document still fail?
Yes, if the triggers are implemented as instructions rather than as capability limits. A perfect list enforced advisorily will be followed most of the time and will fail at exactly the moment it matters, which is why enforcement is an architectural question.
Conclusion
- A document with an owner, a version and a review log — not a configuration screen.
- Phrasings, not categories. Only the first kind can be implemented.
- Revise from transcripts weekly for a month, and read the non-escalations.
- The owner is whoever would unwind the commitment. If they have not read it, nobody approved it.
- Write the out-of-hours rule. It is the hardest case and the one left blank.
Last updated: