Prioritize Support Tickets by What Actually Recurs
Most prioritization starts with whichever tickets a PM happened to read recently, or the ones that got escalated loudly. That's not the same as knowing what's actually most common, and it means a quiet but frequent problem can lose to a rare but noisy one every time. A PM opening the support queue on a Monday morning is far more likely to act on the ticket that got escalated by an account manager over the weekend than on the fact that thirty other users quietly reported a smaller version of the same underlying friction over the past month.
Warning
A ticket you remember and a ticket that recurs are different signals. The one you remember might just be the one that got escalated, not the one affecting the most users.
The ticket you remember isn't always the one worth fixing first. The one that keeps recurring is.
Why reading tickets in order doesn't surface real frequency
Reading through a support queue gives you impressions, not counts. A problem reported by fifteen different users in fifteen different ways doesn't look like a pattern when you're reading one ticket at a time, it looks like fifteen separate complaints. The mental effort of holding a running tally across dozens of tickets, each with different wording, is exactly the kind of counting task a human reviewer is bad at and prone to underestimating.
Consider a support queue for an onboarding flow where one user, an enterprise account, escalates loudly about a confusing step in setup. That ticket gets attention fast. Meanwhile, over the same week, thirty separate free-tier users quietly submit tickets about the same step, phrased in thirty different ways, none of them escalated, none of them individually alarming. Read in the order they arrived, the loud enterprise ticket dominates the PM's mental model of what's broken, while the actual highest-frequency problem, affecting far more users, sits unrecognized as a pattern across thirty separate tickets.
Before: skim recent tickets, prioritize whichever ones feel most urgent or got escalated, move on.
After: paste a batch of tickets into Claude, ask it to group them into themes ranked by how many tickets fall into each one, and prioritize based on actual frequency.
A process for turning tickets into ranked themes
- 1
Collect a real batch, not a handful
Pull tickets from a defined window, a full week or month, rather than whatever's sitting in your inbox. A partial sample skews toward whatever came in most recently.
- 2
Ask for themes grouped by frequency, not a summary
A summary compresses what was said. Ask specifically for tickets grouped into recurring themes, with a count of how many tickets fall into each group.
- 3
Ask for a representative ticket per theme
A real example grounds each theme in something concrete, and it's useful later when you need to justify a priority with an actual case, not just a count.
- 4
Prioritize by count, then sanity-check with severity
Frequency tells you what's common, not necessarily what's most costly. Once you have the ranked list, check whether a lower-frequency theme is still worth moving up because of how severe it is.
Here are 30 support tickets about our onboarding flow. Group them into the three most common complaints, and tell me how many tickets fall into each group.
”Once themes are ranked, it's worth checking whether they've grown or shrunk relative to a prior period, since a theme that's rapidly increasing week over week is a different kind of urgent than one that's been a steady, low-level hum for months.
Here's the same theme breakdown from last month. Compare the two and tell me which themes are growing as a share of total tickets, not just which ones have the highest raw count this month.
”
Inside Claude Tutorial
Ranking by real frequency instead of recency is transferable.
Grouping scattered reports into counted themes, instead of prioritizing whichever one you saw most recently, applies well beyond support tickets. The app has a full lesson on it, with practice that carries over to any feedback you need to act on.
When frequency and severity point in different directions
Sometimes the most common theme isn't the most damaging one. A minor annoyance reported often and a rare but account-blocking bug both deserve a place on the list, just not necessarily in frequency order. Treating frequency as the only input risks systematically under-prioritizing the rare-but-severe issues that don't generate many tickets simply because the affected users can't get far enough into the product to file one.
Tip
Ask Claude to flag which themes involve users being blocked entirely versus merely inconvenienced. A blocking issue with fewer reports can still outrank a bigger but low-severity theme.
Of the three themes you found, which ones involve users being completely blocked from finishing onboarding, versus just annoyed by friction? I want to weigh severity alongside frequency before finalizing priority.
”It's also worth checking whether a low-frequency, high-severity theme might actually be under-reported precisely because it's severe, since a user who hits a hard blocker early in onboarding may abandon the product entirely rather than take the time to file a ticket about it.
This blocking issue only generated 3 tickets, which seems low for something this severe. Is there a reason a blocking issue like this might be under-reported compared to a milder one that still lets users continue?
”Continue reading
- Writing a Roadmap Doc That Explains the Tradeoffs: turning a ranked list of themes into a roadmap decision stakeholders can follow.
- Writing a PRD From a One-Line Feature Request: what to do once a theme surfaces a feature worth specifying.
- Sharpening a PRD Before You Send It for Review: catching edge cases a theme like this one might point to before review.