Support tickets are the most honest data your company collects. No survey polish, no NPS theater, no "what can we do better" small talk. Just a customer, a problem, and a timestamp. And almost nobody in CS reads them at scale, because reading 1,000 tickets is a full-time job nobody hired for.
So the richest signal in the company sits in a queue that leadership glances at for resolution times and ignores for content. Meanwhile the tickets already contain next quarter's churn reasons, the onboarding gaps, the bugs your top five accounts are quietly working around โ all of it, written down by the customers themselves, waiting for someone to do the reading.
That someone is you, and the reading takes twenty minutes. Below are the triage prompts that turn a ticket export into themes, sentiment shifts, and a one-page memo leadership will actually act on. This is the morning ritual I wish I'd built years ago.
The setup: your weekly ticket export
Before the prompts, the raw material. Once a week โ Monday before your coffee, ideally โ export the last 7 days of tickets from your helpdesk. The columns you need: subject, body, submitted date, account/company, plan or segment, first response time, resolution status, CSAT if you have it. Strip customer names and contact details before pasting anything into a model โ tickets contain PII by design, and your prompt workflow should assume everything is logged somewhere you don't control. Replace names with account IDs; the sentiment analysis doesn't need to know who anyone is.
On volume: if you're exporting more than 2,000 tickets a week, sample. Take every ticket from your top segment and a random 500 from the rest โ tell the model exactly what you sampled so the counts stay honest. The point of triage is direction, not census. You're looking for themes that deserve a closer look, not a research paper.
Prompt 1: The theme clustering prompt (the whole trick)
This is the foundation. Everything downstream โ sentiment shifts, segment splits, escalation flags โ runs on these clusters. The prompt asks for themes, volume, direction, and proof, in one pass:
THEME CLUSTER PROMPT: I'm pasting [N] support tickets from the past 7 days (subject + body + account ID + segment). Cluster them into 5โ10 themes based on the actual problem the customer is reporting โ not the words they use, the problem. For each theme: 1) a plain-English name, 2) ticket count and % of total, 3) 2โ3 representative quotes (verbatim, with account IDs), 4) the dominant sentiment (frustrated / confused / blocked / feature-request), 5) one sentence on whether this is a new theme or ongoing (compare against my pasted theme list from last week: [paste]). Do not merge distinct problems into one theme to hit the count range โ if there are 12 real themes, list 12. Flag any theme where a single account is more than 30% of the tickets.
The last instruction matters most. A theme that's 40 tickets from one account is a single escalation wearing a trench coat, and it should go to the CSM who owns that account, not the product roadmap. The prompt catches what dashboards miss: concentration, not just volume.
Prompt 2: The sentiment shift detector
Themes tell you what customers are talking about. Sentiment shifts tell you what's getting worse โ which is where churn lives. Run this monthly, or whenever a cluster from Prompt 1 looks angry:
SENTIMENT SHIFT PROMPT: Compare these two ticket sets: SET A (tickets from [last month], summarized themes below) and SET B (tickets from this month, pasted in full). For each theme present in both sets: has the sentiment improved, worsened, or held steady? Quote specific language that proves the direction โ I want to see the exact words, not your paraphrase. List themes that appear in SET B but not SET A (new pain), and themes that disappeared (resolved or renamed?). Rank the worsening themes by a combined score of volume ร sentiment severity ร account tier, and explain each ranking in one sentence. SET A themes: [paste].
The "quote specific language" line is the anti-hallucination guard. Sentiment is slippery, and models will happily tell you things got "slightly worse" with nothing behind it. Forcing verbatim evidence makes the shift defensible โ and it gives you the quotes you'll need in the memo anyway.
Prompt 3: The segment splitter
One company, many experiences. Your enterprise accounts and your self-serve long tail are not filing the same tickets, and treating the queue as one blob averages away the most important differences. This prompt splits the clusters by segment:
SEGMENT SPLIT PROMPT: Using the same ticket export, re-cluster by segment: [list your segments โ e.g., Enterprise, Mid-Market, Self-Serve]. For each segment, give me the top 3 themes by volume, and โ this is the point โ the themes that rank high in one segment but barely appear in another. For each segment-specific theme: is this a real segment need, or the same underlying problem described differently? Enterprise tickets: [paste subset or full export with segment column]. Output: a comparison table in markdown, theme names as rows, segments as columns, cell text = ticket count or "โ".
This is where you find the gold. Enterprise-only "confused" themes are almost always onboarding or documentation gaps that your highest-paying customers will pay to not experience. Self-serve-only "blocked" themes are product bugs your freemium funnel is silently absorbing. The asymmetries are the strategy.
Prompt 4: The daily escalation radar
Weekly themes catch trends. This one catches fires. Run it on each morning's new tickets โ or pipe it into an automation โ to flag the tickets that deserve a human before the queue gets to them:
ESCALATION RADAR PROMPT: I'm pasting today's new tickets (subject + body + account ID + account health score + plan). Flag any ticket that meets one of these: 1) language suggesting the customer is considering leaving ("cancel," "alternatives," "evaluating," or equivalent sentiment even without those words), 2) a repeat of a known unresolved issue for the same account (I'll paste the open-issues list: [paste]), 3) an executive or multi-user CC indicating the issue has been escalated internally by the customer, 4) sentiment markedly angrier than the customer's historical tone (if a ticket history is pasted: [optional]). For each flag: ticket ID, which rule fired, a 2-line summary of the situation, and the single best first action. Be aggressive about flagging โ I'd rather review a false positive than miss a fire. Miss nothing in rule 1.
Notice the last two sentences: the prompt explicitly sets the error preference. Models default to balanced judgment; triage is not the place for balance. You want the net wide, because a human reviews the flags anyway. Calibration is a weekly ten-minute job: look at what the radar flagged, mark the false positives, and tighten the prompt.
The 20-minute morning ritual
Prompts without a ritual are just a nice folder of markdown. Here's the actual routine:
Monday, 8:00. Export last week's tickets (PII-stripped, sampled if needed). Run the theme clustering prompt. Save the theme list โ you'll paste it into next week's prompt as the "last week" reference, which is what makes the trend line real.
Daily, first pass. Run the escalation radar on the morning's new tickets. Forward flags to the owning CSM or support lead with the model's suggested first action attached. The CSM still decides โ but they decide with a two-line brief instead of a cold inbox.
First Monday of the month. Run the sentiment shift and segment split prompts. This is the memo run. One page: top 5 themes by volume, the 2โ3 sentiment shifts that moved, the segment asymmetries, and โ for each โ the one recommended action with an owner. Send it to CS leadership and support leadership, same page, same meeting if you have one. That shared memo is doing quiet political work: tickets stop being "support's problem" and become the company's early-warning system.
What the model gets wrong (and the guardrails)
Four things, all fixable. First, counts. Models are notoriously sloppy at arithmetic โ "37 tickets" might be 34. Never quote a count in a memo without spot-checking it against the export's filter. The direction is what you need from the model; the precision comes from your spreadsheet.
Second, PII. Said it above, saying it again: strip names, emails, and phone numbers before anything touches a model. Build the strip into the export query, not into your discipline. Discipline fails at 8 a.m.; SQL doesn't.
Third, theme invention. A model asked to cluster will cluster โ even noise. The "past week's themes" reference you paste each week is the guardrail: it forces the model to compare against continuity instead of inventing fresh taxonomy every Monday. If a "new" theme shows up, make it prove it wasn't last week's theme wearing different words.
Fourth, the substitute-for-reading trap. Triage prompts don't replace reading tickets; they decide which tickets you read. Every week, read five tickets from the top theme yourself โ the model's representative quotes. The texture of customer language is where the real insight lives, and no summary preserves it. The prompts make reading scalable; they don't make it unnecessary.
Closing the loop (where this actually pays off)
The highest-value thing you can do with triage output isn't the memo. It's the follow-up to the customers who filed the loudest tickets. Every theme that makes the memo should get a response plan: a KB article for the confusion themes, a product update for the bug themes, and โ the part everyone skips โ a reply to the specific customers who reported it, telling them what changed. "You filed this in March, it's fixed in today's release" is a retention play disguised as a courtesy email. CSMs who own it per account; support leadership owns the public-facing version.
Track one metric for the whole system: theme-to-resolution time โ the days from when a theme first surfaces in triage to when the fix ships or the communication goes out. That number, falling month over month, is the proof that reading the tickets changed the company. Everything else is process.
Your tickets already contain next quarter's churn, written down by the customers themselves. Twenty minutes a week is all it takes to read them.
Tomorrow: the renewal countdown flow โ scheduling touchpoints 90 days out, with the checklist that makes sure nothing slips.
