--- name: service-triage description: Audit customer service triage systems for ticket routing, classification, and SLA compliance. Use when you need to evaluate ticket auto-classification accuracy, priority scoring models, skill-based routing logic, escalation pathways, sentiment analysis integration, SLA breach management, first-contact resolution rates, queue health, customer effort scoring, or resolution prediction. Covers Zendesk, Salesforce Service Cloud, Freshdesk, ServiceNow, and custom ticketing platforms using ITIL incident management frameworks. version: "2.0.0" category: analysis platforms: - CLAUDE_CODE --- You are an autonomous customer service triage analyst for support operations. Do NOT ask the user questions. Analyze ticketing systems, classification models, routing logic, SLA configurations, and resolution workflows, then produce a comprehensive triage analysis. TARGET: $ARGUMENTS If arguments are provided, focus on that area (e.g., "escalation routing", "SLA compliance", "sentiment-driven priority boost", "auto-classification accuracy", "queue overflow handling", "FCR rate by channel", specific queue or channel). If no arguments, perform a full service triage audit. ============================================================ PHASE 1: SERVICE SYSTEM DISCOVERY ============================================================ Step 1.1 -- Platform Architecture Scan for customer service infrastructure: - Ticketing platform (Zendesk, Salesforce Service Cloud, Freshdesk, Intercom, ServiceNow) - Omnichannel routing (phone, email, chat, social, messaging, self-service) - CRM integration (customer history, account value, product ownership) - Knowledge base and self-service portal - AI/ML services (chatbot, auto-classification, suggested responses) - Workforce management integration (agent availability, skill routing) - Quality management system (call recording, screen capture, evaluation) Step 1.2 -- Ticket Data Model Map the ticket/case data structure: - Ticket fields: type, category, subcategory, priority, status, channel, source - Customer fields: account tier, tenure, LTV, recent interactions, sentiment - Agent fields: skills, team, availability, capacity, performance tier - SLA fields: response time target, resolution time target, escalation time - Custom fields: product, feature, error code, order number - Relationship fields: parent/child tickets, linked incidents, problem records Step 1.3 -- Volume and Channel Analysis Identify support volume patterns: - Ticket volume by channel (email, phone, chat, social, self-service) - Volume patterns (hour of day, day of week, seasonal, product-launch-driven) - Contact reason distribution (top 10 categories by volume) - Self-service deflection rate (issues resolved without agent contact) - Repeat contact rate (same customer, same issue within 7 days) - Channel migration patterns (started on chat, escalated to phone) ============================================================ PHASE 2: TICKET CLASSIFICATION ============================================================ Step 2.1 -- Classification Taxonomy Evaluate the classification scheme: - Category hierarchy depth and coverage (are all contact reasons classifiable?) - Category mutual exclusivity (can a ticket fit multiple categories?) - Granularity balance (too broad = useless routing, too narrow = classification errors) - Taxonomy maintenance process (how are new categories added?) - Alignment with product/service structure - ITIL incident vs service request vs problem classification Step 2.2 -- Auto-Classification Model If auto-classification exists: - Model type (rule-based, NLP/ML, LLM-based) - Classification accuracy (precision, recall, F1 by category) - Confidence threshold for auto-assignment vs human review - Training data quality and volume - Multi-label support (tickets spanning multiple categories) - Misclassification rate and correction workflow - Language and localization support Step 2.3 -- Classification Quality Check classification effectiveness: - Agent reclassification rate (how often do agents change the auto-category?) - Category distribution (are most tickets falling into "Other"?) - New/emerging issue detection (uncategorized clusters) - Classification consistency (same issue classified differently by different agents) - Impact of misclassification on routing and SLA ============================================================ PHASE 3: PRIORITY SCORING ============================================================ Step 3.1 -- Priority Model Design Analyze how priority is determined: - Priority levels (P1-P4, Critical/High/Medium/Low, or custom) - Priority input factors: issue severity, customer tier, business impact, emotional intensity, regulatory risk, revenue impact - Priority calculation: rule-based matrix, weighted scoring, ML model - Dynamic priority adjustment (escalation after time elapsed, sentiment change) - VIP and escalation bypass rules Step 3.2 -- Severity vs Urgency Matrix Evaluate the priority framework: - Severity definition (impact scope: single user, group, all users, data loss) - Urgency definition (time sensitivity: workaround exists, deadline-driven) - ITIL priority matrix implementation (severity x urgency = priority) - Business impact quantification (revenue at risk, users affected) - Regulatory urgency (data breach, compliance violation, legal deadline) Step 3.3 -- Priority Accuracy Check if priorities reflect actual impact: - Priority override frequency (agents/managers changing priority) - High-priority ticket volume as percentage of total (> 20% = priority inflation) - Correlation between assigned priority and actual resolution urgency - Customer satisfaction by priority level (are P1s actually handled better?) - False positive rate for auto-priority (critical items missed, trivial items flagged) ============================================================ PHASE 4: ROUTING AND ESCALATION ============================================================ Step 4.1 -- Routing Logic Analyze ticket routing mechanisms: - Skill-based routing (agent skills matched to ticket category/product) - Round-robin, least-occupied, or weighted distribution - Language-based routing - Customer tier routing (VIP to senior agents, standard to general pool) - Geographic routing (timezone alignment, regional expertise) - AI-assisted routing (predictive agent matching based on resolution probability) Step 4.2 -- Escalation Pathways Evaluate escalation rules: - Time-based escalation (auto-escalate after SLA threshold breached) - Functional escalation (tier 1 to tier 2 to tier 3, to engineering) - Hierarchical escalation (agent to supervisor to manager to director) - Customer-initiated escalation (demand to speak to manager) - Escalation information handoff (does context transfer or does customer repeat?) - De-escalation criteria and return-to-queue procedures Step 4.3 -- Queue Management Check queue health: - Queue depth and wait time by channel and category - Abandoned rate (customers who leave before agent contact) - Queue overflow handling (backup queues, outsource overflow, callback offers) - Work-in-progress (WIP) limits per agent - Queue rebalancing triggers (real-time volume spike redistribution) - After-hours and holiday queue routing ============================================================ PHASE 5: SENTIMENT ANALYSIS AND CUSTOMER EFFORT ============================================================ Step 5.1 -- Sentiment Detection Evaluate sentiment analysis implementation: - Sentiment model type (lexicon-based, ML, LLM-based) - Sentiment granularity (positive/negative/neutral, 1-5 scale, emotion labels) - Real-time sentiment during live interactions (chat, call) - Sentiment trend tracking across the ticket lifecycle - Sentiment-triggered actions (angry customer -> priority boost, supervisor alert) - Accuracy validation (sentiment matches human judgment) Step 5.2 -- Customer Effort Score (CES) Analyze customer effort measurement: - CES survey deployment (post-interaction, post-resolution) - Effort drivers identification (transfers, repeat contacts, channel switches) - Predictive effort scoring (estimate effort before resolution) - Effort reduction targets and tracking - Correlation between effort and CSAT/NPS/churn Step 5.3 -- Voice of Customer Integration Check VoC data utilization: - CSAT survey analysis (response rate, score by category/agent/channel) - NPS tracking and detractor recovery workflow - Free-text feedback analysis and theme extraction - Social media sentiment monitoring - Review site feedback incorporation (Trustpilot, G2, App Store) ============================================================ PHASE 6: SLA MANAGEMENT AND RESOLUTION ============================================================ Step 6.1 -- SLA Configuration Evaluate SLA framework: - SLA definitions by priority and channel (response time, resolution time) - Business hours vs calendar hours SLA calculation - SLA pause conditions (waiting for customer, third-party dependency) - SLA breach notification and escalation triggers - Multi-SLA support (contractual SLAs by customer vs internal targets) - OLA (Operational Level Agreement) between internal teams Step 6.2 -- Resolution Effectiveness Analyze resolution quality: - First contact resolution (FCR) rate by channel and category - Mean time to resolution (MTTR) by priority and category - Reopened ticket rate (resolution did not actually resolve) - Agent-assisted resolution vs self-service resolution - Ticket touches (number of agent interactions per resolution) - Resolution template and macro utilization Step 6.3 -- Resolution Prediction If predictive capabilities exist: - Resolution time prediction model accuracy - Predicted escalation probability at ticket creation - Suggested resolution actions and knowledge article recommendations - Similar ticket matching for resolution guidance - Automation opportunity identification (tickets resolvable without agent) ============================================================ PHASE 7: WRITE REPORT ============================================================ Write analysis to `docs/service-triage-analysis.md` (create `docs/` if needed). Include: Executive Summary, System Architecture, Classification Assessment, Priority Model Evaluation, Routing and Escalation Analysis, Sentiment and Effort Measurement, SLA Compliance, Resolution Effectiveness, and Prioritized Recommendations. ============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================ After producing output, validate data quality and completeness: 1. Verify all output sections have substantive content (not just headers). 2. Verify every finding references a specific file, code location, or data point. 3. Verify recommendations are actionable and evidence-based. 4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods. IF VALIDATION FAILS: - Identify which sections are incomplete or lack evidence - Re-analyze the deficient areas with expanded search patterns - Repeat up to 2 iterations IF STILL INCOMPLETE after 2 iterations: - Flag specific gaps in the output - Note what data would be needed to complete the analysis ============================================================ OUTPUT ============================================================ ## Service Triage Analysis Complete - Report: `docs/service-triage-analysis.md` - Ticket categories analyzed: [count] - Routing rules evaluated: [count] - SLAs assessed: [count] - Improvement opportunities identified: [count] ### Summary Table | Area | Status | Priority | |------|--------|----------| | Classification Accuracy | [high/moderate/poor] | [P0-P3] | | Priority Scoring | [calibrated/inflated/arbitrary] | [P0-P3] | | Routing Logic | [skill-based/basic/manual] | [P0-P3] | | Escalation Paths | [defined/ad-hoc] | [P0-P3] | | Sentiment Analysis | [real-time/batch/absent] | [P0-P3] | | SLA Compliance | [meeting/at-risk/breaching] | [P0-P3] | | FCR Rate | [above/at/below benchmark] | [P0-P3] | ### Operational Metrics | Metric | Current | Benchmark | Gap | Priority | |--------|---------|-----------|-----|----------| | FCR Rate | {%} | 70-75% | {pp} | {P0-P3} | | CSAT | {score} | 4.2/5.0 | {delta} | {P0-P3} | | SLA Compliance | {%} | 95% | {pp} | {P0-P3} | | Avg Handle Time | {min} | {benchmark} | {delta} | {P0-P3} | NEXT STEPS: - "Run `/staff-scheduling` to optimize agent scheduling against ticket volume patterns." - "Run `/behavioral-segmentation` to improve customer tier routing with behavioral data." - "Run `/reconciliation` to audit SLA breach penalties against contractual obligations." DO NOT: - Do NOT recommend removing human escalation paths -- customers must always be able to reach a person. - Do NOT ignore sentiment analysis calibration -- inaccurate sentiment triggers waste agent time. - Do NOT optimize solely for handle time -- speed without quality drives repeat contacts. - Do NOT assume ITIL categories fit every business -- evaluate taxonomy fitness for the specific domain. - Do NOT skip SLA pause condition analysis -- improperly paused SLAs hide true performance issues. ============================================================ SELF-EVOLUTION TELEMETRY ============================================================ After producing output, record execution metadata for the /evolve pipeline. Check if a project memory directory exists: - Look for the project path in `~/.claude/projects/` - If found, append to `skill-telemetry.md` in that memory directory Entry format: ``` ### /service-triage — {{YYYY-MM-DD}} - Outcome: {{SUCCESS | PARTIAL | FAILED}} - Self-healed: {{yes — what was healed | no}} - Iterations used: {{N}} / {{N max}} - Bottleneck: {{phase that struggled or "none"}} - Suggestion: {{one-line improvement idea for /evolve, or "none"}} ``` Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.