Why 20% of your repeated tickets should never have been reopened

A high volume of tickets well resolved by Level 1 Support can hide a structural problem: different cases, same root cause, never actually fixed. Formalizing a Problem Management process — treating "known errors" as a category rather than isolated tickets — cut repetitive cases by more than 20% over two years, sustaining 97% CSAT, +60 NPS, and 99.95% uptime for four consecutive years.

The problem isn't volume: it's repetition

Running enterprise-level support with a high weekly ticket volume isn't a problem in itself — most of those cases get resolved well and fast on first contact. The problem appears when a subset of those tickets repeats: a different case number, the same underlying symptom, never actually root-caused.

What separates incident management from problem management?

Closing tickets fast is incident management: it resolves today's symptom. Problem Management is the discipline — formal in ITIL, though we called it "support to the operation" internally — of treating known errors as their own category, analyzing the unconfirmed root cause behind each one, and driving them to a permanent fix instead of a workaround that repeats indefinitely.

Is the extra effort of root-cause analysis worth it?

In the two most recent years of running that process, repetitive cases dropped by more than 20%, while we sustained 97% CSAT, +60 NPS, and 99.95% uptime across all products for four consecutive years. The investment in root-cause analysis doesn't compete with resolution speed — it sustains it, because every problem solved at the root is an entire category of future tickets that simply ceases to exist.

How do you get Level 1 to adopt the process?

It was one of the hardest parts of standing up this process. In a large support operation, it's easy to normalize cases that look simple without recognizing their real impact on productivity or user experience, and to keep resolving them one by one instead of escalating them for analysis. Building the criteria for when a pattern needs escalating took direct coaching and a few stumbles, but it matured in about two months.

The lesson I take

It isn't just closing tickets fast — it's making sure the same ticket doesn't come back. That's the difference between an efficient support team and one that also makes the platform more reliable every month that passes.

Frequently asked questions

How do you reduce incident recurrence without just closing tickets faster? By treating known errors as their own category (Problem Management) and driving each one to a permanent root-cause fix, instead of a workaround that repeats indefinitely.

What is a known error in ITIL? An incident whose root cause has been identified but not yet permanently corrected. It's logged as an open problem and tracked to definitive resolution, rather than being closed as a resolved ticket.