Here is a pattern every busy support team eventually recognizes with a sinking feeling: the same issue, again. The export that times out. The login that fails after a password reset. The webhook that silently drops every few days. Each instance is a fresh ticket, handled competently, closed, satisfaction recorded — and then it comes back, because nobody ever fixed the thing causing it. You can be excellent at clearing tickets and still be trapped, closing the same incident fifty times while the queue never gets lighter. The escape hatch is a discipline with a boring name and an outsized payoff: problem management.

The distinction between incident and problem is the most useful idea in service management that customer support teams routinely don't have language for. Once a team learns to separate the two, the way they think about a recurring issue changes permanently — and so does the slope of their backlog.

The two jobs are genuinely different

An incident is an interruption to service for a specific customer, right now. The job of incident management is restoration: get this person working again, as fast as possible, by any means — a workaround, a manual fix, a restart. The customer is waiting, so speed wins. You are not required to understand why it broke to resolve an incident; you are required to make it stop hurting this customer today.

A problem is the underlying cause behind one or more incidents. The job of problem management is elimination: find the root cause and fix it so that class of incident stops happening to anyone. There is no customer tapping their foot, which means problem work optimizes for thoroughness over speed — the opposite of incident work.

Conflating the two is what keeps teams stuck. If you only ever do incident management, you restore service over and over and never reduce volume — you are bailing water without patching the hull, which is exactly the trap behind a backlog that refuses to drain. If you tried to root-cause every incident before resolving it, customers would wait days for fixes that a workaround could have delivered in minutes. You need both jobs, run deliberately as separate work.

The workaround buys you time; it is not the fix

The bridge between the two disciplines is the workaround, and it is worth taking seriously. When you identify a problem you can't fix immediately, a documented workaround lets agents resolve every future incident of that type quickly and consistently — a known issue with a known temporary answer. This is sometimes called a "known error": you understand the cause, you have a stopgap, and the permanent fix is pending.

The danger is letting the workaround become the resolution. A workaround that works well enough quietly removes the pressure to ever fix the real thing, and the problem becomes permanent furniture. So track the known error as an open problem even while agents are happily applying the workaround via a saved reply — the incidents are handled, but the problem is not closed until the cause is gone. The workaround makes the pain survivable; it does not make the problem solved.

How to actually find problems hiding in your queue

Problems rarely announce themselves; they hide inside a stream of individually-reasonable incidents. Two practices surface them.

  • Read your tags, not just your tickets. A disciplined tagging taxonomy is what turns "I feel like I keep seeing this" into "this issue generated 8% of last month's volume." Volume by cause is the radar for problem management — the issues at the top of that list are your problems, ranked by exactly how much they're costing you.
  • Link incidents to assets and changes. When several incidents all point at the same asset, or all cluster right after a particular change, the common thread is the problem. This is why incident, problem, change, and asset tracking are most powerful together — each one provides the linkages that make the others' patterns visible.

The output of this hunt is a problem record: a description of the cause, the incidents it explains, the workaround in use, and an owner accountable for the permanent fix. Crucially, a problem usually does not get fixed by support — it gets fixed by engineering or operations. So problem management is largely about making the case: assembling the volume data that proves a fix is worth an engineer's time, which is the same evidence-based muscle behind a good support-to-product feedback loop.

Don't run more problems than you can close

A failure mode worth naming: a team discovers problem management, gets excited, and opens forty problem records — which then sit untouched because nobody has time to drive forty root-cause investigations. An open problem nobody is working is just a more elaborate way of ignoring the issue.

Run problem management like a tight, ranked queue. Pick the two or three problems causing the most pain — measured in ticket volume, customer impact, or both — give each a real owner, and drive those to a permanent fix before starting more. A team that fully eliminates three recurring issues a quarter will feel the queue get lighter; a team with forty open problem records and zero closed ones has just invented new paperwork. Prioritize problems the same way you'd prioritize anything else: by impact, ruthlessly.

The honest test

Problem management is working when issues you used to see weekly simply stop appearing — and when your team can point to specific recurring tickets that no longer exist because the cause behind them got fixed. Watch it in your metrics: a reopen and recurrence rate that trends down, and a tag-volume chart where last quarter's top drivers have fallen off the list entirely. If instead your most common issues are the same ones they were six months ago, you are doing incident management beautifully and problem management not at all — closing the same ticket for the fiftieth time, and wondering why the queue never gets shorter. The fix is to treat the recurring ones as problems to eliminate, not incidents to keep surviving.