Purpose
Convert unstructured or semi-structured complaint records into a categorized trend summary that surfaces the top issue clusters, frequency and rate signals, and early-warning risk flags — so quality and post-market surveillance teams can decide where to investigate, escalate, or open a CAPA without manually reading every record.
When to Use
Invoke this skill when the user asks to:
- Summarize a batch of customer complaints or return descriptions into themes
- Prepare a monthly or quarterly post-market surveillance trend summary
- Identify which product issues are rising or newly emerging
- Flag potential safety or reliability signals hidden in complaint free-text
- Categorize a complaint log for a management review or QMS input
- Decide whether a complaint pattern warrants escalation or a CAPA
Inputs Required
Before starting, collect:
- Complaint data: The raw records — a pasted log, exported table, or list of free-text complaint descriptions
- Product line/model(s): Which product(s) the complaints relate to
- Time period covered: Date range of the complaint set (e.g., Q2 2024, Jan–Jun)
- Volume baseline: Units sold/shipped/installed in the period, if available, to compute complaint rate (optional but improves rate signals)
- Prior-period comparison: Previous period's counts or top categories, if available, to detect trend direction
- Known issues/watchlist: Any issues already under investigation or expected
- Severity or safety flags in data: Any existing severity, injury, or field-safety indicators in the records
If volume baseline or prior-period data is missing, report raw counts and share-of-total instead of rates, and note that trend direction is inferred within the current dataset only.
Instructions
Step 1: Normalize and Parse the Complaint Records
Read every record and extract, per complaint:
- Product/model referenced (map variants to a single line where obvious)
- Failure mode / symptom in plain language (what went wrong)
- Component/subsystem implicated (e.g., battery, hinge, firmware, packaging, charger)
- Use context if stated (e.g., during charging, on first use, after drop)
- Severity indicators if present (safety, injury, fire/overheat, data loss, cosmetic only)
Deduplicate obvious repeats. Do not invent data — if a field is not stated, mark it "unspecified."
Step 2: Categorize into Issue Clusters
Group complaints into a consistent taxonomy. Use these standard top-level categories, adapting sub-categories to the product:
- Safety / Hazard (overheating, fire, sharp edge, electrical shock, injury reports)
- Functional Failure (device won't power on, feature not working, intermittent operation)
- Reliability / Durability (breakage, wear, degradation over time)
- Connectivity / Software (pairing, app, firmware, updates)
- Power / Charging (battery life, charging failure, adapter issues)
- Physical / Cosmetic (scratches, fit, finish, loose parts)
- Packaging / Shipping Damage
- Usability / Instructions (setup confusion, unclear documentation)
- Other / Unclassified
Each complaint goes to exactly one primary category (assign the most severe applicable). Note secondary themes where relevant.
Step 3: Compute Frequency and Rate Signals
For each category and top sub-issue:
- Count and share of total complaints (%)
- Complaint rate (per 1,000 or per 10,000 units) if volume baseline is provided
- Trend direction vs. prior period: ↑ Rising / → Stable / ↓ Falling / ★ New — with the delta
- Rank categories from highest to lowest volume, then re-rank by risk in Step 5
Step 4: Detect Emerging Risk Flags
Apply these signal rules and flag any that trigger:
- New pattern: An issue absent in the prior period now appearing repeatedly (≥3 records or a clear cluster)
- Acceleration: Category rising ≥30% period-over-period or clustering in recent dates
- Severity concentration: Multiple records citing safety, overheat, injury, or fire — flag regardless of low count
- Single-component convergence: Distinct symptoms tracing back to one component/subsystem
- Early-life failure: Failures reported "on first use" or within days of receipt (suggests defect vs. wear)
- Batch/lot clustering: Concentration around a date range, region, or lot if identifiable
For each flag, state the signal, the supporting evidence (counts/examples), and why it matters.
Step 5: Prioritize and Recommend Actions
Rank the top issues by a Risk = Severity × Frequency × Trend logic (not raw volume alone). For the top 3–5 issues, recommend one action each from:
- Monitor (watch next period, no action yet)
- Investigate (assign engineering/quality review)
- Escalate (management review / potential CAPA trigger)
- Report (regulatory or field-safety consideration if safety signal present)
Be explicit and opinionated — do not label everything "monitor."
Output Format
- Structure: Executive summary → category breakdown table → emerging risk flags → prioritized action list
- Length: 700–1,100 words
- Format: Prose executive summary plus a category breakdown table and clearly labeled flag/action blocks
- Sections: 1. Executive Summary (3–5 sentences: total complaints, top category, headline risk) 2. Category Breakdown Table (columns: Category, Count, % of Total, Rate per 10k [if available], Trend, Top Sub-Issue) 3. Emerging Risk Flags (each flag: signal type, evidence, why it matters) 4. Prioritized Actions (top 3–5 issues ranked by risk, each with recommended action and rationale) 5. Data Notes (assumptions, missing baselines, unclassified rate)
- Tone: Quality analyst — factual, evidence-anchored, conservative on safety claims, decisive on prioritization
Quality Checklist
Before delivering output, verify:
- [ ] Every complaint record is assigned to exactly one primary category (counts sum to total)
- [ ] The category table includes count, % of total, and trend direction for each row
- [ ] Any safety/overheat/injury language in the data is flagged regardless of low count
- [ ] At least one emerging risk flag is either raised with evidence or explicitly stated as "none detected"
- [ ] Prioritized actions use risk logic (severity × frequency × trend), not raw volume alone
- [ ] Rates are only reported when a volume baseline was provided; otherwise counts and share are used, and this is noted
Notes
- Low-count safety signals outrank high-count cosmetic issues — never let volume bury a hazard signal.
- When complaint text is vague, cluster by symptom rather than guessing at root cause; root cause is an investigation output, not a summarization output.
- If the same complaint could fit two categories, assign the more severe one to avoid under-weighting risk.
- This summary is a triage input for quality review — it identifies where to look, not a formal CAPA or regulatory determination.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills