How to Make a Support Ticket Report: Step by Step

A support ticket report is mostly a definitions problem. Tickets created, tickets solved, first reply time, and resolution time all sound self-explanatory. Every one of them has more than one official meaning inside the same help desk.

Get the counting rules stated and the report writes itself. Skip that step and two honest people will pull the same export and disagree by hours.

This guide covers what belongs in the report, the four places the definitions fork, and how to build it from a ticket export.

What belongs in a support ticket report

Volume alone tells you almost nothing. The arrangement is what makes the numbers safe to read.

Element	Why it is there
Tickets created in the period	The demand side
Tickets solved in the period	The supply side, on a stated status rule
Backlog at period end	Everything not solved or closed
First reply time	On a stated clock and a stated definition
Resolution time	First or full, named explicitly
Reopened tickets	The quality signal the other numbers hide
Unreplied tickets	Where the process failed outright
A stated date basis and scope	Which channels, brands, and queues are included

Two rows carry more weight than their size suggests. Reopened and unreplied tickets are where a report stops being a scoreboard and becomes useful.

Zendesk publishes the underlying formulas, which makes the definitions checkable rather than a matter of opinion. Its metrics and attributes reference gives each one.

Start with the simplest. Solved tickets is "the number of solved or closed tickets," so the metric spans two statuses rather than one.

"First reply time" has two official definitions

This is the fork that causes the most disagreement, and the vendor warns about it directly.

Zendesk's SLA documentation says it in one line: "Do not confuse SLA reply time with the native Zendesk reply time metric."

The native metric is strict about who replies. Zendesk states that "first reply time is calculated exclusively based on agent replies." Automated and bot-related actions "aren't considered when calculating the first reply time."

The SLA metric is not. There, first reply time is "the time between ticket creation and the first public comment from an agent (or autoreply)." Zendesk adds that "reply time metrics are fulfilled if you set up a trigger to autoreply with a public comment."

Read those two together and the consequence is stark. An autoresponder can satisfy your SLA target while the native first reply time keeps running.

So a report showing 98% SLA attainment and a four-hour median first reply is not contradicting itself. It is reporting two different things, both correctly.

There are two smaller exceptions worth knowing. Take the case where an agent creates the ticket and the first comment is public. The duration metrics reference says the second timestamp "shifts to the second public agent comment."

And shared tickets do not count. Zendesk notes that when an agent comments publicly from another account using ticket sharing, "this doesn't count toward your account's first reply time."

"Resolution time" also has two

The same split runs through the resolution metrics, and here both versions ship by default.

First resolution time is the "duration between ticket creation and its first resolution," ending at "the first time the ticket status is set to solved."

Full resolution time is the "duration between ticket creation and its most recent resolution." It ends at "the last time the ticket status was set to solved."

For a ticket solved once, the two are identical. For a ticket solved, reopened, and solved again, they diverge by however long the second round took.

That is exactly why reopened tickets belong in the report. Zendesk defines them as tickets "reopened after being solved," and notes the metric "doesn't include tickets solved and reopened during the same update."

There is a second-order effect people miss. The daily average of solved tickets counts them "only if they are currently solved or closed." So a ticket reopened today quietly leaves last month's solved count.

A report you ran in June will therefore not reproduce in August. Nothing broke; the underlying status changed.

Two more metrics separate waiting from working. Requester wait time is the combined time in the new, open, and on-hold statuses, and agent wait time is the combined time in pending.

That pair answers the question a resolution average cannot. Long resolution times caused by waiting on the customer are a different problem from long resolution times caused by queue depth.

Calendar hours or business hours

Every reply and resolution figure exists on two clocks, and choosing one is not optional.

Zendesk stores both. After the first public reply, "the system calculates the first reply time in calendar hours and business hours." Both metrics "are stored with the ticket data."

The default you see is not neutral. Zendesk notes that pre-built Explore reports "display information on pre-built reports in calendar hours." Business hours metrics "are available and can be used in your own reports."

So a team working nine to five will look slow on the default report. A ticket arriving at 6pm Friday carries roughly 63 calendar hours before Monday morning, and close to zero business hours.

Live conversation channels add one more wrinkle. The First reply time (sec) metric for messaging and chat "ignores your messaging business hours and live chat operating hours settings."

And chat reply-time SLAs are opt-in. Zendesk states that reply time SLAs for live chat "are turned off by default," so their absence is a configuration state rather than perfect performance.

How to do it manually

Option 1: One tab per metric family

Export the ticket list with metric fields, then split volume, reply time, and resolution time onto separate tabs before summarising anything.

Keep the calendar and business hour columns side by side rather than picking one at export time. You will be asked for the other one.

Compute medians rather than means for the time metrics. A handful of tickets left open over a holiday will drag an average somewhere no ticket actually sits.

The ceiling is that a spreadsheet cannot see status history. You get the current state of each ticket, so reopen behaviour has to come from the reopened count rather than from reconstruction.

Option 2: A definitions tab, written first

Record the reply time definition, the clock, the resolution metric, the status rule for solved, the channels in scope, and the date basis.

Then record what the report does not claim. Writing down that SLA attainment and native first reply time measure different things stops a well-meaning colleague from quoting them as one number.

The limit is the usual one. Documenting a rule does not apply it, and next quarter somebody rebuilds the pivot from memory.

Option 3: Segment before you average

Split by channel before computing any time metric. Email, chat, and phone tickets have different physics, and a blended median describes none of them.

Then exclude or flag the tickets that distort. Tickets awaiting customer response for weeks belong in their own line rather than inside the resolution average.

Show what you excluded and how many there were. A reader who cannot see the filter will assume there was none.

The limitation is that segmentation multiplies the work. Three channels times two clocks times two resolution metrics is twelve numbers to keep straight.

The shared ceiling. All three assume the export covers one date range on one date basis for every queue. Mixed ranges across tabs is the most common silent error in this report.

Where the manual route slows down

The first support ticket report takes an afternoon. The fourth takes longer, because the help desk changed underneath it.

A new channel gets switched on, so the blended median moves for reasons unrelated to performance. Business hours get edited for a new region, and every historical business-hour figure shifts with them.

Then the reopen effect arrives. Last quarter's numbers no longer reproduce, and explaining why takes longer than rebuilding the report.

There is a fourth cost that only shows up under pressure. Someone asks whether support got faster this quarter. An honest answer needs the clock, the definition, and the channel mix stated first.

For the satisfaction side of the same picture, see our guide to creating an NPS report. If the volume itself is the problem, our walkthrough on building an AI agent for pre-sales customer support covers the deflection side.

How to build it with Powerdrill Bloom

Step 1: Upload your ticket export

Upload the ticket export, or the ticket and SLA exports together. Powerdrill Bloom profiles the columns on arrival, so blank timestamps, mixed date formats, and tickets missing a first reply surface before any median is computed.

Step 2: Describe the report in natural language

State the definitions rather than rebuilding them. Name the reply time definition, the clock, which resolution metric you want, the status rule for solved, and the channels in scope.

Then ask the questions that catch the errors. Ask how many tickets have no agent reply at all. Ask which tickets were reopened. Ask for medians per channel rather than one blended figure.

Step 3: Export the chart, report, or deck

Take out the metric table per channel, or a chart of created against solved with backlog behind it. Slides that carry the definitions beside the numbers come out of the same run.

Common mistakes

Quoting SLA attainment as first reply time. One accepts an autoreply and the other excludes automated actions entirely.

Comparing calendar hours to business hours. The default report gives you the first, and your target was probably set on the second.

Using the mean for reply and resolution times. A few abandoned tickets move an average to a place no real ticket occupies.

Blending channels. Chat and email medians differ by design, and the blend hides both.

Reporting resolution time without saying which one. First and full resolution time are separate stored metrics, not rounding variants.

Treating a solved count as final. Solved counts include only tickets currently solved or closed, so reopens change the past.

Leaving unreplied tickets out. They are defined as tickets with fewer than one agent reply, and they are the clearest failure the report can surface.

Conclusion

Name the reply definition, name the clock, pick first or full resolution, state the status rule, segment by channel, and show reopens and unreplied tickets. That produces a support ticket report someone can act on.

What the report may not do is compare cleanly to another company's numbers. The definitions are configurable, so a benchmark you read somewhere was almost certainly measured differently.

Track it against your own history instead, on a fixed set of rules. That is the version that tells you whether anything actually improved.

If rebuilding it every month eats a day, try Powerdrill Bloom on your ticket export. See also the AI report generator page and the voice of customer summarizer.

Frequently asked questions

Why does my SLA attainment not match my first reply time?

They measure different events. Zendesk's SLA first reply time can be fulfilled by an autoreply, while the native first reply time metric excludes automated and bot actions entirely.

Should I report first resolution time or full resolution time?

Report whichever you name. First resolution time ends at the first time a ticket is set to solved. Full resolution time ends at the last, so reopened tickets separate the two.

Are support metrics measured in calendar or business hours?

Both are stored. Zendesk's pre-built Explore reports display calendar hours, and business hours metrics are available for reports you build yourself.

Why did last quarter's solved count change?

Solved counts include tickets that are currently solved or closed. A ticket reopened after the period ends drops out of that period's count.

Can I compare my resolution time to an industry benchmark?

Only loosely. The definitions, the clock, and the channel mix are all configurable, so a published figure was probably measured on different rules than yours.