Service Triage

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

Operational Metrics

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.