The Monthly Close Review

First Friday of the month, 14:00, and Grace has twenty ticket numbers on a sheet of paper and a coffee going cold beside the keyboard. She opens the first. The last message is from the requester: "Any update on this?" Below it, a status change to Resolved, two days later, no reply. She makes a mark. The second ticket has a resolution note; it says "done". Another mark. The third is a small masterpiece: four lines, the cause named, and the user's confirmation quoted with a time. The category is corrected from "e-mail" to "disk space" because that is what it turned out to be. She writes the ticket number in a box at the bottom of the sheet labelled "best this month" and moves on. Seventeen to go.

At a desk across town the same Friday, nobody is doing this. That desk's dashboard shows resolution times falling and the queue under control. Its manager has concluded from those two facts that the closes are fine. Nobody has opened a closed ticket there in a year except by accident, while searching for something else, and finding "done". The dashboard measures how fast tickets close. Nothing on it measures whether they closed well, because no counter can read a note.

A close review is a monthly reading of a small sample of closed tickets against a fixed set of questions. Was the note usable? Was confirmation asked for and recorded honestly? Is the category right? How long did the ticket sit between the fix and the close? The close review is the feedback loop for everything else in this series. This article is part of our Closing Tickets Properly series. It is the last one, because it is how the other five stay true after the first month.

It covers why to review closes at all, and how to draw a sample of twenty that tells you something. Next come the four things to look for, one at a time, and a scoring table. Then it covers giving the feedback without turning the review into a ranking, and the forty-five minutes, laid out. It finishes with what the review feeds, and the close review sheet to run it from.

Why Review Closes at All

The close is the only part of a ticket the future reads, and it is also the part no metric sees. Resolution time measures the gap between open and Resolved. Reopen rate counts the tickets that came back. Satisfaction scores the users who answered. None of them opens the ticket and reads the last entry. That is where the quality of a close actually lives. It lives in a note a stranger could follow, a reply the user received, and a category that matches the fault. The review is the one instrument that reads.

Without it, closes decay. Notes shorten by a word a month until they reach "done". Confirmation requests lose their dates, categories stay at whatever intake guessed, and the end-of-day sweep comes back. This is not because anyone decided it should but because nothing pushed the other way. Standards agreed in a meeting last a quarter. Standards somebody reads for forty-five minutes a month last as long as the reading does. The review is not an audit and it is not a quality programme with a scorecard and a logo. It is one person, one afternoon, twenty tickets, and a sheet.

It also catches what the four parts of a proper close exist to prevent, before the cost arrives. A silent close shows up in the review in month one; without the review it shows up as a complaint in month three. A wrong category shows up in the review as a mismatch; without the review it shows up in the quarterly report as a decision made on the wrong pile. A note that says "done" shows up in the review as a fail; without the review it shows up next year as two days of rediscovery. The review takes forty-five minutes a month. The alternative takes the rest of the year, in small pieces.

Sampling: Twenty Tickets, Not All of Them

Read twenty tickets, not three hundred. Twenty is enough to see a pattern and few enough to read properly in half an hour. It is the same twenty every month in the sense that the method is fixed. That is what makes month four comparable with month one. A desk closing eighty tickets a month reads one in four. A desk closing six hundred reads one in thirty. Both read twenty, because the review measures the habits of the desk, and habits show in a sample. Reading every ticket turns the review into a job, and a job gets skipped.

Draw the sample so that nobody chooses it, including you. Export the month's closed tickets to a spreadsheet, or filter the list to Closed with last month's dates. Sort by ticket number, and take every Nth row where N is the count divided by twelve. That gives twelve tickets nobody picked. Then add eight on purpose. Take three that were reopened, three that were closed on notice without confirmation, and two that were closed without a fix. The last group is cannot reproduce or will not fix or out of scope. These selected closes are where the standard is hardest to keep and most worth checking. If the month had fewer than three of a kind, take what there are and fill from the random set.

Make sure every technician appears at least twice. If the random twelve leave someone out, swap one in rather than leaving the gap. A review that never reads one person's tickets has no basis for saying anything to them, good or bad. Write the twenty numbers on the sheet before you open any of them. The sample is drawn first and read second. The order matters, because a reviewer who reads as they draw will, with the best intentions, stop drawing when the pattern looks clear.

What to Look For: Note Quality

Open the ticket and find the resolution note. Ask the stranger's question: could a competent technician who was not there repeat this fix from what is written? That is the whole test, and it has three grades. Pass: the four lines are there, symptom, cause, fix and verification. The cause is honest including "not found" where that is the truth, and the fix names the things it changed. Partial: the fix is there and repeatable but the cause or the verification is missing or implied. Fail: the note is a word, a phrase, or absent; the reader learns that the ticket ended and nothing else. The structure the test expects, and why each line earns its place, is in Resolution Notes Worth Reading Later.

Read the note before the rest of the ticket, and score it before reading the history. If you read the history first you will understand the ticket and then judge the note kindly, because you now know what it meant. The stranger will not have read the history. Score what the stranger sees, then read the history to check whether the note is also true. That is a different question and occasionally has a different answer.

Mark the best note of the month as you go, with its ticket number and one line on why. It will be the single most useful output of the review, because it becomes the example the desk sees. A desk learns a standard from one good example faster than from a page of rules. The first review I ran on my own desk found the best note in the newest technician's tickets and the worst in mine. I have chosen to regard that as rigour.

What to Look For: Confirmation

The second question has two halves: was confirmation sought, and was the outcome recorded honestly. Look at the resolving reply, the message that told the user the fix was in. Does it exist? If the last message the requester could see is their own, there was no resolving reply. That is a silent close, which fails the question before it starts. The review counts these separately because they are the cheapest thing it will ever find to fix. If the reply exists, does it ask the user to try something specific, by a date, and say what silence will mean? The shape, and why each element matters, is in User Confirmation Without Chasing Forever.

Then read the end of the ticket. If the user replied with a yes, the note should say so, with the time. If the user never replied, the note should say "closed on notice" or words to that effect, not "user confirmed". In that case, the close should have come with a reply saying a reply reopens the ticket. A ticket closed on notice and recorded as confirmed is the review's most important catch. It is the one that corrupts every other number: the reopen rate, the satisfaction sample, and the stranger's trust in the verification line.

Count the nudges while you are there. Two is the rule. A ticket with four or five "just checking" messages is the chasing trap. A ticket closed the same minute as the resolving reply, with no window at all, is the other failure. Neither is a scandal in one ticket. Either, across six of twenty, is a habit the review exists to notice.

What to Look For: Category

The third question is whether the category matches what the note says the ticket turned out to be. Read the note's symptom and cause lines, then look at the category field. "E-mail" on a ticket whose cause line says the disk was full is wrong. It is wrong in the specific way that intake categories are wrong. The category was set from the first message, before anybody knew anything, and never revisited at close. The habit the review is checking is the two-second correction at the moment of the resolving reply, which is argued for in Categorize at Close, Not Just at Open.

Count "Other" and its cousins, "General", "Misc", "IT", separately. A ticket left in the catch-all is not miscategorised so much as uncategorised, and the fix is different. A miscategorised ticket needs the close habit. A catch-all ticket may need a category that does not exist yet. If the review finds four of twenty in "Other" with the same cause, that is a category the list is missing, and the reviewer has just found it without a meeting.

Tools differ in where the category lives: a dedicated field, a tree, a custom field on the form, or nothing at all. If your tool has none, the category is the first word of the resolution note, and the review reads it there. The question is the same wherever the field is. Does the label match the fault?

What to Look For: Time to Close After Fix

The fourth question is about two gaps. Both are readable from the ticket's history in most tools, where every status change and reply is stamped with a time. The first gap is between the fix being applied, which is the resolving reply or the resolution note, whichever came first, and the status being set to Resolved. In a desk that closes at the fix, that gap is minutes. In a desk that sweeps on Friday afternoon, it is days. A note written days after the fix is a note written from memory. That is why the first gap and the note quality score tend to move together.

The second gap is between Resolved and Closed, which is the confirmation window. About seven working days is the expected length when the user did not reply and the ticket closed on notice. A day or two is expected when the user confirmed quickly. Zero is expected when the fix was confirmed in the room. What the review is looking for is the tail. That includes tickets that sat at Resolved for three or four weeks, which means somebody was chasing or nobody was looking. It also includes every one of a technician's tickets going from Resolved to Closed in the same minute. That means no window exists in practice whatever the workflow says.

Work the gaps out in the spreadsheet rather than by hand. With the fix time, the Resolved time and the Closed time in three columns, a subtraction gives the first gap in days. Most spreadsheets have a function that counts working days between two dates. That way, a Friday-to-Monday window reads as one day rather than three. Write the two gaps on the sheet for each ticket and the median of each at the bottom. A median first gap over one day is a sweep. A median second gap under one day, on a desk that is supposed to have a window, is a window that is not being used.

The Scoring Table

Score each of the twenty tickets against the table, and keep the grades to three so that the scoring is quick and two reviewers would mostly agree. The rightmost column is where to look in the ticket, so a new reviewer can run the review from the table alone. Totals go on the sheet; the point of totals is to compare months, not to hit a number.

Three fails on one ticket is normal in the first month and means the ticket was a ten-second close. Three fails on the same question across twelve tickets is the pattern, and the pattern, not the ticket, is what the review reports. The sheet has a box for the top three patterns. Fill it from the totals, not from the ticket that annoyed you most.

Feedback Without Blame

The review's output is a pattern and a change, never a ranking. Share the desk-wide totals with the whole desk. An example is twenty tickets, eleven with no reply, six notes a stranger could not use, and four categories wrong. In that example, the median gap from fix to Resolved is two days. Those are facts about the desk. A desk that hears them as facts about the desk will fix them, because nobody was named and everybody recognises their own ticket in the count. Then show the best note of the month, with the author's permission and their name. Praise is the one place names belong, and a good example teaches faster than a rule.

Do not rank the technicians. Not in a table, not in a chart, not "just so we can see". A ranking turns the review into a contest, and a contest is won by closing the way the review rewards. That sounds like the goal until you notice the fastest way to pass "was confirmation recorded honestly". It is to stop asking for confirmation at all and record "closed on notice" every time. Many tools give each agent a private view of their own numbers and keep it private; respect that boundary in the review too. The desk sees the desk's score. Each person sees their own tickets.

Where one person's tickets carry one pattern, nine of their ten closes silent, say, the feedback is a conversation, not a line in a meeting. Sit with them, open two of their own tickets from the sample, and ask the stranger's question together. Most technicians who close silently believe they are being efficient and have never seen their tickets from the user's side. The two tickets do the work the conversation cannot. Agree one change, theirs, and check it in next month's sample, which will include their tickets because the sample always does. A review that ends in a private conversation and a changed habit has done its job. A review that ends in a score on a wall has started an argument.

The same principle runs through the breach review in the SLA series, where the rule is that the target breached and the technician did not. Here, the close failed and the habit did. The habit was shaped by the tool that made the status one click and the reply three. It was also shaped by the sweep that nobody forbade, and by the saved reply that did not exist. Change the shape and the habit follows. The parallel method, one review, one change, one month, is laid out in SLA Breaches and What They Teach. A desk that runs both will notice they fit in the same afternoon.

The Forty-Five Minutes

The review fits in forty-five minutes, protected on the calendar, on the first working Friday of the month, with the sheet, the export and a coffee. Minutes one to five: draw the sample, twelve random and eight chosen, and write the numbers on the sheet. Six to thirty: read the twenty, scoring each against the table as you go, noting the best note and the two gaps. Thirty-one to forty: total the columns, write the top three patterns, and compare them with last month's sheet. Forty-one to forty-five: choose the one change, write it with an owner and a date, and file the sheet with the others.

One change is the right number, for the same reason it is the right number in every monthly review. Two changes and next month's sheet cannot tell you which one worked. Typical first changes are a shared closing reply, a rule that the note comes before the status, or a two-second category check added to the close checklist. Typical later changes are smaller: a missing category added, a confirmation request reworded, a sweep moved from Friday afternoon to the moment of the fix. Month six's change is often "none, see note". Three of those in a row mean the closes are good. The review should then say so, in writing, somewhere the desk will see it.

Rotate the reviewer, after the first three months, through everyone on the desk who has the permissions to read closed tickets. A technician who has run the review once writes different notes for the rest of their career. That is because they have sat where the stranger sits and read "done" twenty times in an afternoon. Rotation also keeps the review honest about the reviewer, whose own tickets are in the sample like everyone's. The desk lead draws the sample and reads the sheet; the reviewer does the reading. Both sign the bottom, which is not bureaucracy. It is the two people who will remember what the sheet said.

What the Review Feeds

The review produces, as a by-product, the four lists that other practices live on. A reviewer who writes them down as they go has done an hour of someone else's work in the margins. The first is knowledge-article candidates: any note in the sample whose cause has appeared before is a third-time rule waiting to be applied. In that case, the ticket number goes in the sheet's follow-up box. The second is problem candidates: the cannot-reproduce closes, read together, and any note whose fix line says "workaround". The third is template changes: a confirmation request that users keep misreading, a closing reply that nobody fills in properly, a phrasing that produced a complaint. The fourth is category changes: the catch-all tickets with a common cause.

The review also cross-checks the reopen review, which reads the month's reopened tickets for what caused them. The three reopened tickets in the close sample are read here for how they were closed the first time. The answer is usually visible: no confirmation asked, a note that recorded a hope as a fact, or a reply that said "fixed" without saying what to do if it was not. Read in that order, the close review explains the reopens and the reopen review confirms it. The reopen side of the exchange is laid out in The Reopen Review; the two reviews share a Friday comfortably.

Keep the sheets. The pattern test on month four is "read the last three sheets". A desk with twelve sheets in a folder has a year of evidence about its own habits that no dashboard can produce. It is in a form a new desk lead can read in twenty minutes. The sheets also settle arguments. "Our notes are fine" is an opinion. Eleven sheets showing the note score rising from six of twenty to seventeen of twenty is a record. The sixteen-page quality framework somebody will eventually propose has nothing on it.

A Short War Story: The Sample at Ashgrove Housing

Ashgrove Housing's four-person desk ran its first close review after a ticket about the tenant repairs line recurred. It was a phone system fault that stopped tenants reporting repairs for a morning. It recurred five months after it was first fixed and took two days to diagnose again. That was because the original ticket's note read "done" and the technician who wrote it had moved on. Grace, the desk lead, drew twenty closed tickets from the previous month. She found eleven with no reply to the requester, six notes of five words or fewer, and four categories still showing the intake guess. There was a median gap of three days between the fix and the Resolved status. That turned out to be a Friday afternoon sweep that everyone did and nobody had agreed to. She shared the four totals with the desk without a name attached. She showed the one excellent note in the sample as the standard. It was written by Kwame, who had joined six weeks earlier. Grace made one change: a shared closing reply, with the rule that it went out before the status changed. The second month's sheet showed three silent closes instead of eleven and fourteen usable notes instead of six. The sweep had gone, because a reply written at the fix leaves nothing to sweep. The lesson was that the two-day rediscovery had been the cost of a note nobody read. It also showed that forty-five minutes a month had found in one afternoon what the desk had been paying for in two-day instalments.

The Close Review Sheet

The sheet is the forty-five minutes on one page. It is plain text so it can live in a shared folder, a knowledge article, or a printed binder beside the desk. Draw the sample into the first block before reading anything. The grid holds one row per ticket and the grades from the scoring table. The totals and the patterns are filled last. The one change is the only line anyone other than the reviewer needs to read.

CLOSE REVIEW — ONE PAGE
Desk: __________________  Month: ______________  Reviewer: ____________

SAMPLE (drawn before reading; 20 tickets)
  Random, every Nth from the closed list (12):  ______ ______ ______ ______
                                                ______ ______ ______ ______
                                                ______ ______ ______ ______
  Reopened (3):            ______ ______ ______
  Closed on notice (3):    ______ ______ ______
  Closed without fix (2):  ______ ______
  Every technician appears at least twice:  [ ] yes

GRID (P = pass, Pa = partial, F = fail; gaps in working days)
  Ticket   Reply   Note   Confirm   Category   Fix->Resolved   Resolved->Closed
  ______   ____    ____   ____      ____       ____            ____
  ______   ____    ____   ____      ____       ____            ____
  (one row per ticket; twenty rows)

TOTALS
  Reply sent:         P ____  Pa ____  F ____      (silent closes: ____ of 20)
  Note usable:        P ____  Pa ____  F ____
  Confirmation:       P ____  Pa ____  F ____      (silence recorded as confirmed: ____)
  Category right:     P ____  Pa ____  F ____      (in a catch-all: ____)
  Median gap, fix to Resolved: ____ days    Median gap, Resolved to Closed: ____ days
  Last month's totals for comparison: Reply ____  Note ____  Confirm ____  Category ____

PATTERNS (from the totals, top three)
  1. ______________________________________________________________________
  2. ______________________________________________________________________
  3. ______________________________________________________________________

BEST NOTE THIS MONTH
  Ticket ______  by __________   Why: _______________________________________

THE ONE CHANGE
  What: ___________________________________________________________________
  Owner: __________   Done by: __________   Check on next month's sheet: [ ]

FOLLOW-UPS FOR OTHER PRACTICES
  Knowledge-article candidates (repeat causes):  ______ ______ ______
  Problem candidates (cannot reproduce, workarounds): ______ ______
  Template or closing-reply changes needed: _______________________________
  Categories missing or to merge: __________________________________________

PRIVATE CONVERSATIONS NEEDED (names not on this sheet)   [ ] none   [ ] ____
Signed: reviewer __________   desk lead __________

Adapt the sheet to the desk, within limits. A one-person desk drops the technician coverage line and the private conversations box and keeps everything else, because the stranger it writes for is its future self. A desk with no category field strikes that column. A desk with no Resolved status collapses the two gaps into one, fix to Closed. What should not be adapted away is the order, sample first and read second, and the single change at the bottom. A sheet with three changes on it is a sheet that will not be able to say, next month, what worked.

Grace's twenty tickets took her thirty-eight minutes, and the sheet went in a folder with a one-line change at the bottom. Eleven months later the folder holds twelve sheets. The silent-close count on the newest is zero, and the best note of the month is a contested title. That is a strange thing for a help desk to compete over and exactly the right one. The close is the part of the ticket the future reads. The review is how the desk reads it first.

Frequently Asked Questions