- Time
- 10 minutes
- You work in
- Scheduled Jobs
- Connect first
- Works out of the box
Before you start
- A few weeks of answered threads
Support reporting usually counts things: tickets opened, tickets closed, first-response time. All true, all measuring the support function rather than the product, and none of it tells you what customers were unhappy about.
The words are right there. Nobody reads them in aggregate.
Ask for themes in their language
The instruction that matters is to keep the customer's phrasing. Once a complaint is translated into your internal vocabulary it stops being evidence and becomes a category.
Every Friday, read the week's customer threads and tell me what people were actually unhappy about. Group by theme. For each theme: how many people raised it what they said, quoted, two or three examples whether it got worse or better than last week Use their words for the theme name. If four people said "it's slow", the theme is "it's slow", not "performance concerns". Ignore questions that were simply questions. I want dissatisfaction, not volume. If there was nothing worth reporting, say so.
The instruction about naming themes in their words is the whole report. "Performance concerns" is a category that can sit in a document for a year. "It's slow" is a sentence somebody has to answer. The translation into professional language is exactly what lets an organisation look at a complaint without feeling it.
Read the quotes, not the counts
The counts tell you what to look at. The quotes tell you what is actually wrong, and they are usually more specific than any summary would be.
This is also the section to forward. A product argument settles much faster with three customer sentences in it than with a number.
Watch the direction, not the level
A theme with four mentions is not inherently worse than one with two. A theme that went from one to four is. The week-on-week comparison is what turns this from a snapshot into a signal.
Keep it separate from the bug clustering
This report is about dissatisfaction; clustering repeated tickets is about identifying one cause behind several reports. They overlap and they are not the same, and combining them produces something that does neither well.
What good looks like
Once a week you read six themes in customers' own words, with quotes, and you can tell which are growing.
The uncomfortable measure: how many of this week's themes were already on last month's list unchanged?