Support ticket analysis

Support ticket analysis starts with an export, and most of the errors start there too. Pull one row per ticket, with the ticket ID kept on every row from start to finish. Every number in the final readout should be traceable to a list of IDs that someone can open.

Zendesk

From the Tickets API you need id, created_at, status, via (the channel the ticket came in on), subject, description (the first comment), tags, group_id, assignee_id, custom_fields and satisfaction_rating. Status is one of new, open, pending, hold, solved or closed.

The timings live in a separate Ticket Metrics object: reply_time_in_minutes, first_resolution_time_in_minutes and full_resolution_time_in_minutes, each measured in both calendar and business hours, plus reopens, group_stations (how many groups the ticket passed through), assignee_stations and solved_at. For a full history, the incremental ticket export (/api/v2/incremental/tickets/cursor) pages through every ticket, and Zendesk documents sideloading the metrics with include=metric_sets. If you work in Explore instead, the Support - Tickets dataset has first reply and resolution times too.

Intercom

Each conversation has id, created_at, state (open, closed or snoozed), source (the first message), tags, team_assignee_id, admin_assignee_id, conversation_rating and ai_agent_participated. The timings sit in a statistics object: time_to_admin_reply, time_to_first_close, time_to_last_close, median_time_to_reply, count_reopens and count_assignments.

Two details matter. Intercom's durations are in seconds and already subtract time outside office hours. And they are measured from first_contact_reply_at, the customer's first message, so an outbound message nobody answered has no statistics at all. Filter those out before you count anything.

Zendesk reports minutes, Intercom seconds. Zendesk gives you calendar and business hours; Intercom gives you office hours only. If you ever combine the two, convert both and say which clock you used.

1. Volume by contact reason. Tickets per reason, with each reason's share of the total. This is the number product teams care about most, and the hardest to get right (see the next section).

2. First reply time. How long a customer waited for a human's first answer. Report the median, and the 90th percentile next to it.

3. Resolution time. Time to solved (Zendesk's full resolution time, or Intercom's time to last close). Again, the median.

4. Escalation rate. Escalated tickets ÷ all tickets. There is no standard definition, so pick one and print it: a ticket that passed through more than one group (group_stations > 1 in Zendesk), a ticket moved to a named tier-2 or engineering group, or a ticket carrying an escalated tag. Intercom's count_assignments is a looser proxy, since a reassignment inside one team counts too.

5. Reopen rate. Solved tickets with at least one reopen ÷ solved tickets. Zendesk's reopens and Intercom's count_reopens both give you the count.

6. The arrival heatmap. Tickets created by weekday and hour. Zendesk's own Explore recipe builds exactly this grid, with median first reply time in each cell, so you can see whether slow replies follow the busy hours or the thinly staffed ones.

Why the median, not the mean

Resolution times are skewed: most tickets close within hours, and a few sit open for weeks. Take nine tickets resolved in 0.5, 1, 1.5, 2, 2, 3, 4, 6 and 72 hours. The mean is 10.2 hours. The median is 2. One stuck ticket moved the mean fivefold, and a mean-based target would have you chasing it while telling you nothing about the typical customer. NIST's engineering statistics handbook puts it plainly: for data with extreme values in the tails, the median is the better estimate of the typical value. Keep the mean out of the readout, and list the long-tail tickets by ID instead.

A worked example

Here is a month for a software company with 4,200 tickets. The figures are invented to show the layout, not as a benchmark.

Billing is the biggest pile, but it's quick and rarely comes back. Data import errors are fewer, slower and reopen almost one time in seven. That second row is the one to take to product.

Agent-applied tags are rarely good enough for this. Macros add tags automatically, agents pick whichever tag is quickest, and "other" quietly becomes the largest category. Reading the ticket text is better, and it's a task language models do well: Anthropic's own ticket routing guide covers classifying support tickets by intent with Claude.

What makes the tagging trustworthy is the setup around it:

• Write the rules first. For each reason, one line on what's in and what's out. "Login and access: can't sign in, SSO, 2FA, locked accounts. Not: billing-related account suspension."
• Allow "Not themed". A model told to pick one of six reasons will force a ticket into the nearest one. Give it a way out.
• Ask for the evidence. For each ticket, the reason plus the sentence that decided it.
• Keep the ticket ID on every row. Without it, nobody can check the tagging, and the counts become a matter of trust.

How to check the tagging

1. Draw a sample. Take 200 tickets at random, stratified so each reason has at least 20.
2. Label them blind. Someone on the support team tags the sample using the same rules, without seeing Claude's answer.
3. Measure agreement. Report percent agreement, and Cohen's kappa, which corrects for agreement by chance: κ = (pₒ − pₑ) ÷ (1 − pₑ). Say you agree on 172 of 200 (pₒ = 0.86) and chance agreement from the label mix is 0.24. Kappa is (0.86 − 0.24) ÷ 0.76 = 0.82. McHugh's review of the statistic in Biochemia Medica recommends reporting both and treats any kappa below 0.60 as inadequate.
4. Read the disagreements. They usually cluster in one or two pairs of reasons, such as "bug" against "how-to". Fix the rule, not the individual ticket.
5. Re-check on a fresh sample. Run it again whenever you change the rules, ship a big release or add a channel.

Keep the sample, the labels and the IDs. When someone in a product review asks how you know import errors doubled, you can show them.

Hand Claude a ticket export and ask for "an analysis", and you'll get a confident summary with averages, a top-five list and no way to check any of it. The prompt below asks for the opposite: one table, stated definitions, and the ticket IDs behind every cell.

It works on a CSV, through Intercom's connector (see Claude connectors), or against a warehouse table through Count's MCP server, which lets Claude query your data and show the query behind each number.

Analyse our support tickets created from [start date] to [end date],
in [time zone]. Read only: don't change, tag or reply to any ticket.

1. Retrieve every ticket in the period. Page until there's no next
   page, and report how many you retrieved.
2. Exclude spam, merged tickets and outbound messages the customer
   never answered. Give the count for each exclusion with five IDs.
3. Give each ticket one contact reason using these rules, and quote
   the sentence that decided it. Tickets that fit none go in
   "Not themed":
   [reason: what's in / what's out]
4. Build one table by contact reason: tickets, share, median and 90th
   percentile first reply time, median resolution time, escalation
   rate, reopen rate. Medians, not means. Say whether times are
   calendar or business hours.
5. Escalated means [group_stations > 1 / tagged "escalated"].
   Reopened means at least one reopen.
6. Build a heatmap of tickets created by weekday and hour, in
   [time zone].
7. For every number in the table, keep the list of ticket IDs it was
   calculated from, and give me that list as a file.
8. Pick 30 tickets at random, stratified by reason, and list their IDs
   without your labels, so I can tag them blind.
9. Show every query, filter and piece of code you used.

Don't explain why a reason grew unless the tickets say so.

Step 8 is the one people skip. It turns a check into a five-minute job, and it's the difference between "Claude says" and "we checked". For more on that habit, see how to check AI answers.

In Count, each figure comes with its Reasoning Chain: the query, the filters and the rows behind it, so the IDs travel with the number. The two workflows below go further: one sorts conversations into themes and matches them to open issues, the other turns ticket volume into a staffing plan.

Support conversations are the largest pile of product feedback most teams have, and the least read. Claude can read all of them through Intercom's connector, sort them into themes with written rules, count each theme against the previous period and match it to the issue already open in Linear or Jira. Zendesk has no generally available official connector yet, so Zendesk teams export a view as CSV.

Sort our support conversations from [date] to [date] into themes, and
compare them with the [same length] period before.

1. From Intercom, search conversations in both periods. Page through
   every result until there's no next page. Report how many you
   retrieved for each period and confirm none were left.
2. Read each conversation's first customer message and the agent's
   reply. Assign it to one theme using written rules: give the rule for
   each theme (what's in, what's out) before the counts.
3. Conversations that fit no theme go in "Not themed". Don't force
   them into the nearest theme.
4. Build one table: theme, conversations this period, previous period,
   change (%), share of all conversations. Shares add up to 100%.
5. Say clearly that these are conversations, not customers. If you can
   count distinct companies per theme, add that column.
6. For each theme, search Linear for an open issue that matches it and
   give its ID, or "None".
7. Link five example conversations for each theme.
8. Show the search filters and the code you used for the counts.

Don't explain why a theme grew unless the conversations say so. Read
only: don't add notes or tags in Intercom or create issues in Linear.

Capacity planning is arithmetic on three numbers: how many tickets are coming, how long each takes, and how many productive hours an agent has. Claude is quick at the arithmetic. The risk is the inputs, because a model will fill a missing shrinkage rate or handle time with one it remembers. This workflow takes every input from your files and shows the plan's sensitivity to the one you're least sure of.

Plan support staffing for [Q1 2027].

1. From the attached Zendesk export, take tickets created per ISO week
   for the last 12 months. Report the weeks you got and any missing.
2. Forecast weekly tickets for each month of the quarter: the same
   month last year, times the year-on-year growth of the last full
   quarter. Show the growth calculation.
3. Read handle time and shrinkage from the project instructions. If
   either is missing, stop and ask me. Don't use a benchmark.
4. Productive hours per FTE per week = contracted hours x (1 -
   shrinkage). Required FTE = weekly tickets x handle time / productive
   hours.
5. From [roster sheet], count FTE available each month after planned
   leave. FTE = contracted hours / [37.5].
6. Build one table: month, forecast tickets a week, hours needed,
   required FTE, rostered FTE, gap. Then a dashboard: required against
   rostered FTE by month, and tiles for the largest gap.
7. Show how the largest gap changes if shrinkage is 5 points higher or
   lower, and if handle time is 2 minutes longer or shorter.
8. Don't recommend hiring, overtime or outsourcing. List the gaps; the
   decision is ours.

Show the code for every calculation and the cells you read.

The same analysis makes two different documents.

For product, lead with reasons that point at the product: bugs, import errors, confusing settings. For each one, give the count this period and last, the reopen rate, the linked issue if one exists, and five example tickets with a quoted line each. Product managers act on a sentence from a customer far faster than on a percentage. Count conversations, not customers, and say so; one account with a broken integration can file forty tickets.

For leadership, keep it to one page:

• Ticket volume against the previous period, and per 1,000 active customers if you have that number, so growth in customers isn't mistaken for a worse product.
• Median and 90th percentile first reply and resolution time, against your own targets.
• Escalation and reopen rates, with the definition in a footnote.
• The three reasons that moved most, and who owns each.
• What tickets can't tell you. Customers who leave without writing in don't show up here.

Put the ticket ID lists in an appendix or a linked sheet. They rarely get opened. When they do, it's because someone doubts a number, and that's exactly the moment you need them. The business operations guide covers the weekly review this readout usually feeds.

Open tickets drop out of resolution time. Only solved tickets have a resolution time, so last week always looks fast: its slow tickets are still open. Report resolution time by the week tickets were created, and say how many are still open.

Merged and spam tickets inflate volume. Exclude them, and report how many you excluded.

Bots change what "first reply" means. If an AI agent answers first, decide whether that counts. Intercom marks these conversations with ai_agent_participated.

Calendar and business hours get mixed. A 16-hour first reply in calendar time can be 1 hour in business time. Pick one per report.

Time zones move the heatmap. API timestamps are in UTC. Convert to your team's local time, and watch the weeks where the clocks change.

The mix shifts. If median first reply time improved because billing questions (fast) grew while bug reports (slow) shrank, nothing got better. Compare reasons with themselves, period on period, before you compare the total.