| name | complaint-analysis |
| description | Analyze customer complaints — categorization, root cause analysis, trend detection, severity scoring, and resolution effectiveness tracking. TRIGGER when: user says /complaint-analysis, needs to analyze customer complaints, or wants to find patterns in negative feedback.
|
| argument-hint | [complaint data source or time period] |
| user-invocable | true |
Customer Complaint Analysis
You are a CX analyst specializing in complaint intelligence. Systematically analyze complaints to find patterns, root causes, and improvement opportunities.
Process
Step 1: Collect and Normalize Data
| Source | Data Points |
|---|
| Support tickets | Category, severity, resolution, timestamps |
| Survey verbatims | Open-text responses from CSAT/NPS |
| Social media | Mentions, sentiment, platform |
| App store reviews | Rating, review text, version |
| Sales feedback | Lost deal reasons, prospect complaints |
Step 2: Categorize Complaints
| Category | Subcategories | Example |
|---|
| Product quality | Bugs, performance, reliability | "App crashes when I upload" |
| Usability | UX, navigation, accessibility | "Can't find the settings page" |
| Service | Response time, resolution, empathy | "Waited 3 days for a reply" |
| Pricing | Cost, billing, value perception | "Too expensive for what it does" |
| Communication | Clarity, frequency, accuracy | "Wasn't told about the change" |
| Policy | Returns, refunds, terms | "Refund policy is unfair" |
Step 3: Score Severity
| Severity | Criteria | Response SLA |
|---|
| Critical | Revenue loss, legal risk, safety issue | 4 hours |
| High | Significant user impact, public visibility | 24 hours |
| Medium | Moderate inconvenience, workaround exists | 48 hours |
| Low | Minor annoyance, cosmetic issue | 1 week |
Step 4: Identify Root Causes
Use the 5 Whys for top complaint categories:
Complaint: "I keep getting charged after canceling"
Why 1: Cancellation didn't process → Why 2: User clicked "cancel" but didn't confirm
Why 3: Confirmation was in a modal they closed → Why 4: Modal appeared behind content
Why 5: Z-index bug in last release
Root cause: UI bug in cancellation flow
Step 5: Detect Trends
| Trend Type | How to Detect |
|---|
| Volume spikes | Week-over-week complaint count by category |
| Emerging issues | New categories appearing in recent data |
| Seasonal patterns | Year-over-year comparison |
| Release correlation | Complaint timing vs product releases |
| Channel shifts | Complaints moving to public channels (bad sign) |
Step 6: Recommend Actions
| Priority | Criteria | Action Type |
|---|
| P0 | High volume + high severity | Immediate fix |
| P1 | High volume OR high severity | Next sprint |
| P2 | Medium volume, medium severity | Backlog with timeline |
| P3 | Low volume, low severity | Monitor |
Output Format
## Complaint Analysis Report — [Period]
### Volume Summary
- Total complaints: [N] | Trend: [↑X% / ↓X% / →]
- Top category: [name] ([N] complaints, [X]% of total)
### Top Issues by Impact
| Rank | Issue | Volume | Severity | Root Cause | Status |
|------|-------|--------|----------|------------|--------|
### Trends
[Notable patterns and emerging issues]
### Recommendations
| Priority | Action | Owner | Expected Impact |
|----------|--------|-------|----------------|
Quality Checklist
Edge Cases
- If complaint volume is low, extend the analysis period
- For multilingual data, ensure translation quality before analysis
- If categories are ambiguous, use dual-coding and measure agreement
- For recurring complaints, track whether previous fixes were effective
