Lesson 5.2Lesson 26 of 30
Escalation and ambiguity
Design effective escalation and ambiguity resolution patterns
Key points
- 1Escalate on three triggers: the customer asks for a human, the policy is silent or the request needs an exception (e.g. matching a competitor's price), or the agent cannot make meaningful progress.
- 2An explicit request for a human is honoured at once, without investigating first. A frustrated customer with a simple issue gets an acknowledgement and an offer to fix it now; if they repeat that they want a person, escalate.
- 3Sentiment and the model's self-reported confidence are poor proxies for complexity: an angry customer may have a trivial issue, a polite one a policy exception, and the model can be confidently wrong.
- 4
get_customerreturns several matches? Ask for another identifier (order number, billing postcode). Never pick one by a heuristic such as the most recent account. - 5Put explicit escalation criteria in the system prompt, with few-shot examples showing when to escalate and when to resolve autonomously, including borderline cases and the reasoning.
What the exam guide checks here
Objective wording from the exam guide (English).
- 5.2.K1Escalate on: request for a human, policy exception or gap, no meaningful progress
- 5.2.K2Escalate at once on explicit demand vs offer resolution when the issue is simple
- 5.2.K3Sentiment and self-reported confidence are poor proxies for complexity
- 5.2.K4Multiple customer matches need more identifiers, not heuristic choice
- 5.2.S1Explicit escalation criteria with few-shot examples in the system prompt
- 5.2.S2Honour explicit requests for a human immediately, without investigating first
- 5.2.S3Acknowledge frustration, offer resolution, escalate if the customer repeats the request
- 5.2.S4Escalate when policy is ambiguous or silent (competitor price match)
- 5.2.S5Ask for extra identifiers on multiple matches
Lock it in
Answer scenario questions on this topic. Every option comes with an explanation.
Practise 5.2 · 23 questions