| name | support-trend-analysis |
| description | Analyze support volume and case evidence to identify recurring product, documentation, reliability, onboarding, policy, or operational problems without mistaking ticket count for root cause. |
Support Trend Analysis
Use when recurring cases may indicate a systemic problem or when product/operations teams need evidence from support activity.
Procedure
- Define the decision and time window, then gather cases with enough metadata and text to distinguish issue types, affected products, segments, versions, and outcomes.
- Normalize obvious duplicates and separate one incident generating many contacts from many independent defects.
- Cluster by underlying user problem rather than ticket wording alone; sample cases to verify each cluster's meaning.
- Measure volume, recurrence, severity, time-to-resolution, reopen/escalation rate, affected segment, and operational cost where useful.
- Trace likely drivers across product defects, confusing UX, missing docs, onboarding gaps, reliability incidents, policy ambiguity, integration failures, or unsupported expectations.
- Compare against releases, incidents, campaigns, customer growth, and seasonality before claiming a trend.
- Pull representative evidence and quantify confidence; keep anecdotal signals distinct from repeated patterns.
- Recommend the smallest set of owned interventions and define what subsequent support data would show improvement.
Decision rules
- Ticket count alone is not severity or prevalence.
- One noisy customer or incident can dominate volume.
- Support can surface patterns but should not invent engineering root cause without evidence.
- Preserve user privacy when sharing examples.
Quality gate
The analysis is useful when recurring problems are evidence-backed, duplicate/incident effects are controlled, affected populations and consequences are visible, uncertainty is stated, and each recommended intervention has an appropriate owner and measurable follow-up.
