Support hears the truth about the product first — every confusion, every broken flow, every "I wish it could" — but it stays trapped in the queue as a thousand one-off replies. Leadership and product end up guessing at what customers want while the answer sits in last month's tickets. This system reads the month at once and rolls it into a report: the recurring themes, where people get stuck, what they keep asking for, and which bugs are biting — each with a count and a read on impact — so support turns into the early-warning system it should be.
- A month of tickets as
tickets-may.csv— subject, body, and ideally a date and channel column. Drop it into the chat in Claude Desktop (or open the folder it lives in) so Claude can read it. Scrub names, emails, and account numbers to[customer]before you share it. - Any context that makes counts meaningful: total ticket volume, what shipped or changed during the month, and last month's report if you have one to compare against.
- Who the report is for — a product team wants friction and requests; leadership wants themes and trend lines — so you pitch it right.
-
Confirm the data, then surface the themes
Make Claude prove it read the full month, then pull the recurring themes — the handful of stories the month is really telling, above the noise of individual tickets.
you askRead tickets-may.csv. First confirm the row count and date range. Then identify the top recurring THEMES across the month — not individual tickets, but the 6–8 stories the data keeps telling — with a count and a one-line description for each. Don't write the full report yet.what you get back A confirmation ("1,240 tickets, May 1–31") and a themed list — "billing confusion (210), onboarding friction (180), mobile bugs (95)..." — each a story with a number behind it, not a single complaint.
Always anchor a report in real counts — "a lot of people mentioned billing" moves no one; "210 tickets, 17% of the month" moves a roadmap.
-
Split it into the four buckets product actually uses
A flat list of themes is hard to act on. Sorting into friction, requests, bugs, and praise tells each reader exactly what's theirs to fix — and which signals are which.
you askSort the themes into four buckets: friction points (where people get stuck), feature requests (what they keep asking for), bugs (something's broken), and what they love. For each item give a count, a representative quote with the customer scrubbed to [customer], and a one-line read on impact. Flag your confidence where a theme is fuzzy.what you get back Four labeled buckets — friction, requests, bugs, praise — each item with a count, an anonymized real quote, and an impact note, plus a confidence flag where the grouping is loose.
-
Rank by impact and recommend where to look
Volume isn't the same as importance — a low-count bug that loses paying customers outranks a high-count cosmetic gripe. Have Claude reason about impact, not just frequency, as a recommendation you'll sanity-check.
you askRank everything by likely impact, not just volume — weigh how many customers, how angry, and whether it touches money or churn. Give me the top 5 things product and leadership should look at this month, each with the count, the why, and the suggested owner. Be clear these are recommendations to verify, not conclusions.what you get back A prioritized top-5 — "double-charge bug: low count (31) but high impact, touches billing and trust → engineering" — framed as recommendations, with the reasoning shown so you can challenge it.
-
Assemble the report for its audience
Package it so a busy reader gets the story in thirty seconds and the detail if they want it. The summary at the top is what actually gets read in a leadership channel.
you askAssemble a voice-of-customer report: a 4-bullet executive summary at the top (the month in 30 seconds), then the four buckets with counts and quotes, then the prioritized top 5 with owners. Keep the tone factual, cite counts everywhere, and end with 3 questions for product to dig into. Make it paste-ready for our team channel.what you get back A clean report — executive summary, the four buckets with evidence, a prioritized action list with owners, and open questions — that reads in thirty seconds and holds up to a skeptical product lead.
- Feed it from triage: run the Find what the queue is really about playbook each week and let those clusters roll up into this monthly report, so the report writes itself from work you already did.
- Close the loop downstream: the friction-point themes are the exact backlog for the Build a help center from the questions you actually get playbook, and the bugs are escalations for engineering — the report should hand off, not just describe.
- Make it monthly and automatic (Power Track): schedule a
/vocagent (see the Playbook's Capabilities tab) to draft the first cut on the first of each month from the prior month's export, so you edit a draft instead of starting cold. Scheduled agents are the opt-in Power Track — on Desktop you run the same prompts at the start of each month until you're ready to automate them.
- Counts and quotes are the report's credibility — verify the headline numbers against the raw export and confirm every quoted line is real and accurately attributed before anyone forwards it up.
- A month of tickets is a dense pile of PII — scrub names, emails, and account numbers to
[customer]before uploading, and keep quotes anonymized in the report itself. - Claude surfaces and ranks the patterns; a human owns the conclusions. The impact ranking is a recommendation to challenge — present it as "here's what the data suggests we look at," not "here's what's wrong with the product."
you'll end up with A factual, count-backed voice-of-customer report — themes, friction, requests, bugs, and a prioritized top 5 with owners — that turns the month's queue into an early-warning signal product and leadership will actually read.
Questions people ask
- What do I feed in, and how should I scrub it?
- A month of tickets as a CSV with subject, body, and ideally date and channel columns — with names, emails, and account numbers scrubbed to `[customer]` before uploading. Add context that makes counts meaningful: total volume, what shipped that month, and last month's report to compare against.
- Why does every theme need a count?
- Because counts are the report's credibility. "A lot of people mentioned billing" moves no one; "210 tickets, 17% of the month" moves a roadmap. Verify the headline numbers against the raw export before anyone forwards it up.
- Should I rank issues purely by how many tickets they get?
- No — rank by impact, not just volume. A low-count bug that touches money or churn outranks a high-count cosmetic gripe. Have Claude weigh how many customers, how angry, and whether it touches revenue, and treat the ranking as a recommendation you verify.
- Who owns the conclusions in the report?
- A human does. Claude surfaces and ranks the patterns, but present the impact ranking as "here's what the data suggests we look at," not "here's what's wrong with the product" — the conclusions are yours to challenge and confirm.