Zendesk Problem and Incident Ticket Report: Measure Blast Radius

Last updated: August 09, 2026

Zendesk Problem and Incident Ticket Report

Ticket volume tells you how much work arrived. It does not tell you how much of that work came from the same underlying fault — and that distinction decides whether the answer is more agents or one engineering fix.

Zendesk already models this. The ticket type field marks a ticket as Question, Incident, Problem, or Task, and incidents can be linked to a problem ticket so that solving the problem solves every incident attached to it. Most teams use the workflow during outages and then never report on it, which means the single cleanest measure of root-cause impact in the whole product sits unused.

This guide builds that report in Explore, covers the attribute trap that catches almost everyone on the first attempt, and shows how to turn incidents-per-problem into an argument for fixing something upstream.

What this report should answer

  • Which problems generated the most incident tickets?
  • Which problems still have unsolved incidents attached right now?
  • How much support labour would one root-cause fix have removed?
  • Are incidents linked at all, or is the workflow being skipped?
  • Is our ticket mix shifting toward incidents over time?

See incidents per problem for the metric and ticket volume for the baseline it should be read against. Keep this beside the support metrics dashboard so root-cause load is visible next to inflow.

This is the mistake that breaks most first attempts, so it is worth being explicit.

Ticket type tells you whether a ticket is a problem or an incident. It does not tell you whether an incident is linked to a problem. Filtering to Ticket type = Incident returns every incident in your account, including hundreds that were never attached to anything.

The link lives in a different attribute: Ticket problem ID, which returns the ID of the problem ticket an incident is attached to. If it has a value, the incident is linked. If it is null, it is not.

Every report below therefore does two things: uses Ticket problem ID as the grouping attribute, and excludes null values so unlinked incidents do not collapse into one meaningless row.

Both attributes live in the Support - Tickets dataset. Ticket problem ID also appears in the SLAs and Copilot datasets, so you can carry the same analysis into SLA and AI reporting later.

How to build the report in Zendesk Explore

1. Incidents per problem

  1. In Explore, open Reports > New report, choose Support > Support - Tickets, and click Start report.
  2. In Metrics, add Tickets > Incidents. This metric counts tickets where ticket type is Incident.
  3. In Rows, add Ticket > Ticket problem ID.
  4. Click the Ticket problem ID attribute, open the Excluded tab, and select Null.
  5. Apply a top/bottom filter to show the top 10 or 20 problem IDs.

You now have your blast-radius ranking: one row per problem, ordered by how many customers it affected.

Problem IDs are not readable, which limits how far this report travels. Add Ticket subject to Rows for context, or maintain a lightweight lookup for the problems worth naming. Some teams also apply a tag to each problem ticket so the report can group by a human-readable label — see Zendesk Tags Analysis Guide.

2. Unsolved incidents by problem

The version above is retrospective. This one is operational: which problems still have customers waiting.

Create a standard calculated metric named Unsolved incidents:

IF ([Ticket type - Unsorted] = "Incident"
  AND (([Ticket status - Unsorted] != "Solved")
  AND ([Ticket status - Unsorted] != "Closed")))
THEN [Ticket ID] ENDIF

Add it alongside Incidents, keep Ticket problem ID in Rows with nulls excluded, and set the aggregator to COUNT. Then add a result metric calculation for the ratio of unsolved incidents to total incidents, displayed as a percentage.

Two readings, both useful:

  • High unsolved count — the problem is live and customers are still affected. Work it now.
  • High unsolved percentage on an old problem — the problem ticket was solved but its incidents were not closed out, or new incidents keep attaching to a fault that was never actually fixed.

That second pattern is the one worth building an alert around. It is how a “resolved” outage keeps generating tickets for weeks.

3. Ticket type mix over time

Zoom out to the whole account. Add Incidents, Problems, and Tickets as metrics with Time - Ticket created by week in Columns.

Report incidents as a share of total tickets, not as a count. A rising incident share means a larger portion of your demand is fault-driven rather than question-driven — a materially different queue that rewards fewer agents and more engineering escalation. A rising question share points the other way, toward self-service and help centre work. See Zendesk Ticket Deflection Report.

Also watch the problem count itself. If problems climb while incidents-per-problem falls, the team is opening a problem ticket per report rather than clustering — the workflow is being followed in form but not in substance.

4. Cost of the root cause

This is the view that makes the report useful outside support.

Filter to one problem ID, then add:

  • Full resolution time (min) with a SUM aggregator — total support hours consumed by that one fault
  • Replies per ticket or agent replies — how much conversation each incident required
  • Bad satisfaction tickets — customer damage
  • Ticket organization name — which accounts were hit, and whether any were strategic

Multiply summed handle time by your loaded cost per hour and you have a defensible figure for what one unfixed root cause cost the business. Pair with Zendesk Cost per Ticket and Zendesk Cost per Resolution Report.

Support teams that get engineering attention for reliability work almost always do it with a number like this rather than with a description of the pain.

5. Linkage rate — is the workflow being used?

Before trusting any of the above, measure whether incidents are actually being linked.

Create two calculated metrics: incidents with a non-null Ticket problem ID, and incidents with a null one. Report the linked share by group and by week.

If linkage is low, your blast-radius numbers understate reality by however much the workflow was skipped, and the fix is process and agent enablement rather than analysis. Low linkage is extremely common — the workflow depends on an agent recognising that a ticket belongs to a known fault, which is exactly the judgement call that gets skipped during a spike.

Where the ticket type field breaks down

Two honest limitations to plan around.

Ticket type is a current-state field. It reflects what the ticket is now, not what it was when created. A ticket that arrives as a Question and is later reclassified as an Incident is counted as an Incident for its whole history. Your incident share is therefore a snapshot of present classification, which is fine for trend analysis but not for point-in-time reconstruction. The Updates history dataset is the place to go if you genuinely need to know when reclassification happened.

Linking is retrospective. Incidents are usually attached after someone identifies the pattern, so the first wave of tickets for a new fault often stays unlinked. Expect the earliest incidents in any problem cluster to be undercounted, and treat the first hour of any incident as structurally missing from this report. For catching the spike itself, use Zendesk Ticket Volume Report and tag-based detection instead.

Also worth separating in your head: merges and problem links are different operations. Merging removes duplicate volume; linking preserves each customer’s ticket while grouping the cause. If your team merges duplicates during outages, those customers disappear from incident counts entirely — see Zendesk Merged Tickets Report.

How to interpret the patterns

A few problems generate most incidents

The classic and most actionable finding. This is a reliability or product-quality issue being absorbed as support labour, and the fix belongs upstream. Take the top three problems to your engineering review with summed handle time attached.

Many problems, few incidents each

Either your faults are genuinely diverse, or agents are opening a problem ticket per report instead of clustering. Check whether several problem tickets share a subject or tag — if they do, it is a workflow issue.

High incident volume, almost nothing linked

The workflow is not being used. Analysis will not help; enablement will. Consider a trigger or macro that prompts linking when a ticket matches a known-fault tag.

Incident share rising while total volume is flat

Demand is shifting from questions to faults. This changes what the team needs — more escalation paths and status communication, less self-service content. It often precedes a CSAT dip driven by “the issue was not resolved” — see Zendesk Satisfaction Reason Report.

Unsolved incidents persist after the problem is solved

Solving a problem ticket is meant to solve its linked incidents. If unsolved incidents remain, either they were attached after the problem was solved, or the underlying fault recurred. Check created dates against the problem’s solved date before concluding anything.

Incidents concentrated in one organization

Not a fleet-wide fault but a configuration or integration issue specific to that account. Cross-check Zendesk Tickets per Organization Report before treating it as a general reliability problem.

Common mistakes

  • Using Ticket type to find linked incidents. It only identifies what a ticket is, not what it is attached to. Use Ticket problem ID.
  • Forgetting to exclude nulls. Every unlinked incident lands in one row and dominates the chart.
  • Reading incident counts without linkage rate. Low linkage means your numbers understate reality by an unknown margin.
  • Treating problem IDs as readable. Add subject or a tag so the report can be shared.
  • Ignoring merges. Merged duplicates never appear as incidents, so heavy merging hides blast radius.
  • Assuming type was always what it is now. Type is current state; reclassification rewrites history.
  • Counting incidents but not their cost. Summed handle time is what moves an engineering conversation.
  • Expecting to catch spikes here. Linking lags the spike; use volume and tag monitoring for detection.

What to do when one problem dominates

  1. Confirm linkage rate is high enough for the count to be meaningful.
  2. Sum full resolution time across the problem’s incidents to get the labour cost.
  3. Add organization to see whether commercial exposure is concentrated.
  4. Check unsolved incidents to see whether customers are still affected.
  5. Check whether the fault is recurring — new incidents attaching after the problem was solved.
  6. Take cost, customer count, and affected accounts to the owning engineering team as one package.
  7. Add a tag for the fault so future recurrences are detectable before anyone opens a problem ticket.
  8. Re-measure incident share after the fix ships.

Where this report fits in your dashboard

FAQ

Which attribute links an incident to a problem? Ticket problem ID in the Support - Tickets dataset. Ticket type only tells you whether a ticket is a Problem or an Incident, not whether it is linked.

Why does my report have one giant row? You did not exclude null values on Ticket problem ID. Every unlinked incident shares a null value and collapses into a single row.

How do I count only incidents that are still open? Create a calculated metric filtering ticket type to Incident and ticket status to anything other than Solved or Closed, then group by Ticket problem ID.

Can I report on the problem ticket’s own metrics from the incident rows? No. Ticket problem ID identifies the parent but does not give you access to the parent’s metrics. Report on the problem ticket separately.

Does solving a problem ticket solve its incidents? Yes, that is the point of the workflow — solving the problem solves linked incidents. Incidents attached after the problem was solved stay open.

Should we merge duplicates or link them as incidents? Link when each customer needs their own updates and you want blast radius measured. Merge when the tickets are genuinely the same request from the same person.

See which root causes generate the most Zendesk load - start free