The Root Causes Behind Reopens and the Fix for Each

Friday, 16:40, and Sam at the Northgate Retail desk has five reopened tickets from the week lined up in the list. Each has a different story and the same first line from the requester. The till ticket came back because the till was never actually tested after the fix. The e-mail ticket came back because the fix was right and the store manager did not know she had to sign out. The label printer ticket came back because it was restarted, again, for the fourth time this month. The report ticket came back because the fix was applied to the wrong report. And the mapped drive ticket came back because it was closed at 17:02 on Tuesday, in a hurry, on the theory that it was probably done. Sam wrote the five on the whiteboard, looked at them for a minute, and said the useful thing: "These are not five problems. These are five reasons."

A root cause, in the plain sense used here, is the reason a fix failed, as opposed to the fault that was fixed. The fault is what the requester reported; the root cause of the reopen is what the desk did or did not do that let the ticket come back. Nearly every reopen traces to one of five: the premature close, no verification, a workaround mistaken for a fix, the wrong problem solved, and a communication gap. This article is part of our Reopened Tickets series. The first article sorted reopens into kinds and the second turned them into a rate; this one is about why they happen and what to change for each.

It starts with why five causes, not fifty, are enough, then covers each of the five in turn. For each, it explains what it looks like on the reopened ticket, why desks do it, and the fix at the desk and in the process. Next is how to tell the causes apart from the ticket itself, using Sam's five as the worked example. Then it explains which cause to fix first when a desk has all of them. After that is a short war story about a fix that was right twenty-three times. It ends with the cause table, built to be copied, that pairs each cause with its fix and its owner.

Five Causes, Not Fifty

Reopens cluster, and they cluster by cause rather than by fault. A desk that reads a month of reopened tickets one at a time sees forty different faults: a printer, a drive, a password, a report, a scanner. A desk that reads the same forty asking "why did the fix not hold" sees the same five answers over and over, in different proportions. The proportions are the diagnosis. The faults are the desk's work. The causes are the desk's habits, and habits are what you can change.

The five map onto the two kinds of reopen that count. The not-fixed reopen, where the fault never went away, is usually a premature close, no verification, or the wrong problem solved. The fixed-then-broke reopen, where the fault went away and came back, is almost always a workaround mistaken for a fix. The communication gap sits across both, because a right fix the requester did not understand reopens exactly like a wrong one. If your desk has sorted its reopens with the classification card from What a Reopen Is Telling You, the kind already narrows the cause to two or three. The reopened ticket's own history then does the rest.

Why five and not fifty? Because every finer distinction I have tried to draw turned out to be one of these five wearing a hat. "Closed by the wrong person", "closed on a Friday", "closed to meet a target" are all the premature close. "Tested on the wrong machine", "tested while logged in as admin" and "tested before the change had replicated" are all no verification. A cause list that grows past five is describing symptoms again, and symptoms are what the reopens were already telling you.

The Premature Close

The premature close is a ticket marked resolved before the work was finished, on the expectation that it would be. The technician has done most of the fix, or asked the requester to try something, or raised the change that will fix it. They resolve the ticket on intent rather than on outcome. On the reopened ticket it looks like a resolution note in the future tense: "this should sort it", "once the sync runs you'll be fine", "let me know if it doesn't work". A requester reply follows, saying that it did not.

Desks close early for three reasons, and all three are pressures rather than character flaws. The first is the open count. A desk judged by how many tickets are open learns that a ticket in Resolved is not counted, and that a resolve can always be undone. The second is the end of the day, especially Friday, when an unfinished ticket feels like an unfinished week and a resolve feels like tidying up. The third is a belief, usually unspoken, that the requester will say if it is not fixed, so resolving early costs nothing. The requester does say so. That is what a reopen is, and it costs a second round of work plus the requester's trust.

The fix at the desk is a rule about tense: a ticket is resolved when the fix has happened and been seen to work, never when it is expected to. If the fix depends on something that has not run yet, the ticket stays open, in a waiting status. It needs a note saying what it is waiting for and when to check. The fix in the process is to stop counting Resolved as finished anywhere a technician can see. Report on confirmed closes rather than resolves. Treat a resolve that reopens inside a day as a close that did not happen. The Closing Tickets Properly series covers the closing conversation itself; the point here is only that the conversation cannot start before the fix is done.

The premature close has one tell in the history that is worth checking on every reopen. Look at how long the ticket spent in its working status before it was resolved. A ticket that went from first reply to Resolved in two minutes was not fixed in two minutes; it was resolved on hope. Most tools record every status change in the ticket's history with who made it and when. Many can report how long tickets spent at each status. Where yours can, a month's worth of two-minute resolves is one report rather than forty tickets read one at a time. Where it cannot, the export has the timestamps and a spreadsheet does the subtraction.

No Verification

No verification is a fix that was done, was correct, and was never confirmed from the requester's side. The technician made the change, saw it take effect from their own screen, and resolved. The requester, on their own screen, sees the fault. Their session was already open, their machine had cached the old answer, or their profile was the old one. Or the change had simply not reached them yet. On the reopened ticket it looks like a confident resolution note, "mapped the drive and confirmed it appears", followed by "I don't see it", and both are true.

This is the most common cause on most desks, and the hardest to see from inside, because the technician did everything right except the last step. The fix worked. It worked for the technician. The reopen is not saying the fix was wrong; it is saying nobody checked it where it mattered. A fix that has not been seen to work from the requester's seat has not been seen to work. It has been seen to compile.

The fix at the desk is the verification step, which is the subject of Preventing Reopens and gets a full checklist there. In one sentence: before resolving, have the requester try the thing, or try it yourself as them, on their machine, in their session. The fix in the process is to make verification a status rather than a virtue. A ticket moves to a waiting-for-confirmation state after the fix. It moves to Resolved only when the confirmation arrives or the confirmation window runs out. A desk that relies on technicians remembering to verify will verify on quiet days.

A Workaround Mistaken for a Fix

A workaround is a step that makes the symptom stop without removing what caused it: a restart, a reconnect, a cache cleared, a service bounced, a cable reseated, a profile rebuilt. Every one of them is a legitimate first move, and every one of them resolves the ticket honestly if the cause really was a one-off. The reopen arrives when it was not. "Fine for a week, then back." "Same thing again this morning." On the reopened ticket it looks like a short resolution note, a short interval of peace, and then the same requester, apologetic, back again.

Desks mistake workarounds for fixes because the workaround works. The requester is happy, the ticket is resolved, the next ticket is waiting, and nobody can tell a one-off from a recurrence until it recurs. The mistake is not the first restart. The mistake is the third, recorded in the same words as the first, by a technician who did not read the earlier two because the ticket number was different each time. A restart has fixed more tickets than any technician alive. It has permanently fixed almost none of them.

The fix at the desk is honesty in the resolution note: "restarted the print spooler; symptom cleared; cause not found". Then the next technician who opens a ticket about the same printer knows it has been here before. The fix in the process is a weekly look for the same fault on several tickets. That is what the reopen review is for. The process also needs a practice of linking the repeats together so they can be worked as one. Most help desk tools can link related tickets, and few small-team tools have a separate problem module. So the convention is a linked set of tickets under a shared name with an internal note on each saying so. A full ITSM suite has a problem record for the same job. The fourth label printer restart goes in whichever of those your desk has. Finding the cause behind a recurring workaround is the territory of known errors and workarounds, and the reopened ticket is how that work gets fed.

The Wrong Problem Solved

The wrong problem solved is a correct fix applied to the wrong fault, and it happens when the ticket's title and the requester's meaning drift apart. "Can't print" meant "can't print in colour to the finance printer from the new laptop", and the technician fixed printing. "E-mail not working" meant "the shared mailbox for orders stopped syncing on Tuesday", and the technician fixed e-mail. The report that was fixed was the weekly one; the requester meant the monthly one with a similar name. On the reopened ticket it looks like a reply that adds a detail the original never had, usually beginning "no, I mean".

This cause starts at intake, which is why it is the one a technician can least fix alone. A ticket that arrives with a symptom and no device, no account, no example and no "since when" invites a guess. A busy desk guesses well most of the time, which is why the habit survives. The guess is not the failure. The failure is resolving on the guess without confirming it was the right one, which turns a wrong problem into a reopen instead of a clarifying question. Gathering the right information at the first touch is owned by the intake article on it; the reopen is what happens when that article was not read.

The fix at the desk is to restate the problem in the first reply, in the technician's own words. Let the requester correct it: "So the colour printer in finance is missing from your new laptop, and black-and-white printing works; is that right?" It takes one sentence and it catches the wrong problem before any work is done on it. The fix in the process is on the form and the triage habit. Require a field for the device or system affected and an example. The triager sends back a ticket that has neither. Of the five causes this is the one that improves the fastest once the form asks the right question, and the one that never improves while it does not.

The Communication Gap

The communication gap is a right fix the requester did not know how to use, or did not know had happened. The password was reset, and the requester needed to sign out and in again, and the reply said "reset done". The printer was re-added on the server, and the requester needed to add it on their machine, and the reply said "sorted". The fix was made overnight, and the reply never came, and the requester kept doing the workaround they had found because nobody told them to stop. On the reopened ticket it looks like a correct fix, a terse or absent reply, and a requester who reports the original fault in the original words. From their side nothing changed.

This cause is the cheapest to fix and the most galling, because the hard part was done and the easy part was skipped. It comes from writing the resolving reply for the technician rather than the requester. "Reset done" is a complete sentence to the person who did the reset. To the person waiting at reception with a queue of patients, it is a noise. The resolving reply has to say three things in the requester's language. Say what was wrong, what was done, and what they now need to do or look for to see it working. Resolution notes that do this are the subject of resolution notes worth reading later, and the third part, what to do now, is the one that stops the reopen.

The silent close is the extreme form, where the status changed and no reply went at all. It is worth saying plainly that a status change on its own tells the requester nothing. In many tools a change of status sends no message to the requester at all. In those that can send one it is a bare notification nobody reads. So the resolving reply is the message or there is none. Test yours by resolving a ticket from your own address without a reply and seeing what, if anything, arrives. The fix at the desk is the three-part reply, every time, on a predefined template if that helps. The fix in the process is to make the resolving reply the thing that resolves the ticket. Then the status cannot change without words going to the requester. Send the satisfaction question with the same message. The "I did not know this was fixed" comments will tell you how often the gap is still open.

Telling the Causes Apart from the Ticket

The reopened ticket carries enough evidence to name the cause in a minute, and the evidence is in four places. Start with the resolution note's tense and length. Future tense means a premature close. A confident past tense followed by "I don't see it" means no verification. A terse one-liner means a possible communication gap. The time between the resolve and the reopen: hours means not fixed, days or weeks with a working interval means a workaround. The requester's reply: a repeat of the original words means the fix did not reach them, a new detail beginning "no, I mean" means the wrong problem. And the history of the fault beyond this ticket: a search for the same symptom that finds three closed tickets means a workaround, whatever this ticket says.

Sam's whiteboard is the worked example. The till ticket's note said "replaced the card reader, should be fine now". The ticket was resolved four minutes after the part arrived and reopened the next morning when the till was first used. That was a premature close, resolved before anyone ran a transaction. The e-mail ticket's note said "password reset done". The requester replied with the identical error message two hours later. That was a communication gap, since the reset was right and the sign-out was never mentioned. The label printer ticket's note said "restarted, printing again", the fourth such note in a month across four ticket numbers: a workaround mistaken for a fix. The report ticket's note described fixing the weekly sales report, and the reply said "no, I mean the month-end one": the wrong problem solved. The mapped drive ticket was resolved at 17:02 with "mapped the drive, confirmed visible". The requester could not see it at 08:30 because her session had been open all along: no verification.

Five tickets, five causes, and Sam's next week had a different shape for each. The till got a rule about running a transaction before resolving. The e-mail reply template grew a line about signing out. The label printer got a linked set of four tickets and an afternoon with the vendor's manual. The report ticket got a one-line restatement at the top of every reply. The mapped drive got a verification step. None of those fixes would have done anything for the other four, which is the whole reason to name the cause before choosing the fix.

Which Cause to Fix First

Fix the communication gap first, because it costs nothing but a template and it stops reopens on tickets where the technical work was already right. A three-part resolving reply, written once as a predefined reply and adjusted per ticket, removes this cause inside a week. It also makes the other four easier to see, because once the replies are clear, a reopen can no longer be explained by "they probably didn't understand".

Fix verification second, and the premature close with it, because they are the same habit at two moments: resolving before the outcome is known. A verification step before every resolve, as a status rather than a reminder, deals with both. The open-count pressure that drives the premature close has to be addressed from above at the same time, by reporting on confirmed closes rather than resolves. These two take a month to become habit and they are the two that move the reopen rate most.

Fix the wrong problem third, on the form, because the form change is quick. The habit change, restating the problem in the first reply, rides along with the clearer replies you introduced in step one. Fix the workaround last, not because it matters least but because it needs a review rhythm and a search of the history. That is a weekly practice rather than a rule. The first three fixes will also have cleared enough noise that the recurring faults are finally visible as a group. A desk that tries to start with the workarounds will spend its review time on reopens that a template would have prevented.

A Short War Story: The Sign-Out at Harbourview Clinic

Harbourview Clinic's two-person desk changed the password policy on a Monday, and by Thursday it had twenty-three reopened tickets. Every one was from a receptionist or nurse whose password had been reset correctly and who had replied with the same locked-out error. Nadia, who had done most of the resets, had closed each with "reset done, please try again". Not one of the twenty-three had known to sign out of the shared reception machines. There, the old session held the old password and would hold it until somebody signed out. Two mornings of reception were worked from a paper diary with patients waiting. The practice manager asked whether the desk had broken the computers, and the desk's week went into reopening and re-answering tickets it had already solved. The fix was one sentence added to the reset reply, "sign out of the reception PC and back in, then it will work", and the reopens stopped the same day. The fix had been right twenty-three times, and the reply had been wrong twenty-three times, which reopens a ticket just as reliably.

The Reopen Cause Table

The table puts the five causes beside what each looks like on the reopened ticket and the fix a technician applies on that ticket. It also gives the fix the desk applies to its process so the cause stops recurring, and who owns the process fix. Copy it into the knowledge base and refer to it from the classification card. When the weekly review has sorted a month of reopens by cause, the right-hand columns are the agenda.

A sixth row appears on some desks, and it is worth watching for without adding it to the table. It is the fix that was right, verified, explained and still failed, because the underlying system is unreliable in a way the desk cannot control. Those reopens are real and they are not the desk's cause. They belong to the vendor, the network, or the change that broke it. The right response is a linked set of tickets and a conversation with whoever owns the system. That is a problem-management matter rather than a reopen one. Put them in the review under "not ours", with the evidence attached, and do not let them inflate the desk's own five.

Sam's whiteboard stayed up for a month. Each Friday he added the week's reopens under one of the five headings. By the fourth Friday the premature close and the communication gap columns were empty. The verification column had two, and the workaround column had the label printer, now a single linked set with a part on order. The whiteboard had done what the reopens had been trying to do all along. It had turned forty faults into five reasons and five reasons into four fixes, and the fifth was in the post.

Frequently Asked Questions