csat-root-cause
Skill0 starsChanged 39 days agoMITView on GitHub
Analyzes CSAT and NPS verbatims to surface root-cause themes and prioritize fixes by frequency and impact. Use when interpreting customer satisfaction data to inform product or process decisions.
In this repository6 other files it gives its agents.
- churn-reductionSkill
- escalation-summarySkill
- kb-article-writerSkill
- refund-deescalationSkill
- support-macro-librarySkill
- support-ticket-replySkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Before analyzing, filter the dataset: remove blank verbatims, remove comments that mention only a specific agent by name (these are …
- Distinctive: line 38
Do not present word clouds - they conflate frequency with font size and obscure causality.
- Distinctive: line 39
Do not conflate correlation with causation.
- Distinctive: line 40
Do not analyze fewer than 30 verbatims.
- Distinctive: line 41
Do not pool detractor and promoter comments into one analysis - the same theme (e.g.
- Distinctive: line 42
Do not report a theme supported by fewer than 5 verbatims as a trend.
- Distinctive: line 46
Every theme is scored on both frequency and impact - never prioritized on mention count alone.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CSAT Root Cause Analysis
Raw CSAT scores tell you that something is wrong. Verbatim comments tell you what and why. The goal of root-cause analysis is to turn hundreds of individual comments into a ranked list of fixable problems.
Data preparation
Before analyzing, filter the dataset: remove blank verbatims, remove comments that mention only a specific agent by name (these are agent-performance signals, not product/process signals), and separate detractor verbatims (score 0-6 on NPS, 1-3 on CSAT) from promoter verbatims. Analyze detractors first - they drive churn.
Coding scheme
Apply a two-level coding scheme. Level 1 is the broad category (product bug, slow response time, unclear communication, pricing confusion, onboarding friction, feature gap, policy frustration). Level 2 is the specific sub-theme within that category. Code each verbatim with exactly one Level 1 and one Level 2 code. If a verbatim contains multiple distinct complaints, split it into sub-comments before coding.
Prioritization matrix
After coding, calculate two numbers for each theme: frequency (what percentage of verbatims mention it) and impact (what is the average CSAT score for tickets that mention it versus those that do not). Plot themes on a 2x2 matrix: high frequency + high impact = fix immediately, high frequency + low impact = quick wins, low frequency + high impact = critical edge cases, low frequency + low impact = monitor.
Presenting findings
Report findings as: the top three to five themes by priority, with verbatim examples for each, a proposed fix or owner for each theme, and a success metric (what does a fixed version look like in the data). Avoid reporting a theme without a proposed action - analysis without a recommendation is noise.
Thresholds that signal urgency
Escalate immediately if any single theme appears in more than 15% of detractor verbatims within a 30-day window, or if average CSAT for a theme drops below 2.5/5. These thresholds indicate systemic failure, not statistical noise.
Deliverable
Produce a root-cause report containing: the coded verbatim dataset (every comment tagged with one Level 1 and one Level 2 code), the frequency-by-impact matrix, the top three to five prioritized themes each with two or three representative verbatims, a proposed fix and named owner per theme, and the success metric that will show in the data when each fix has worked.
What to avoid
- Do not present word clouds - they conflate frequency with font size and obscure causality.
- Do not conflate correlation with causation; a theme appearing alongside low scores does not prove it caused the low score without further validation.
- Do not analyze fewer than 30 verbatims; sample size below that produces unreliable theme distributions.
- Do not pool detractor and promoter comments into one analysis - the same theme (e.g. pricing) means different things in each population.
- Do not report a theme supported by fewer than 5 verbatims as a trend; call it an edge case and monitor it.
Quality bar
- Every theme is scored on both frequency and impact - never prioritized on mention count alone.
- Each reported theme carries a proposed action, an owner, and a success metric, not just a description.
- Detractors and promoters are analyzed separately, and the escalation thresholds (15% of detractors in 30 days, theme CSAT below 2.5/5) are checked explicitly.
- Verbatim examples are quoted, not paraphrased, so the reader can audit the coding.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

