Bad Clarification Behavior
Agent asks unnecessary questions or misses critical clarifications.
Conversation Resolution
12 patterns for this goal
Conversation resolution fails when a support agent selects a canned response matching the customer’s topic but wrong for their account state, asks repeated questions the customer already answered, escalates before attempting a solvable request, or fails to detect and adjust to escalating customer frustration. Unlike general conversation-quality failures that are about tone and state tracking, resolution-specific failures concentrate on support-domain concerns: whether the right canned response was selected for this customer’s tier, whether the escalation threshold was calibrated correctly, whether basic support-conversation mechanics (asking once, listening to frustration signals) are working.
Key Takeaways
- 12 patterns are documented, grouped into canned-response selection failures (1), clarification and questioning failures (3), escalation timing failures (2), and tone/de-escalation failures (4), plus 2 multi-agent handoff failures.
- Embedding-retrieval-selects-similar-but-wrong-canned-response shows that canned-response libraries contain responses for similar-but-distinct scenarios (different plan tiers, different bug fixes, different preconditions), and retrieval by text similarity alone ranks the wrong response first because of topical overlap, not account-state match.
- Bad-clarification-behavior, repeated-question-loop, and escalation-too-early together show the ask-vs-act and escalation-threshold calibration problems are as severe in support as in general conversation quality, but with domain-specific consequences (asking too much or too little on account details, escalating too early on solvable requests).
- Multi-agent handoff failures are concentrated in conversation-resolution: multi-agent-handoff-drops-de-escalation-context shows triage agents gather context and detect frustration, but that context doesn’t reach downstream specialized agents because the handoff schema has no field for it.
Scope
- Canned-Response Selection — embedding-retrieval-selects-similar-but-wrong-canned-response. Retrieval by text similarity ranks a topically-similar but precondition-wrong response above the correct one.
- Clarification and Information Gathering — bad-clarification-behavior, repeated-question-loop, unclear-next-step. All three involve asking too much, asking redundantly, or leaving the customer without a clear next action.
- Escalation Timing and Quality — escalation-too-early, poor-escalation. One is escalating before attempting a solvable request; the other is escalating but without clear handoff context so the escalation itself fails.
- Tone and Emotional State — tone-mismatch, over-apology-loop, user-frustration-escalation, conversation-mood-whiplash. All four involve register/emotional tone, but applied to support-specific scenarios (apologizing instead of solving, missing escalating frustration).
- Multi-Agent Handoff — multi-agent-handoff-drops-de-escalation-context-between-triage-and-billing-agent, bad-refusal, false-completion-claim, inconsistent-answers.
When Conversation Resolution Matters
- Hybrid human-AI support systems where AI handles triage and straightforward requests, with escalation to humans for complex issues, requiring accurate escalation thresholds and quality handoffs
- Support queues with template-based canned responses indexed by topic, where retrieval-ranking mismatches can send a customer to a response written for a different account tier or bug fix
- Long customer-service sessions where emotional state (frustration, anger) changes across turns, requiring real-time sentiment detection and de-escalation response patterns
Cross-Pattern Insight
Support conversation-resolution failures are the same underlying problems as general conversation-quality failures (state tracking, clarification calibration, tone), but applied to support-specific mechanics. The added dimension is that support agents operate under structural constraints: they have canned-response libraries (which must be selected by account state, not just topic), escalation thresholds (which must be calibrated to route solvable requests to bot and hard requests to human), and handoff schemas (which must carry de-escalation context and customer frustration state, not just a ticket category). The recurring mitigation across all patterns is making context explicit: account-state metadata for response selection, escalation-attempt counters for threshold-setting, and structured handoff fields for de-escalation notes and prior partial resolutions already issued.
Frequently Asked Questions
How do you select the correct canned response when multiple responses are topically similar?
Embedding retrieval selects similar-but-wrong canned response shows pure text-similarity ranking can fail when the canned-response library contains responses for similar-but-distinct scenarios. The fix is to pre-filter the candidate set by account-state metadata (plan tier, region, prior ticket history) before applying embedding-similarity ranking, so a precondition-wrong response cannot outrank a precondition-correct one on pure text similarity.
If a customer has escalating frustration signals, what should the agent do?
User frustration escalation documents that agents often fail to detect escalating frustration or continue with the same approach that caused it. The fix is real-time sentiment tracking, explicit acknowledgment of detected frustration, and a forced change in response strategy (different question, different assumption, escalation to human) when frustration is rising. The most common mistake is apologizing repeatedly without changing approach.
What is the difference between “escalation too early” and “poor escalation”?
Escalation too early is refusing a solvable request without attempting it. Poor escalation is escalating the conversation, but without clear handoff context, so the human agent has to re-ask everything the bot already gathered. Both are escalation-related failures but at different points in the flow.
Should a support agent verify a completion claim with a tool call, or assume it worked?
False completion claim documents that agents often claim an action was completed (refund issued, setting changed) without checking that the action actually persisted. For critical actions, a verification call (re-fetch the account status) before claiming done is required. Completion claims without tool-proof are a documented failure.
Patterns
| Pattern | Mechanism |
|---|---|
| Embedding-Retrieval Selects Similar But Wrong Canned Response | Response selected by topic similarity doesn’t match customer’s account state or preconditions |
| Bad Clarification Behavior | Asks unnecessary questions or misses critical clarifications |
| Repeated Question Loop | Asks for information already provided earlier in the conversation |
| Escalation Too Early | Escalates a solvable request without attempting resolution |
| Poor Escalation | Escalates but without clear handoff context, forcing human agent to re-gather information |
| Tone Mismatch | Register (formal, casual, empathetic) doesn’t match the context or customer’s own tone |
| Over-Apology Loop | Apologizes repeatedly without changing approach or solving the problem |
| User Frustration Escalation | Fails to detect and adjust to customer’s escalating frustration across turns |
| Conversation Mood Whiplash | Emotional tone swings sharply between adjacent turns without justification |
| False Completion Claim | Claims an action was completed without tool proof it actually persisted |
| Inconsistent Answers | Gives contradictory answers to the same policy or fact question across turns |
| Multi-Agent Handoff Drops De-Escalation Context | Frustration level and already-gathered details are lost when conversation is routed from triage to specialized downstream agent |
| Bad Refusal | Refuses safe requests or gives unsafe help due to calibration failure in safety classifier |
| Unclear Next Step | Customer doesn’t know what happens next after agent’s response |
Total: 12 patterns
Related Goals
- Proactive Retention Outreach — proactive agent reaching out to at-risk customers, versus reactive support handling inbound requests
- Refund and Billing Disputes — specialized domain for financial-risk resolution, applying general conversation-resolution principles to billing-specific scenarios
- Conversation Quality — general conversation quality failures that apply across all use cases, not just support
Bad Refusal
Agent refuses safe requests or gives unsafe help.
Embedding Retrieval Selects Similar but Wrong Canned Response
A Support Agent That Selects a Canned Response or Macro From a Library Via Semantic/Embedding Similarity to the Customer's Message, Rather Than by Matching the Customer's Actual Account State or Issue Category, Retrieves a Response That Is Lexically and Topically Close to What the Customer Wrote but Answers a Different Underlying Situation -- Sending Confident, On-Topic-Sounding Guidance That Does Not Actually Apply to the Customer's Case
Escalation Too Early
Agent gives up despite solvable request.
False Completion Claim
Agent says done when action was not completed.
Inconsistent Answers
Agent gives different answers across turns.
Multi-Agent Handoff Drops De-Escalation Context Between Triage and Billing Agent
A Triage Agent That Determines a Customer Is Already Frustrated and Has Explicitly Requested Not to Repeat Their Account Details Again Records That Context Only in Its Own Conversational Reasoning, and When the Conversation Is Routed to a Downstream Specialized Billing Agent That Operates on a Structured Ticket Object Containing Only the Stated Issue Category, the De-Escalation Context and Already-Provided Details Never Cross the Handoff Boundary, So the Billing Agent Re-Opens the Conversation by Asking the Customer to Re-Authenticate and Re-Explain Everything From Scratch
Over-Apology Loop
Agent apologizes repeatedly without solving.
Poor Escalation
Agent fails to hand off to a human at the right time.
Repeated Question Loop
Agent asks for information already provided.
Tone Mismatch
Agent sounds rude, robotic, too casual, or too formal.
Unclear Next Step
User does not know what happens next.