Ticket trends and recurring root causes

Scope

Read the ticket history as a signal about the product, not as a workload. Two questions: what happened to volume and why, and which root causes recur often enough that fixing the cause would be cheaper than handling the tickets. Local data only; richer where a product-analytics or error-tracking integration is connected, but complete without one.

Procedure

1. Establish the shape of volume. Using the ticket data available to you, count tickets per day (or per week for a long window) over the last 90 days, and compare the most recent 30 against the preceding 30. Break the same series down by source (hubspot, zendesk, jira, slack, thread, manual). Say what normal looks like before saying anything is abnormal: give the typical daily range and the weekday/weekend pattern, so a "spike" is measured against a baseline the report actually printed.
2. Find the spikes. A day materially above the recent typical range is a candidate. Ignore ones fully explained by a change in a single source's ingest (a connector that was down for two days and then backfilled produces a fake spike — check for that before investigating a cause).
3. Anatomy of each real spike, in this order. For each: a. Composition — what were the tickets about? Cluster the spike day's tickets by root cause and subject; a spike is almost always one dominant cluster plus normal background. Name the dominant cluster and its share. b. Onset — when did the first ticket of that cluster arrive, to the hour? That timestamp, not the peak, is what any candidate cause has to precede. c. Candidate cause — look for something that changed just before the onset. Where source control or CI is connected, check deploys and merges in that window; where error tracking is connected, check for a new issue or a rate change starting at the same hour; where product analytics is connected, check whether a funnel step's conversion dropped at the same time. With none of those connected, say the correlation could not be tested and give the onset timestamp so a human can check it in minutes. d. Resolution — how did the cluster end: a fix, a workaround, or did the tickets simply stop arriving with no recorded resolution? The third case is the most important to flag, because the cause is still out there.
4. Recurring root causes across the whole window. Independently of spikes, group the investigated root causes over 90 days and rank by frequency and by total investigation effort. tickets__search_similar is the way to find the recurrences that are worded differently each time. For each recurring cause, record: how many tickets, over what span, whether it is accelerating, and whether the fix has ever been described as permanent in any investigation. A root cause that recurs monthly and is "fixed" every time is a signal that the real cause was never found — say that.
5. Chronic versus acute. Separate the two, because they need different owners. Acute is a spike with a cause and an end. Chronic is a steady trickle that never spikes and never stops — chronic causes are systematically under-noticed precisely because they never create a bad day, and adding up their annual ticket count is usually the most persuasive number in this report.
6. Look for what stopped. A cluster that used to arrive weekly and has not appeared in a month is worth recording too, both as a genuine win and as a prompt to check that the tickets are not simply being lost before they reach the queue.
7. Cost the top causes. For each recurring cause, multiply ticket count by the typical resolution time to give a rough handling cost over the window. Say plainly that it is an estimate; it exists to rank causes against each other, not to be quoted as a budget figure.

Finding keys

The key names the cause or pattern, not a date or a spike, so a chronic cause keeps one ledger row across months and closes when it genuinely stops. Give each recurring cause a stable slug and reuse it; a spike gets a key only when it turned out to have an unresolved cause worth tracking.

• cause:payout-bank-verification:recurring
• cause:oauth-token-expiry:chronic
• spike:checkout-declines:unresolved-cause
• trend:volume:rising-30d
• source:slack:ingest-gap

Severity rubric

Severity is about the cause's ongoing cost and the risk it repeats, not about how loud the spike was.

• critical — a spike whose cause was never identified and whose tickets simply stopped arriving; or a recurring cause that is accelerating and customer-visible.
• high — a chronic cause among the top few by handling cost that no fix has ever addressed; a sustained rise in volume with no explanation.
• medium — a recurring cause with a known workaround but no permanent fix; a spike that was explained and resolved but could recur because nothing changed.
• low — small recurring annoyances, seasonal or expected variation worth recording.
• info — the baseline itself, resolved trends, and clusters that stopped — recorded so the next run can compare.

Output guidance

Open with a one-paragraph executive summary in plain words: volume this period versus last, the number of spikes and whether their causes were found, and the single recurring cause costing the most. Then: a Volume section that prints the baseline before any anomaly claim, a section per spike following the composition / onset / candidate cause / resolution structure with the onset timestamp stated exactly, a Recurring root causes table (Cause | Tickets | Span | Accelerating? | Estimated handling cost | Ever permanently fixed?), and a short What stopped section. Close with a recommendations table (Cause | Recommended fix | Who owns it | Tickets avoided per month). Distinguish everywhere between what the data shows and what you inferred, and where a correlation could not be tested because nothing is connected, say so and give the timestamp a human needs.