Preventing Reopens with a Check Before the Close

At 16:58 on a Thursday, Jonah at the Acme desk has the shared calendar permissions fixed for the sales team, or believes he has. He can see the calendar from his own account. He types "Permissions updated, should be fine now", presses Resolve, and leaves at 17:01. At 08:20 on Friday the ticket is back, because the sales team's assistant opened her calendar, saw the same error, and replied "Still can't see it". Jonah will spend twenty minutes on it and discover that the permission needed her to close and reopen the calendar application. He will close the ticket again with a better note. The whole reopen was decided at 16:58, in the two minutes between "I think it's fixed" and Resolve. It could have been prevented by a single question.

Preventing reopens means the habits that live in those two minutes. Those are the check that the fix works where the requester works and the question that asks them to confirm it. They also include the reply that tells them how to tell, and the short wait before the ticket is finally closed. None of it is technical. All of it is routinely skipped, because the fix feels finished the moment it works from the technician's chair. This article is part of our Reopened Tickets series. The earlier articles sorted, measured and traced reopens; this one is about not having them.

It covers where reopens are decided, and the four moments between fix and close. Then comes verifying from the requester's seat, with what "verified" means for the common ticket types. Next come the fix-check question and how to ask it, and the resolving reply that prevents the reopen. After that come the confirmation window and what to do on silence, and the workaround declared as a workaround. Next are updating the knowledge base before the close and turning all of this into a habit rather than a memory. Last come a short war story about a console that said "installed" and the pre-close verification checklist, built to be printed.

Where Reopens Are Decided

A reopen is decided before the ticket is closed, not after. By the time the requester replies "still broken", everything that caused the reopen has already happened. The fix was made, or half made; it was checked, or not. The reply was written, or not; and the ticket was moved to a state that invited the reply. The requester's reply is a measurement of those four moments. Prevention is about the moments, which is why it is cheap. A reopen costs an hour of two people's time. The check that prevents it costs two minutes of one person's.

The four moments map to the causes in The Root Causes Behind Reopens. The fix moment is where the premature close and the wrong problem solved happen: the ticket resolved on intent, or the right fix made to the wrong thing. The check moment is where no verification happens. The reply moment is where the communication gap happens. The waiting moment is where a tool closes a ticket too fast or a desk chases a requester too long. Both of those produce reopens of their own. Each moment has one habit that closes it, and the four habits together are the checklist at the end of this article.

The honest reason desks skip the moments is that each one feels like a delay on a ticket that is already done. The fix works. The next ticket is waiting. Verification is a conversation with a requester who may not answer for an hour, and a resolving reply with three parts takes longer to write than "sorted". Every one of those feelings is accurate and every one of them is a loan at a bad rate. The two minutes saved at 16:58 are repaid at 08:20 with interest, by the same technician, on the same ticket, in front of the same requester.

Verify From the Requester's Seat

Verification means the fix has been seen to work where the requester works: on their machine, in their session, with their account, doing the thing they reported they could not do. It does not mean the change was made. It does not mean the change took effect on the server. It does not mean it works for the technician. A permission that the console shows as granted, a drive that the technician can see, a password that the directory accepts, are all claims about the fix. The requester opening the calendar is the check.

There are three ways to verify, in order of preference. The first is to watch the requester do it, in person or in a remote session, which takes a minute and catches everything, including the sign-out nobody mentioned. The second is to do it as them. Sign in to their machine with their account, or impersonate the account where the tool allows it, and perform the task. The third, when neither is possible, is to ask the requester to do it now and tell you the result. Do this while the ticket is still open and you are still on it. The third is the weakest, because it depends on a reply, and it is the one most desks use for everything. Move one notch up the list on any ticket that has reopened before.

Some fixes cannot be verified at once, and those tickets stay open. A change that needs an overnight job to run, a replication that takes an hour, a part on order, a tablet that will pick up an update when it next connects: none of these is a fix yet. The ticket goes into a waiting status with a note that says what it is waiting for and when to check. It is resolved after the check, not before. Resolving now and trusting the overnight job is the premature close with a timer on it. The timer always goes off at 08:20.

The table says what "verified" means for the tickets a small desk sees most. The middle column is the check the technician can do alone; the right-hand column is the one that only counts from the requester's seat. Resolve on the right-hand column.

The last row is the honest one. An intermittent fault cleared by a restart has not been verified and cannot be, because the only test is time. Those tickets are resolved as workarounds, with the note saying so, or held open through the interval the fault usually takes to come back. The section on workarounds below says how to choose. What they are never is "fixed, verified" on the strength of the symptom being absent at 15:10.

The Fix-Check Question

The fix-check question is one sentence asked before Resolve, and it is the cheapest habit in this series: "Can you try it now, while I'm on this, and tell me exactly what you see?" It asks for three things at once: an action from the requester, an answer within the ticket's lifetime, and a specific observation rather than a verdict. "Is it OK now?" invites "I think so", which is not verification. "Open the calendar and tell me what you see" invites "it opens, I can see Tuesday's meetings", which is.

Ask it with the step attached. If the fix needs a sign-out, a restart, a re-add or a refresh, the question includes it: "Sign out and back in, then open the calendar and tell me what you see." Most "right fix, still broken" reopens are a step the requester did not know to take. The question is where the step gets said. A fix that needs a step the reply did not mention is a reopen waiting for the morning.

Ask it by whatever channel gets an answer soonest. On a desk where the requester is nearby, that is walking over. Where there is a phone, it is the phone, with a note on the ticket afterward. Where it is e-mail, it is e-mail, and the ticket waits in a waiting status for the reply, not in Resolved. The question is also where the wrong-problem reopen gets caught, because a requester asked to open the monthly report when they meant the weekly one will say so. That correction costs nothing now and an afternoon later.

On a ticket that has already reopened once, the question is not optional and the answer is not taken on trust. The requester tries it while the technician watches or is on the line. The ticket is resolved only after the words "yes, that's working" have been said about a specific thing. Handling a Reopened Ticket Well, earlier in this series, covers the rest of that conversation. The point here is that the desk's one free mistake with this requester has already been spent.

The Resolving Reply That Prevents the Reopen

The resolving reply says four things, in the requester's language: what was wrong, what was done, how to tell it is working, and what to do first if it is not. The first two are the record. The third is the verification handed to the requester, so that "working" means the same thing to both of you. The fourth is the part that prevents the reopen, because it names the step the requester might still need. For example: "If the calendar still shows the error, close the calendar application completely and open it again; the permission is applied the next time it starts."

The "how to tell" line does the most work for the fewest words. "You should now see the Sales Team calendar in your list on the left, with next week's meetings in it" gives the requester a test they can run in ten seconds and a result they can compare. "Should be fine now" gives them nothing. A requester with nothing to compare against will report the first odd thing they see, whether or not it is the original fault. Writing resolution notes that survive is the subject of the Closing Tickets Properly series. This article only insists on the two lines that keep the ticket closed.

The reply is the message, in every tool. Changing a status tells the requester nothing in most tools. In the few that send a notification on a status change, it is a bare line nobody reads. If a satisfaction rating is requested, it usually rides on a reply rather than on a status, so a close without a reply is also a close without a rating. Close with a reply, every ticket. If the same four parts are being typed for the tenth time, make them a reply template and fill in the specifics. The template is where the sign-out line lives permanently, which is how the Harbourview Clinic reset reply from the root causes article stopped reopening.

The Confirmation Window

The confirmation window is the short period after the resolving reply during which the ticket sits in Resolved, or whatever your tool calls the state between fixed and finished. During that period, it waits for the requester to confirm or to disagree. A reply in that period reopens the ticket onto the same history with the same owner, which is exactly what you want. Silence through the period is taken as confirmation, and the ticket moves to Closed. The window exists because verification by e-mail depends on a reply, and the reply often does not come. The window turns no reply into a yes without the desk chasing anyone.

Three to five working days is the usual length, and the reasoning is in resolved versus closed, which owns the status design. The companion piece on user confirmation without chasing forever owns the conversation. Two rules from both belong here. First, the resolving reply says how long the window is and that a reply reopens the ticket, so the requester knows the door is open and for how long. Second, the window is not a second chance to skip verification. A ticket resolved without the fix-check question and left to the window will reopen on day one or sit silent while the requester finds another route. Neither is confirmation.

The window also needs to agree with the reopen window in the desk's metric definition, the one from Measuring Reopens Honestly. A desk that closes tickets after three days but counts reopens for seven has four days where a reply either reopens the closed ticket, if the tool allows that, or creates a new one, if it does not. Check which yours does with a test ticket. Set the confirmation window no longer than the reopen window so that a reply inside the measurement period lands where the measurement can see it.

The Workaround Declared as a Workaround

A restart that clears a fault is a legitimate resolution the first time, provided the ticket says so. The note reads "restarted the print service; symptom cleared; cause not found". The resolving reply tells the requester the same in their words: "I have cleared it for now; if it comes back, reply to this ticket and say when, because that will help us find why." That reply does two things no "fixed" can do. It sets the requester's expectation honestly, so the return of the fault is a report rather than a betrayal. It also asks for the one fact, the timing, that finds the cause.

The second time the same fault is cleared the same way, for the same requester or a different one, the ticket is linked to the first and both are flagged for the weekly review before either is resolved. Most tools can link tickets. Where yours cannot, a shared word in the subject line and a note on each pointing at the other does the job. From this point the fault is a candidate problem rather than a run of incidents. The right desk response is the one in known errors and workarounds: keep applying the workaround to get people moving, record each occurrence, and spend the review's time on the cause.

Whether to resolve a workaround ticket or hold it open through the interval depends on the interval. A fault that returns within a day is held open in a waiting status for a day, then resolved if it has not. A fault that returns weekly is resolved as a workaround and the requester is asked to reply when it does. That is a reopen the desk has invited and should count as kind two without embarrassment. What a desk must not do is resolve it as "fixed" and be surprised. Surprise is for faults the desk has not seen before. This one has a ticket number.

Update the Knowledge Base Before You Close

A fix that changed a step changes the article that describes the step. The article is updated before the ticket is closed, while the detail is fresh and the technician is still looking at it. The knowledge base is the desk's collection of written answers, for technicians and sometimes for requesters. A stale one produces reopens on its own. The next technician follows the article, the article omits the sign-out, and the ticket closes on the claim. The reopen arrives with nobody understanding why, since the article was followed exactly. The article was followed exactly. The article was wrong.

The update is usually two minutes. Add the sign-out line. Correct the menu path that moved. Add the "how to tell it worked" check to the bottom of the procedure, because every knowledge article about a fix should end with the verification for that fix. Use the same words the resolving reply uses. Where the fix is genuinely new, a short article with the symptom, the cause, the fix and the check is written while the ticket is still open. That article is linked from the resolution note, so the next ticket about the same thing finds it by search. Most knowledge bases let a new or changed article sit in an internal or draft state until someone reviews it. Use that rather than letting the lack of a reviewer stop the writing.

If there is no time to fix the article, flag it. Most knowledge bases have a way to mark an article as outdated or needing review. A flag with a one-line note, "needs the sign-out step; see ticket 4418", is worth more than a correct article nobody got round to. The weekly review reads the flagged list. A desk that closes tickets on a wrong article and never flags it will keep closing tickets on a wrong article. It will do so most confidently, because it is following the documentation.

Making Prevention a Habit Rather Than a Memory

Habits survive busy days; memory does not, so the four moments are built into the desk's workflow rather than left to each technician's conscience. The strongest form is a status: a waiting-for-confirmation state between working and resolved, which a ticket must pass through, and which a technician cannot skip without choosing to. Many tools ship a fixed set of statuses and the name may not be ideal. The meaning lives in the desk's written definition, not the label. So pick the status that fits and write down that it means "fix made, check pending". The desk that has this status verifies on its worst day. The desk that relies on remembering verifies on its best.

The second form is the checklist on the wall, or pinned in the tool, or printed and taped to the monitor of anyone who closed three not-fixed reopens last month. It is at the end of this article. It is deliberately short enough to be read in the two minutes it is meant to fill. A checklist longer than a screen is not read, and an unread checklist has the same effect as no checklist with slightly more paper.

The third form is measurement that rewards the habit. A desk that reports on resolved tickets rewards resolving; a desk that reports on confirmed closes and the reopen rate rewards closing properly. Move the number the desk looks at from the first to the second, and the two minutes stop feeling like a delay and start feeling like the job. The weekly glance at the month's not-fixed reopens, which the reopen review at the end of this series describes, is where the habit is kept honest. That is because a not-fixed reopen is by definition a close that skipped the check.

On a desk of one, the habit is the same and the enforcement is the resolving reply template, with the four parts and the window sentence already in it. A solo administrator cannot be watched and should not be; the template watches the template. Write it once, use it every time, and treat any ticket closed without it as a ticket that is still open.

A Short War Story: The Console That Said Installed at Ashgrove Housing

Ashgrove Housing's desk, Tomasz and one colleague, pushed an update to the repairs application on the housing officers' tablets from the management console. The console reported "installed" for every device the moment the update was queued. Tomasz resolved the fourteen tickets that had asked for the update with "installed, you're good to go". Over the next three days all fourteen reopened from officers in the field whose tablets had not been on the office network since. Those tablets still had the old version, which now refused to open against the updated server. The repairs team logged a week of inspections on paper and re-keyed them. The repairs manager complained in writing about "IT closing tickets before doing the work". The desk spent two days reopening and re-chasing tickets it had already answered. The fix was to resolve each ticket only after the tablet reported back and the officer had opened the application once. That took the same fourteen tickets four days instead of four minutes and reopened none of them. A console's "done" is a claim about the fix, and a claim is not a check.

The Pre-Close Verification Checklist

The checklist is the two minutes before Resolve, on one page. Every item is a box, every box is a fact, and a ticket with an empty box in the first three sections is not ready. Print it, pin it, or paste it into the resolving reply template as a reminder that is deleted before sending. On a ticket that has reopened before, every box is mandatory and the fix-check question is asked live.

PRE-CLOSE VERIFICATION CHECKLIST — BEFORE YOU PRESS RESOLVE
Ticket: __________   Fix made by: __________   Date: __________

THE FIX
  [ ] The fix is done, not scheduled, queued, pushed or expected
  [ ] It was done to the right thing: the device, account, mailbox or
      report named in the ticket, confirmed with the requester if in doubt
  [ ] If it depends on a job, sync or reboot that has not happened yet,
      the ticket stays in a waiting status with a note saying what and when

THE CHECK
  [ ] Seen to work from the requester's seat: they tried it while I was
      on the ticket, or I tried it as them on their machine
  [ ] Any sign-out, restart, re-add or refresh the fix needs has been done
  [ ] The fix-check question was asked and answered with a specific result
  [ ] If the fault is intermittent and was cleared by a restart, the note
      says "workaround; cause not found" and the ticket is handled as one

THE REPLY
  [ ] Says what was wrong, in the requester's words
  [ ] Says what was done
  [ ] Says how to tell it is working: one thing to look at, one result
  [ ] Says what to do first if it is not, including any step they must take
  [ ] Says the ticket stays open for ____ days and a reply brings it back

THE RECORD
  [ ] Resolution note says what was actually done, including the check
  [ ] Knowledge base article updated, or flagged with the ticket number,
      if the fix changed a step or the article was wrong
  [ ] Related tickets linked if this fault has been seen before

THE WAIT
  [ ] Status is the fixed-but-not-finished state, not Closed
  [ ] Confirmation window: ____ days; the ticket closes on silence after that
  [ ] No further chasing after the window; silence is a yes

The checklist shrinks with use. After a month, most technicians carry the first three sections in their heads and only the record section needs the paper, which is as it should be. The paper was there to build the habit, not to replace it. After three months, the only tickets that need the full list are the ones that have reopened, and that list is short, because the checklist is why.

Jonah, the Friday after the calendar ticket, had the shared mailbox permissions to fix for the same sales team. He made the change, walked to the assistant's desk, and asked her to open the mailbox. He watched her close and reopen the application when it did not appear, and watched it appear. The resolving reply took him three minutes and said all four things. It was closed on silence the following Thursday. He did not think about it again, which is the entire point of the two minutes.

Frequently Asked Questions