The Reopen Review: Turning Reopens Into Fixes

Friday, 15:00, at Pennant Print, a commercial printer with a three-person desk. Marta, who leads it, opens the filter that shows the week's reopened tickets and finds eleven. For most of the past year she would have skimmed the eleven, sighed, and closed the filter. Eleven reopened tickets is eleven small embarrassments and there is a weekend to get to. This Friday she has a sheet. Thirty minutes later the eleven have been sorted. Three thank-yous and one different problem are set aside. There are four not-fixed reopens, three of them new-starter setups closed before the mailbox existed. There are also three fixed-then-broke reopens, all about the quoting application timing out mid-morning. One fix to the new-starter procedure. One recurring fault handed over with three linked tickets. The weekend begins at 15:30, and for the first time the eleven have done some work.

The reopen review is a fixed weekly half hour in which someone reads every ticket that reopened that week. They sort them by kind and by cause, look for the pattern, and pick one thing to change. They hand any recurring fault to whoever hunts causes on the desk. This is the step that turns reopens from a score into a source. This article is part of our Reopened Tickets series. It is the last one because everything the earlier articles produced is input to this half hour. That includes the classification cards, the rate, the cause notes, the verification habit.

It covers why the review is weekly and why it takes thirty minutes. Then it covers the six steps, from pulling the week's reopens to closing the loop on last week's fix. Next come the patterns to look for and what each one means, followed by how to feed problem management without a problem module. Then it covers running the review on a desk of one and what the review is not. A short war story follows, about a pattern that lived in the clock rather than the people. Finally comes the review sheet, built so that the half hour fills it in from top to bottom.

Why Weekly, and Why Thirty Minutes

Weekly is the rhythm because reopens arrive in patterns that repeat within days. A pattern found on Friday has repeated four or five times by the time a monthly review would see it. A fixed-then-broke fault on three tickets this week will be on six next week and twelve the week after. Each one is restarted by someone who thinks they are seeing it first. A not-fixed reopen caused by a wrong step in a procedure will recur every time the procedure is followed. Monthly is too slow to stop either. Daily is too fast to see either, because one day's reopens are two or three tickets and two or three tickets are always weather.

Thirty minutes is enough because the sorting has already been done, ticket by ticket, by whoever handled each reopen. The classification card from What a Reopen Is Telling You, the first article in this series, says the kind and the likely cause. So does the internal note that stands in for it. The review reads those notes and tallies them. It spends its time on the only two questions that need a second person: is there a pattern, and what is the one thing to change. A desk whose reopens carry no notes will need ninety minutes for the same review. Most of that time goes on reconstructing from the history what a ten-second note would have said at the time.

The slot is fixed, protected, and short enough that nobody cancels it. Friday mid-afternoon works for most desks, because the week's reopens are in and Monday's are not. The fix decided on Friday can be in place before the week that would have needed it. Who attends depends on size. On a desk of three or more, the lead and one technician attend, rotating. That way, over a quarter everyone has read a stack of reopens and seen what they have in common. On a desk of one or two, whoever is there, with the sheet, which is the subject of its own section below.

Step One: Pull the Week's Reopens

The first five minutes assemble the stack. Most tools have a way to list tickets that reopened in a period. Options are a filter on recently reopened, a report on status changes from resolved back to open, or a saved search on the reopen event. Use whichever yours has, set it to the seven days since the last review, and count. If the tool cannot list reopens directly, export the week's tickets with their status history. Then sort for any that went from a resolved or closed state back to an open one. That takes twenty minutes the first time and five after that. Measuring Reopens Honestly has the spreadsheet method.

Add the reopens the tool cannot see. A reply to a closed ticket may create a new ticket rather than reopening the old one. In that case, the week's second tickets from the same requester within the reopen window are reopens in disguise. The review wants them. A quick sort of the week's new tickets by requester finds most of them. Look for a name that also appears on a ticket resolved in the past fortnight. Merge or link each pair so the history is together, then count the pair once.

Write three numbers on the sheet before reading a single ticket: this week's reopen count, last week's, and the week before. The count on its own is nearly meaningless, as the measuring article says at length. But three weeks of it side by side is a direction. And a direction is the first thing the review should notice. Eleven after six after seven is a different Friday from eleven after twelve after ten, before anyone has opened a ticket.

Step Two: Sort by Kind, Then by Cause

The next ten minutes sort the stack twice. First by kind: not fixed, fixed then broke, a different problem, a thank-you. The last two are set aside at once, after a glance to confirm that the different-problem reopens were split into new tickets and the thank-yous were closed again without a reply. They are counted on the sheet, because a desk where thank-yous are half the reopens has a mechanical problem worth knowing about. But they get no further time. The review is about the first two kinds, which are the ones that say a fix did not hold.

Then sort by cause, using the five from The Root Causes Behind Reopens. Those are premature close, no verification, a workaround mistaken for a fix, the wrong problem solved, a communication gap. Add a sixth bucket for faults in systems the desk does not control. Each not-fixed or fixed-then-broke ticket gets one cause. Take it from the handler's note where there is one and from a minute with the history where there is not. The tallies go on the sheet. Most weeks the two tallies tell most of the story before the pattern step begins. Four no-verification reopens on a desk of three is a habit, and three workarounds on the same application is a fault.

Disagreements about cause are settled quickly and recorded either way. A reopen that could be a premature close or no verification is written up as whichever the resolution note's tense suggests. And the review moves on, because the fix for both is the same verification step and the sheet is not a court. The one distinction worth a minute's argument is between a workaround and a not-ours fault. The first is the desk's to chase and the second is somebody else's. Putting a vendor's fault in the desk's column makes the desk look careless for a problem it cannot fix.

Step Three: Find the Pattern

A pattern is anything three or more of the week's reopens have in common that one reopen would not reveal. And there are five worth looking for, in order. The same cause on three or more tickets points at a process. Examples are a step the desk skips, a template missing a line, a status that lets tickets through unchecked. The same fault on two or more tickets, even with different requesters and different technicians, points at a problem. That is a cause behind the symptom that nobody has found because each ticket was treated as new. The same category carrying most of the reopens points at the work rather than the people. It usually points at a procedure or a system that category depends on. The same time of day or day of week on the closes points at the clock, which is the pattern in the war story below. And one ticket reopened twice or more is a pattern on its own. A twice-reopened ticket has outgrown its handling. The review is where that gets noticed if the second-reopen rule from Handling a Reopened Ticket Well was missed.

Then the three-week test, which separates a pattern from a coincidence. Read the last two sheets. If the pattern on this week's sheet appeared on either of them, it is not weather. In that case, it is a property of the desk and will be on next week's sheet unless something changes. If it appears for the first time, note it, make the cheap fix if there is one, and otherwise wait a week. Three no-verification reopens in one week can be a bad Thursday. Three weeks running, it is how the desk closes tickets.

The table pairs each pattern with what it usually means and the kind of fix that fits. The right-hand column is deliberately specific, because the review's output is one concrete change, and "remind the team to be careful" has never once reduced a reopen count.

Step Four: Pick One Fix

The review ends with one change, and one is the right number. Two changes in the same week and next Friday's sheet cannot say which one worked. Zero changes and the half hour was a reading. The fix is specific enough that someone could check on Monday whether it was done. Examples are a line added to the new-starter template, a checklist item pinned to the wall, a field made required on the form. Another is a knowledge article corrected. Or a rule might say nothing is resolved after 16:30 without the fix-check answered. The fix has an owner by name and a date. And it has an expected effect written as a number: "no-verification reopens from four a week to one".

Choose the fix that removes the most reopens for the least effort, which is nearly always the process fix rather than the problem fix. A template line that stops three not-fixed reopens a week is an afternoon's work with an effect by next Friday. A recurring fault behind three fixed-then-broke reopens may take a month of someone's spare time to find and fix. And it goes to problem management, in the next step, where that month is planned rather than hoped for. The review's own fix is the quick one; the slow one is handed over, not forgotten.

Resist the fix that is really a reminder. "Ask everyone to verify before closing" is not a change. It is the hope that a change will happen, and next week's sheet will show how that went. The change is the thing that makes verification harder to skip than to do. That means the status, the checklist, the template, the measurement that counts confirmed closes rather than resolves. Preventing Reopens, the previous article in this series, has the list of those. The review's job is to pick the one that fits this week's pattern. People do not become careful because they were asked. Processes become careful because they were changed.

Step Five: Feed Problem Management

Problem management, in plain words, is the practice of finding and removing the cause behind incidents that keep coming back. That is distinct from fixing each incident as it arrives. Most small-team help desk tools have no module for it. And most small desks have no one whose title includes it, and neither of those is a reason not to do it. The reopen review is the single best feed a desk has into that practice. That is because a fixed-then-broke reopen is an incident announcing, in writing, that its cause is still present. The Problem Management series describes the practice in full; this step is the handover.

The handover is a package, not a mention. For each recurring fault the review has found, package the tickets, linked together in the tool. Where the tool cannot link, give them a shared word in their subject lines and a note on each pointing at the others. Include the dates and times of each occurrence, because the interval is often the clue. Add the workaround that clears it, so the next technician applies it in two minutes instead of twenty. Include the number of occurrences and the number of requesters affected, which is the case for spending time on the cause. Add a one-line statement of what has been ruled out. All of that fits on a third of a page and most of it is already in the tickets. The review's work is to put it in one place and give it to one person.

That person, on a small desk, is usually a technician with an hour a week set aside for it. The review is where their hour gets its agenda. Finding the repeat tickets describes how to hunt for recurring faults across the whole queue. The reopen review is the shortcut, because reopened tickets are repeat tickets that have identified themselves. Where the desk has a full ITSM suite with a problem record, the package becomes the record. Where it has a help desk tool and a knowledge base, the package becomes a known-error article, internal to the desk. In that arrangement, the workaround is at the top and the linked tickets at the bottom. The convention works just as well.

The not-ours bucket is handed over too, differently. A fault in a system the desk does not own goes to whoever does own it, with the same package and a request for a date. Examples are a vendor's service, the network team's switch, an application another department administers. The review tracks the fault on the sheet under "handed to" until it comes back fixed or the owner says plainly that it will not be. In the latter case, the workaround goes in the knowledge base as permanent and the requesters are told the truth. A desk that absorbs other people's faults into its own reopen rate will be asked to explain a number it cannot change.

Step Six: Close the Loop

The last five minutes look backward. Last week's sheet named one fix with an expected effect; did the kind of reopen it targeted actually fall? Four no-verification reopens last week, one this week, after the checklist went up: keep the checklist, write "worked" on the sheet. Four last week, four this week: the checklist is not being used, or the cause was not what the sheet said. In that case, the review spends a minute deciding which before choosing this week's fix. Three sheets of "worked" in a row on a given cause is a cause the desk has beaten. That is worth saying out loud to the people who beat it.

Closing the loop also means telling the team what the review found, without names. A two-line message after each review does three things. For example: "this week's reopens were mostly new-starter tickets closed before the mailbox was created; the template now has a check for it". It shows the reopens are read, spreads the fix, and makes the next technician who closes a new-starter ticket look for the mailbox. What it does not do is say who closed the three tickets, because the fix is to the template and the template has no name on it.

Once a month the sheets roll up into a paragraph for whoever the desk reports to. It covers the reopen rate for the month against the previous two, the top two causes, and the fixes made and whether they worked. It also covers any recurring fault handed to problem management with its status. It is the same shape as the monthly breach review in SLA Breaches and What They Teach. And the two paragraphs often sit next to each other, because a desk that is closing tickets properly is usually also meeting its targets, and for the same reasons.

The Review on a Desk of One

A one-person desk runs the same review in fifteen minutes on Friday afternoon with the same sheet. And the honesty is harder because the reviewer is reading their own closes. The sorting still works, because the kinds and causes are facts about tickets rather than about people. The pattern step still works, because a solo administrator skipping verification at 16:45 is as visible on a sheet as a team doing it. The one-fix step is the part that saves the solo desk. Without a sheet the solo fix is always "try harder". With one it is a template line that does the trying.

Two adjustments. First, the three-week test matters more, because one person's week has fewer tickets and more weather. A solo desk should hold a pattern to three sheets before changing anything that costs more than a template line. Second, the problem management handover is to a calendar rather than a colleague. A recurring fault gets a half hour booked the following week, with the linked tickets attached to the appointment. On a desk of one, the only thing that stops the hunt from happening is that nothing was ever scheduled to make it happen.

What the Review Is Not

The reopen review is not a performance review, and the quickest way to kill it is to let it become one. The moment the sheet grows a column for who closed each reopened ticket, technicians will stop writing honest cause notes. They will start closing tickets in ways that cannot reopen. Then the stack on Friday will shrink while the failed fixes continue somewhere the review cannot see. The sheet sorts by kind, cause, category, fault and time. It does not sort by person, and the review does not say names. And that rule is written at the top of the sheet where everyone can read it.

Where one technician genuinely needs coaching, the evidence will be visible in the cause tallies over a month without anyone looking for it. In that case, the conversation happens separately, between the lead and the technician, about the habit and the checklist, in the week it is noticed. It does not happen in the review and it does not go on the sheet. The measuring article makes the full case for category before agent; the review simply enforces it by never getting to agent at all. A review that names people finds people. A review that names causes finds fixes, and fixes are what the desk is short of.

The review is also not a meeting in the sense that produces minutes and action logs and a follow-up meeting. It is two people, a filter, a stack, and a sheet with one change on it. If it has grown a slide deck by month three, something has gone wrong. Usually, in that case, the one fix a week was never actually made, so the sheet filled up with observations instead. An observation is what a reopen already is. The review's only job is to turn one of them into a change.

A Short War Story: The Friday Sheet at Tollgate Foods

Tollgate Foods, a food distributor with a three-person desk, started a Friday reopen review after a quarter of Monday mornings spent almost entirely re-answering tickets closed the previous Friday. Ingrid, who ran the desk, had been sorting the week's reopens by cause for three weeks. She had seen nothing but a tall column under "premature close". Then she added a line to the sheet for the time of day each reopened ticket had been resolved. She found that nearly all of them had been resolved between 16:30 and 17:00 on Friday. The cause was a habit she had started herself: a cheerful "let's get the queue under twenty before we go" at 16:15 every Friday. It had quietly become a licence to resolve on hope. She dropped the target that afternoon and replaced it with one rule: nothing was resolved after 16:30 without the fix-check question answered. Monday's reopens fell from around six a week to one or two within a month. The cost of the three months before the sheet had been a dozen Monday mornings and a backlog that started every week behind. It also included a requester community that had learned to expect Friday's fixes to fail. The pattern had been in the clock the whole time, and the people had been blamed for it, including by themselves.

The Reopen Review Sheet

The sheet is the half hour on one page, filled from top to bottom in the order the steps run. The headline is written before any ticket is read. The sorts come from the handlers' notes. The pattern section is the only part that needs thought. And the one fix and the handover are the only parts anyone else will act on. Keep the completed sheets together; the three-week test is "read the last two", and the monthly paragraph is "read the last four". The rule at the top is not decoration.

REOPEN REVIEW SHEET — WEEKLY, THIRTY MINUTES
Desk: ______________  Week ending: ______________  Reviewers: ______________
Rule: this sheet sorts tickets by kind, cause, fault and time. It never names
      the person who closed a ticket.

HEADLINE (write before reading any ticket)
  Reopened tickets this week: ____   Last week: ____   Week before: ____
  Tickets resolved this week: ____   Rate, kinds 1 and 2 only: ____%
  Second tickets from the same requester inside the window (hidden reopens): ____
  Tickets with two or more reopens still open: ____  (list numbers: ____________)

SORT BY KIND
  1 Not fixed ____   2 Fixed, then broke ____   3 Different problem ____   4 Thank-you ____
  Kinds 3 and 4 checked (split / closed again) and set aside:  [ ]

SORT BY CAUSE (kinds 1 and 2 only)
  Premature close ____   No verification ____   Workaround as fix ____
  Wrong problem ____     Communication gap ____  Not ours (another owner) ____

PATTERNS (tick what applies; write the evidence)
  [ ] Same cause on three or more tickets: ______________________________
  [ ] Same fault on two or more tickets: ________________________________
  [ ] One category carrying most reopens: _______________________________
  [ ] Closes clustered at one time of day or day of week: _______________
  [ ] One ticket reopened twice or more: ________________________________
  Three-week test: on either of the last two sheets?  [ ] no   [ ] yes
  Verdict:  [ ] weather, note why   [ ] process pattern   [ ] recurring fault

THE ONE FIX THIS WEEK
  What changes: __________________________________________________________
  Type:  [ ] reply template line   [ ] checklist item   [ ] required form field
         [ ] knowledge article     [ ] status rule      [ ] rule about the clock
  Owner: __________   Done by: __________
  Expected: reopens of this cause from ____ a week to ____

HANDED TO PROBLEM MANAGEMENT OR ANOTHER OWNER
  Fault: ______________________  Tickets linked: ____  Occurrences: ____
  Workaround: _________________________________  Requesters affected: ____
  Handed to: ______________  Date: __________  Date promised back: __________

LAST WEEK'S FIX
  What it was: ______________________________________
  Did the cause it targeted fall?  [ ] yes   [ ] no   [ ] too early to say
  Decision:  [ ] keep   [ ] adjust: ______________   [ ] drop

TEAM NOTE (two lines, no names, sent after the review)
  ________________________________________________________________________

LINE FOR THE MONTHLY PARAGRAPH
  ________________________________________________________________________

Two edges. A week with no reopens of kinds one and two still gets a sheet, with "none" in the pattern section and the reason. A run of empty sheets is either the best news the desk has or the sign that replies have stopped reopening tickets. The measuring article explains how to tell. And a week with thirty reopens does not get a longer review. It gets the same thirty minutes, the biggest cause, one fix, and a note that next week's sheet will need the second-biggest.

Marta's sheet, that first Friday at Pennant Print, said: eleven reopens. Four were not fixed, three of them premature closes on new-starter tickets resolved before the mailbox was created. Three were fixed-then-broke on the quoting application, linked and handed to Rafael for his Tuesday hour. The sheet listed one fix, a mailbox check added to the new-starter template. Marta owned the fix, and it was done Monday. The expected result was for new-starter reopens to go from three to none. The following Friday's sheet had seven reopens, no new-starter tickets among them. The quoting application was still on the handed-to line with a date beside it. The sheet after that had five. By the fourth, the review had become slightly boring, which is the only sign of success it has.

Frequently Asked Questions