Picture three tickets from the same business client, a week apart. Each one says the overnight export did not arrive. Each time, the first line, the support team that answers tickets first, checks it, sends the export by hand and closes the ticket as resolved.
All three closures were correct. None of them fixed anything. Each ticket was the same recurring incident with one cause behind it, and because it arrived under a new ticket number every time, it was handled as new every time.
A recurring incident looks new every time
A help desk counts tickets. It does not count causes. When the same fault comes back, it comes back with a new number, a new timestamp and sometimes a new person at the client writing it. Unless someone links it to the earlier tickets, the queue shows three small incidents, each answered on time, and nothing that says the same thing broke three times.
That is how a recurring incident survives good support. Every single ticket was handled well. The pattern sits in no single ticket, so no one is assigned to it.
Closing an incident is not fixing the problem
IT service management treats them as two different things. Atlassian's guide to problem management quotes the definition from ITIL, a framework of practices for IT service management: a problem is "a cause, or potential cause, of one or more incidents." An incident, in the ITIL wording the guide also gives, is "an unplanned interruption to an IT service or reduction in the quality of an IT service." The problem is what produced it.
The same guide gives the example that settles it. Rolling back a recent deploy can get the service working again and end the incident, "but the underlying problem remains." The ticket closes. The cause stays.
In practice, the difference looks like this:
| Incident | Problem | |
|---|---|---|
| What it is | An unplanned interruption, or a drop in quality, of a service | Whatever caused, or could cause, those incidents |
| It ends when | The service works again | The cause is removed |
| Who acts on it | The support line that received it | The team that owns the system that failed |
| What closes it | The service restored | A change that stops the incidents coming back |
One more term sits inside problem management: the known error. In ITIL, as Atlassian quotes it, a known error is "a problem that has a documented root cause and a workaround." It is the accurate label for a fault that is understood and not yet fixed: the first line knows what to do when it returns, and someone still owes the real fix.
The first line is where the pattern shows
Engineering sees a fault when someone escalates it. The client sees it when it hits them. The first line sees every ticket, so it is where a second and a third occurrence can first be recognised as the same thing. Four habits turn that position into a record someone can act on:
- Search before closing. Before a ticket is closed, check whether the same symptom, from the same client or the same system, appeared in recent tickets.
- Link, do not restart. A recurring incident is linked to the earlier tickets, so its history travels with it and nobody diagnoses it from zero.
- Keep one problem record per cause. A problem record is one entry in your tracker that holds the cause, every incident linked to it, the workaround and the fix. The second occurrence is reason enough to open it. Each later incident is added to that record instead of starting another.
- Write the workaround down. If there is a way to keep the client working, it goes into the knowledge base the same day, so the next shift applies it instead of rediscovering it.
A problem record needs an owner and a date
A problem record nobody owns is a note. The fix lives in another team's work, so the record has to land there. Atlassian's incident management handbook shows the same rule in Atlassian's own process: for every action that comes out of a postmortem, the written record of an incident, its teams "raise a Jira work item in the backlog of the team that owns it." Fixes for root causes are marked as priority actions, and those carry an agreed deadline of 4 or 8 weeks, depending on the service, with reminders until they are completed.
The handbook also sets the bar for what counts as a root cause: the optimal place in the chain of events, where a change will prevent "this entire class of incident." Not today's ticket. The whole family of them.
Google's Site Reliability Engineering book lists the primary goals of a postmortem, and the one it stresses most is to make sure "effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence." A postmortem that ends with no owner and no due date has documented the incident but put no preventive action in place.
The test for your own queue is short. For every open problem record, can you name the team that owns the fix and the date it is due? If either answer is blank, nobody has committed to the fix, and the cause keeps producing tickets until it is fixed.
Your customer is counting
A business customer does not see how your tickets are linked. It sees the same failure again. Atlassian's guide says it in one line: "customer patience wears thin when they notice the same incident happening multiple times."
In customer support for business clients this is sharper, because one company can report the same fault through different people, and the second person to write may not know the first one already did. Your first line is the party that can answer: this is not new, here is the record, here is who owns the fix. That answer tells the client the pattern was noticed, which a fast reply on its own does not.
When the first line is not your team
Outsourcing the first line splits the pattern from the fix. The outside team sees every recurring incident. Your engineers own the systems that cause them. If nobody agreed how the two meet, the vendor keeps closing tickets correctly and the cause keeps producing them. Settle four things before the first ticket:
- Where problem records live. In your own tracker, next to the engineering backlog, not in the vendor's notes.
- Who may open one. The first line opens a problem record on the second occurrence without waiting for permission.
- Where the workaround goes. Into the knowledge base the team works from, so every shift has it.
- What the regular review shows. Open problem records, the incidents linked to each, the owner and the due date. Not only ticket counts.
How a case is handed upward is a separate question, covered in our guide to L1, L2 and L3 support, the first, second and third lines. The point here is narrower: the first line must be able to say "this is not new" and have that sentence land in someone's backlog.
How IMMIDO fits
In our work for Spribe, an international tech company whose first-line support we run (described in our case study), requests and incidents are handled in Jira and Slack, the knowledge base lives in Confluence, and escalating complex cases to a second-line support team (L2) is part of the service.
Across clients, we run 24/7 first-line support inside your own tools.
A team lead on our side runs the team's daily operations. We work as a fixed monthly team, not per ticket, so a fault that keeps returning brings us more work, not more revenue.
Book a call and bring a few recently closed tickets. We will go through them with you and check whether any of them is the same incident coming back. How we run the first line is described on our support page.
Sources: Atlassian, Problem management (the ITIL definitions of problem and known error, the rollback example, customer patience) · Atlassian, Incident Management Handbook: Postmortems (actions in the owning team's backlog, the deadline for priority actions, root causes) · Google, Site Reliability Engineering, Postmortem Culture · IMMIDO, Spribe case study.