Problem Review: Find Recurring Incidents
Find the incidents you keep resolving twice, explain the top one with structured root cause analysis, and agree who owns closing it. Three tools, one sitting, nothing uploaded.
- Finds repeating patterns
- Five structured RCA passes
- Nothing leaves your browser
A problem review looks across recent incidents for repeating patterns, picks the ones worth investigating and agrees an owner for each. The dashboard flags a candidate when at least five incidents share a category, configuration item and similar wording, and ranks those rising over the last 14 days higher. Check a trend against Ramadan, Eid and month-end close before trusting it. Candidates are for review, not confirmed problems.
Most service desks resolve the same incident many times over. Problem management is the practice meant to stop that, and it is the one most often skipped — not because teams disagree with it, but because it needs deliberate time away from the queue, and because the handover from incident to problem usually arrives as a hunch rather than as evidence.
These three tools close that gap in one sitting. Your incident export never leaves the browser.
1. Find the patterns
Drop in an incident export. Incidents that share a category, a configuration item and similar wording are grouped, then ranked by volume, by the severity of the worst tickets in the group, and by whether the rate has climbed in the last fortnight.
2. Explain the top one
Take a candidate straight into the analyser and put it through five structured passes — is/is-not, fishbone, five whys, Pareto and change correlation. The candidate carries across; you do not retype it.
3. Agree who closes it
A recurring pattern with no owner stays a recurring pattern. Settle whether this sits with Incident or Problem, who owns closure, and the words that get a stakeholder to accept it.
Running a problem review that changes something
- Bring evidence, not impressions. A candidate carries its incident count, its date range, the mix of priorities and example ticket references. That is what turns “this keeps happening” into something a change advisory board will act on.
- Take one candidate, not five. A review that opens five problem records and closes none is worse than one that opens a single record and sees it through.
- Prefer rising patterns over large ones. A long-running group of P4s is often a known annoyance with a workaround. A group that has climbed sharply in the last fortnight is usually something that changed recently, which means something can be changed back.
- Check the calendar before you trust a trend. Volumes move around Ramadan, Eid and month-end close. The GCC business calendar sets the working weeks and holidays every Lab tool measures against.
- Write down what you decided not to pursue. Next month you will look at the same list. Knowing why a candidate was passed over saves the argument being had twice.
Method & ownership
Candidates come from the service desk dashboard, which groups incidents by category, configuration item and similar short descriptions, requires at least five incidents in a group, and tests the last 14 days against up to 90 days before them for a rise. Ranking weights the most serious tickets in a group rather than the average. Candidates are starting points for investigation, not confirmed problems, and every step runs in your browser.
The formulas used here are standard, published methods. The implementation, interface, wording, findings logic and benchmark figures are original work by ITSM Compass. Results are estimates, not professional advice. See the terms of use.
© 2026 ITSM Compass. All rights reserved.
Questions
What is a problem review?
A standing session that looks across recent incidents for repeating patterns, picks the ones worth investigating, and agrees an owner for each. It is the practice most service desks have on paper and few run in earnest, because it needs time away from the reactive queue.
How is a problem candidate found?
The dashboard groups incidents that share a category, a configuration item and similar wording, then ranks the groups by volume, by the severity of the worst tickets in them, and by whether the rate has risen in the last 14 days against the weeks before. Groups smaller than five incidents are ignored. They are candidates for review, not confirmed problems.
What data do I need?
One incident export from ServiceNow, Jira, Freshservice or any tool that produces a CSV with dates, priority, category and a short description. Roughly three weeks of history is the minimum for the trend test to mean anything; more is better.
Does my ticket data leave my machine?
No. The export is read in your browser and never uploaded. There is no account and no server, which is the whole reason this runs as a set of browser tools rather than a platform. Close the tab and the export is gone; the dashboard keeps the file name and its top 12 categories with yearly volumes in this browser, for the shift-left calculator.
Why does the root cause analysis need a separate tool?
Because finding a pattern and explaining it are different jobs. The analyser runs five structured passes over your evidence — is/is-not, fishbone, five whys, Pareto and change correlation — so the conclusion rests on the evidence rather than on whoever spoke last.
How often should we run this?
Monthly suits most service desks. The pattern data needs time to accumulate, and the actions coming out of it need time to land before the next pass.
No one has time to run the problem review?
That is the usual reason it never happens. A fractional service delivery manager can run it monthly and carry the actions through to completion.