Zendesk Problem vs Incident
One cause, many reports. Zendesk problem vs incident is the built-in way to model that, and most teams either never use it or use it for the wrong thing.
Zendesk problem vs incident, and the other two ticket types
Zendesk ships with four values in the Type field, and two of them are related to each other.
Question and Task are labels. Problem and Incident are structural: an incident can be linked to a problem, and that link changes what happens when the problem is solved. That is the only place in core Zendesk where the Type field does something rather than just describing something.
How the linking works
Create the problem ticket first. One record describing the actual fault: "checkout fails for customers paying in euros". It doesn't need to be a customer's ticket, and often it is better if it's not. An agent or admin can raise it directly.
Then set each incoming report to type Incident and point it at that problem. The field appears once the type is set. From then on the incidents are children of that problem in a way Zendesk understands.
When you solve the problem ticket, Zendesk offers to solve every linked incident with it, and to send the same comment to all of them. That's the payoff. One properly written explanation, sent once, closing forty tickets, with every requester keeping their own record and their own reply.
Write that comment carefully. It is going to forty different people who each described the fault in their own words, so it needs to stand on its own without referencing anything specific to one reporter.
Incident linking versus merging
These solve neighbouring problems and the difference is worth being precise about.
Link as incidents when different customers report the same fault. Each person keeps their own ticket, their own CSAT survey and their own reply. Nobody's conversation is absorbed into a stranger's.
Merge when the same person raised the same request more than once, by email and then through the form, or twice in one afternoon. There is only one conversation there and it should live in one place.
Getting this backwards causes real damage. Merging forty customers into one ticket destroys thirty-nine conversations, and in Zendesk merges are permanent. Linking two tickets from one person as incidents of a problem leaves you with a duplicate you have documented rather than resolved.
Where teams get it wrong
Making it work under pressure
During an outage nobody has time to read documentation, so decide the mechanics in advance.
Agree who raises the problem ticket, usually whoever is on incident duty. Agree a naming convention so agents can find it in the linking search box in three seconds rather than thirty. Prepare a macro that sets type to Incident and applies your outage tag, so tier one can classify without thinking.
Then report on it afterwards. Counting incidents per problem is one of the few numbers that translates directly for an engineering team: this defect generated sixty-one customer contacts. That is a more persuasive sentence than any severity label.
For the related but different structure of parent and child work, see child tickets and linked tickets.
Frequently asked questions
What does a Zendesk incident ticket actually do?
A Zendesk incident ticket links to a problem ticket, and solving the problem closes every incident attached with the same public reply. That's the entire mechanic, and it's what makes outages survivable.
What is the difference between a problem and an incident in Zendesk?
A problem is the underlying fault, an incident is one customer's report of it. Incidents link to a problem, and solving the problem can solve every linked incident at once.
How do I link an incident to a problem in Zendesk?
Set the ticket type to Incident, then choose the problem ticket in the field that appears. The problem ticket has to exist first.
Does solving a problem close all its incidents?
Zendesk offers to solve the linked incidents and send them a shared comment. Write that comment so it reads sensibly to every requester, not just the first one.
Should I merge duplicate tickets or link them as incidents?
Merge when one person raised the same thing more than once. Link as incidents when different people reported the same fault, so each keeps their own conversation and reply.
Can an incident have more than one problem?
No. An incident points at a single problem ticket. If a customer is hit by two separate faults, that is two tickets or one ticket handled outside the pattern.
Same fault, or the same person twice
Incident links handle many customers with one fault. Ticket Merger handles one customer with several tickets.
Start free trial14-day free trial. No credit card required.