Frequency:Common
Category:
Ticket-Routing Agent Determines Which Product Line a Ticket Belongs to Based on Whatever Product Name Was Most Recently Mentioned in the Conversation, Rather Than Querying the Customer's Actual Purchase/Entitlement Record
Frequency:Common
Category:
When a Single Ticket Contains Multiple Distinct Requests, the Routing Agent Classifies and Routes on the First or Most Prominent Intent Only, Silently Failing to Route or Flag a Secondary Issue Mentioned Later in the Same Message
Frequency:Common
Category:
Self-Service Deflection Agent Generates a Fluent, Assertive Answer From a Weakly-Matched Retrieved Article, Instead of Hedging or Routing to a Human When the Retrieval Similarity Score Is Low
Frequency:Common
Category:
When a Single Customer Message Contains Several Distinct Issues of Varying Severity, the Sentiment-Escalation Agent Scores Overall Message Sentiment as a Blend, Diluting a Severe Complaint That Would Have Triggered Escalation on Its Own
Frequency:Very Common
Category:
Agent Closes a Support Ticket as Resolved Because the Customer's Reply Contains a Polite Closing Phrase ("Thanks," "OK," "Got it"), Without Verifying the Underlying Problem Was Actually Fixed
Frequency:Very Common
Category:
Agent Selects a Templated/Canned Response That Matches Surface Keywords but Misses the Customer's Actual Situation
Frequency:Very Common
Category:
Self-Service Deflection Agent Keeps Offering the Same or Similar Automated Suggestions Without Recognizing the Customer Needs Human Escalation
Frequency:Common
Category:
Self-Service Deflection Agent Routes a Customer Through a Closed Loop of FAQ Articles That Each Point Back to One Another, Never Reaching a Resolution or a Human Handoff
Frequency:Very Common
Category:
Self-Service Agent Marks a Conversation as "Deflected" (Resolved Without Human Agent) Based on the Customer Not Replying, Rather Than the Issue Actually Being Resolved
Frequency:Common
Category:
An SLA-Management Agent's RAG Step, Used to Retrieve the Applicable Response-Time and Resolution-Time Commitments for an Incoming Ticket Based on the Customer Account's Description, Pulls a Lexically Similar but Wrong-Tier SLA Policy Document, Causing the Agent to Apply Incorrect Commitment Clocks to the Ticket
Frequency:Frequent
Category:
A Ticket-Routing Agent That Classifies an Incoming Ticket's Product Category by Embedding Similarity Against a Product-Taxonomy Description Index, Rather Than Against the Account's Actual Provisioned Product List, Matches the Ticket to a Superficially Similar but Incorrect Product Line, Routing It to a Specialist Queue That Cannot Resolve the Customer's Actual Issue
Frequency:Occasional
Category:
A Sentiment-Escalation Agent That Selects an Escalation Playbook by Embedding Similarity Against a Playbook-Description Index, Rather Than Against the Structured Severity Tier the Conversation Actually Belongs To, Matches the Conversation to a Superficially Similar but Wrong Playbook, Routing It Through an Escalation Path That Does Not Match the Actual Risk Level
Frequency:Common
Category:
A Self-Service Deflection Agent's RAG Step, Used to Suggest a Help Article to Resolve a Customer's Question Without Human Involvement, Retrieves a Lexically and Semantically Similar but Deprecated or Product-Version-Mismatched Article Instead of the Current Correct One, Deflecting the Customer With Stale Instructions Framed as the Solution
Frequency:Common
Category:
Support Ticket Routing Model Routes Complex Issues to Tier-1 (Auto-Response); Requires Escalation After Wasted Time
Frequency:Very Common
Category:
Support Agent Uses Outdated Knowledge Base; Gives Customers Incorrect or Outdated Information
Frequency:Common
Category:
Agent Routes a Support Ticket Based on Detected Content Language Without Verifying Agent Team Language Coverage, Sending Non-English Tickets to English-Only Queues
Frequency:Very Common
Category:
Agent Selects a Pre-Written Macro/Canned Response Based on Surface Keyword Match Without Verifying It Actually Addresses the Customer's Specific Situation
Frequency:Occasional
Category:
A Routing Agent That Re-Runs Full-Context Intent Classification on Every New Customer Message Silently Reassigns a Ticket Already Claimed and Being Worked by a Human Agent, Because Growing Conversation Context Shifts the Classification Output Without Any Check on the Ticket's Current Ownership State
Frequency:Occasional
Category:
An Intake Bot That Learns, During a Support Conversation, That a Customer Has a Negotiated SLA Override -- For Example, an Extended Response-Time Allowance Granted as Part of a Contract Renegotiation -- Records That Override Only in Its Conversation Summary, and a Downstream Billing or SLA-Compliance Agent That Calculates Breach Penalties From a Structured Account Field Never Receives the Override, Applying the Standard SLA Instead
Frequency:Occasional
Category:
A Sentiment-Classification Agent That Concludes, in Its Own Analysis, That a Ticket's Tone Indicates a High Risk of Customer Churn or Public Complaint Hands the Ticket Off to a Routing Agent Through a Structured Sentiment-Score Field That Falls Within the Routing Agent's Normal Range, So the Specific Escalation Reasoning the Classifier Reached Never Translates Into Priority Routing
Frequency:Common
Category:
An Intake Bot Hands Off a Conversation to a Specialist Deflection Agent Using a Structured Intent Label, but the Free-Text Detail That the Customer Already Attempted and Failed at the Standard Self-Service Step Is Not Part of That Structured Schema, So the Specialist Agent Re-Suggests the Same Failed Step
Frequency:Common
Category:
A Bot-Tier Support Agent's Chat Transcript With a Customer Shows the Customer Already Tried Two Specific Troubleshooting Steps Without Success, but the Structured Ticket-Summary Payload the Bot Hands Off to the Human-Agent Queue Does Not Carry That Field, So the Human Agent Re-Suggests One of the Same Already-Tried Fixes
Frequency:Occasional
Category:
A Triage Bot Determines a Customer's VIP/Enterprise Status From a Free-Text Account-Notes Lookup, but the Structured Ticket Object It Hands Off to the Routing Agent Has No Field for That Status, So the Routing Agent Sends the Ticket to the Standard Queue Instead of the Premium Queue
Frequency:Occasional
Category:
Agent's Ticket Priority Classifier Is Exploited by Customers Who Learn Which Language Patterns Trigger High-Priority Routing, Degrading the Classifier's Usefulness Over Time
Frequency:Very Common
Category:
Agent Resolves Each Support Contact From a Customer in Isolation, Failing to Recognize That the Same Underlying Issue Has Been "Resolved" Multiple Times Without Actually Being Fixed
Frequency:Occasional
Category:
Sentiment-Escalation Agent Classifies Sarcastic or Passive-Aggressive Customer Messages as Positive, Suppressing an Escalation That Should Have Triggered
Frequency:Common
Category:
Agent's Sentiment Classifier Mislabels Controlled, Formally-Worded but Highly Escalated Customer Language as Neutral, Delaying Human Escalation
Frequency:Occasional
Category:
When Generating a Customer-Facing Explanation for a Missed SLA, the Agent Produces a Plausible-Sounding Root-Cause Narrative It Was Never Given Rather Than Querying the Incident-Tracking System for the Actual Logged Cause
Frequency:Common
Category:
Agent Incorrectly Pauses or Resumes the SLA Response-Time Clock When a Ticket Status Changes, Masking an Actual SLA Breach
Frequency:Occasional
Category:
A Sentiment-Escalation Agent's Free-Text Justification for Why a Ticket Is Being Escalated (Or Not) Invents a Plausible-Sounding Causal Explanation Linking Two Merely Co-Occurring Elements of the Conversation, and That Invented Explanation Is Adopted by Support Managers as a Real Triggering Rule Rather Than Recognized as the Model's Own Rationalization
Frequency:Occasional
Category:
An Issue-Resolution Agent Authorized to Auto-Process Refunds Executes the Refund Directly Off the Customer's Narrated Claim Without Calling the Ledger-Verification Tool It Has Access To, Because the Claim's Phrasing Matches a Known-Resolvable Template
Support-services agents fail across five distinct workflows — ticket routing, sentiment escalation, SLA management, self-service deflection, and issue resolution — and the failure mechanisms span a broader landscape than insurance workflows because support-services systems are more algorithmically diverse. Retrieval-based mismatches recur (embedding-similarity taxonomy matching, deprecated-article retrieval), multi-agent handoff losses recur (prior-attempt loss, VIP-tier loss, SLA-override loss), and stale-parametric-knowledge overrides recur, but support-services also documents distinctly different patterns: measurement gaming (priority inflation), stateless reclassification (mid-conversation ticket reassignment), and silent resolution counting (false deflections). The three mechanisms that dominate insurance workflows still appear here, but they account for only half of support-services patterns; the other half documents failures in measurement-system design, orchestration-layer statefulness, and agent-output transparency. The distinction between support-services and insurance failure patterns matters because it suggests that support-services agent failures, while more diverse, are also more addressable through non-architectural means (metric redesign, improved visibility) alongside structural fixes.
Key Takeaways
- 5 goals and 26 patterns total are documented: ticket routing (6), sentiment escalation (5), SLA management (4), self-service deflection (5), issue resolution (6).
- The three mechanisms that dominate insurance workflows (retrieval mismatch, handoff loss, stale-parametric-knowledge) appear in support-services, but account for only 13 of 26 patterns; the other 13 patterns span measurement gaming, stateless reclassification, false-resolution counting, tonal-incongruity blindness, and hallucinated-rationale substitution.
- Retrieval-mismatch patterns appear in ticket routing (provisioning verification, product-line mismatch), sentiment escalation (playbook-selection mismatch), and SLA management (tier-document mismatch), but differ slightly because they mix domain-specific verification (provisioning records, structured risk tiers) rather than regulatory tools.
- Multi-agent-handoff patterns appear in 4 of 5 support-services goals (all except sentiment escalation), and handoff schemas consistently omit task-relevant context (prior attempts, VIP status, SLA overrides, specialist-attempted remedies).
- Stale-parametric-knowledge overrides appear less frequently in support-services (sarcasm misreading, formal-language blindness) compared to insurance, because support-services data is less often “jurisdiction-specific or actively maintained” compared to insurance regulatory data.
Support-Services Goals
| Goal | Coverage | Patterns | Primary Mechanisms |
|---|
| Ticket Routing (GitHub) | Product classification, effort estimation, language matching, ownership state | 6 | Retrieval mismatch, handoff loss, mid-conversation reclassification, priority gaming |
| Sentiment Escalation (GitHub) | Playbook selection, risk-signal compression, sarcasm detection, formal-language blindness | 5 | Retrieval mismatch, handoff compression, tonal incongruity, content-risk blindness, hallucinated rationale |
| SLA Management (GitHub) | Tier document selection, override propagation, breach-cause grounding, clock-pause logic | 4 | Retrieval mismatch, handoff loss, hallucinated cause, status-field clock error |
| Self-Service Deflection (GitHub) | FAQ loop topology, failed-attempt escalation, resolution confirmation, KB currency | 5 | Failed-attempt blindness, circular-redirect topology, false-resolution counting, KB staleness, handoff loss |
| Issue Resolution (GitHub) | Macro application, handoff loss, repeat-contact blindness, autonomous refund verification, KB staleness | 6 | Macro misapplication, handoff loss, repeat-contact blindness, unverified autonomous action, KB staleness |
Total: 26 patterns
How the Goals Relate
The five support-services goals form a rough pipeline, but with significant orthogonality. Ticket routing classifies and directs incoming tickets. Sentiment escalation may re-route tickets or change handling priority based on customer tone/risk. SLA management tracks response-time compliance. Self-service deflection attempts to resolve issues without human involvement. Issue resolution handles escalated or unresolved cases. However, sentiment escalation and SLA management are also orthogonal concerns that cross-cut routing and issue resolution: a routed ticket may have its escalation priority changed by sentiment, and SLA compliance applies to any ticket regardless of resolution stage. The handoff patterns are remarkably consistent across goals: whenever structured schemas narrow between stages, task-relevant context (prior attempts, VIP status, overrides, specialist recommendations) disappears. The measurement-design patterns are also consistent: per-ticket metrics (deflection success, closure rate, priority) mask cross-ticket patterns (false deflections, repeat contact, priority gaming) until explicitly tracked in parallel.
Frequently Asked Questions
What makes support-services failure patterns more diverse than insurance patterns?
Insurance workflows are more standardized and domain-specific (claims adjudication, fraud detection, underwriting) with consistent handoff points and similar data types. Support-services workflows span multiple business models (deflection-focused cost reduction vs. full-resolution quality), multiple algorithm types (routing classifiers, sentiment models, knowledge retrieval), and customers who interact with multiple stages, creating more failure surface. Additionally, support-services systems are more likely to be gamed by customers (priority inflation) or to have measurement-design issues (false deflections) that don’t arise in insurance.
Do the three insurance mechanisms (retrieval, handoff, stale-corpus) appear equally in support-services?
No. Retrieval mismatch appears consistently (6 instances). Handoff loss appears frequently (in 4 of 5 goals, 9 instances total). Stale-parametric-knowledge appears infrequently (2 instances: sarcasm misreading, formal-language blindness). The other 9 patterns are support-services-specific: measurement gaming, stateless reclassification, resolution-confirmation design, KB staleness, macro misapplication, repeat-contact blindness, unverified refunds, hallucinated rationales, and priority gaming.
Which pattern most directly causes customer dissatisfaction in support?
The repeat-contact-loop (issue-resolution goal) and chatbot-loop-without-escalation (self-service-deflection goal) patterns are most directly cited by customers as frustrating, because they extend resolution time and force customers to re-explain their issue multiple times. Mid-conversation reclassification (ticket-routing goal) also directly frustrates customers by resetting context and losing agent progress.
How do you fix support-services failures without architectural changes?
Several patterns are measurable and correctable without code changes: dual-metric reporting (deflection rate + cross-channel re-contact rate) surfaces false deflections, per-macro-FCR tracking surfaces macro misapplication, repeat-contact pattern detection surfaces root-cause escalation opportunities, and priority-classifier transparency (surfacing feature-attribution) prevents hallucinated rationales from being adopted as coaching rules. Measurement redesign alone addresses about 6 of 26 patterns without architectural change.