Avoiding the Silent Close

Sofia in payroll raised a ticket about the shared finance drive on the first of the month. The drive opened, but every file in the month-end folder took forty seconds to load. She got an automatic acknowledgement with a number in it. Nothing else arrived. She tried the drive every morning, because month-end does not wait, and on the ninth day the files opened instantly. She was relieved, and then she was unsure. Nobody had told her anything had changed, and a thing that fixes itself can unfix itself. She replied to the acknowledgement: "Is this sorted now? Should I expect it to come back?" The reply came back from a new ticket number, from a technician who had not seen the original, asking her to describe the problem.

The original ticket had been marked Resolved on day three. The technician had found a stale index on the file server, rebuilt it, watched the folder open quickly from his own machine, set the status, and moved on. He had done the work. He had told nobody. Sofia found out by accident, six days later, by noticing. The desk's satisfaction report for the month shows a score of 9.1 out of 10, from fourteen responses, out of three hundred and ten closes. It is a very good score from a very small room.

A silent close is a ticket marked Resolved or Closed without a reply to the person who raised it. The fix may be real. The record may even be decent. But the status changed and no message went out, and from the requester's side nothing happened at all. This article is part of our Closing Tickets Properly series, which names "the user told" as one of the four parts of a proper close. It is also one of the seven quiet failures in The Seven Ways Support Quietly Fails, where it gets a section. Here it gets the whole article.

It covers what a silent close is, including the three disguises it wears, then why it happens, which is not laziness. Next come four things it costs, one at a time. These start with the user who finds out by accident, and the rating never asked for. Then come the reopen that is really a complaint, and the record that ends on the wrong voice. After that it covers the rule, which is closing with a reply every time, and what the reply contains. Next come the reply in five variations for five situations, and how to find the silent closes already in your queue. It finishes with making the reply cheaper than the click, and the closing reply itself, ready to save.

What a Silent Close Is

The plain form is a status change with nothing attached. The ticket goes from In Progress to Resolved, and no reply is sent. The tool, in many cases, sends nothing on its own. The requester's last message is still the last message in the thread. They raised a ticket and the ticket went quiet. From where they sit a quiet ticket is a ticket nobody has looked at. The desk counts a resolution. The requester, if they count anything, counts a disappearance.

The silent close wears three disguises, and each one feels like communication from the inside. The first is the internal note: the technician writes a good resolution note, with the cause and the fix, and sets Resolved. The note is excellent. It is also invisible to the requester, because internal notes are not mailed. The technician, having written something, feels that something has been said. The second is the empty reply: "Closing this ticket." Four words, mailed, that tell the user the ticket is over and nothing else; not what was wrong, not what was done, not what to do if it returns. The third is the fix made in person. The technician stood at the user's desk, fixed it, was thanked, and set Resolved on the walk back. So the one ticket with the strongest confirmation has the weakest record and no reply at all.

The test for all three is the same. Open the closed ticket, find the last message the requester could have seen, and ask whether it tells them what happened. If the last visible message is theirs, or an acknowledgement, or four words, the close was silent, whatever the note says. A note the requester cannot see is a diary entry. Useful, and not the same as telling anyone.

Why It Happens

Silent closes are not laziness, and the busiest technicians make the most of them, which should tell you something. They happen because the tool makes the status change one click and the reply a composition. At 16:50, with nine tickets to close, one click wins nine times. They happen because the technician believes the status is the message. In their view, the ticket says Resolved, so the user has been told, in the same way that a document is published once it is saved. They happen in the end-of-day sweep, where fixes from the morning are closed in a batch by someone who no longer remembers the details well enough to write them. And they happen after the in-person fix, where the thanks already happened and a reply feels like telling someone something they just said.

Underneath all of these is a quieter belief, which is that the reply is the optional part. The work was the fix. The reply is admin. A desk that holds this belief, even without saying it, will produce silent closes at a rate that tracks its workload. It will produce them most on the days it can least afford the consequences. The status field has never sent anyone a message. It would not know how.

Check what your own tool does before assuming anything, because tools differ and the settings page does not always say. Some send an automatic message on every status change. Some send one only at Closed and not at Resolved. Many send nothing at all unless a person writes a reply. Raise a ticket from your own address, resolve it without replying, and watch your inbox. If nothing arrives, every status-only close on your desk has been silent, and the users have known that for longer than you have.

Cost One: The User Who Finds Out by Accident

The first cost is that the requester learns the outcome by noticing it, or by not noticing it. Either way, the requester learns that the desk works in the dark. Sofia found out on day nine by trying the drive. Another user finds out when they reply to the acknowledgement and get a new ticket number back. A third checks the portal, sees Resolved beside a ticket they thought was still open, and wonders since when. None of them was told. All of them now know that the desk's definition of finished does not include them.

This costs trust in a way that is slow and specific. The next time this user has a problem, they weigh the ticket against the alternatives. Those are asking the colleague who knows things, messaging the technician directly, or waiting to see if it goes away. The ticket lost the last time because it went quiet, so the ticket weighs less. Nothing about this is a complaint. Nobody writes in to say they have decided to use the desk less. They just do, and the desk sees falling volume and reads it as success. The shadow channel that grows in the gap is the subject of the quiet-failures article. The silent close is one of the things that digs the gap.

It also costs the user the one thing they could not get elsewhere, which is the explanation. A user who is told "the drive was slow because the index had become stale; I rebuilt it; if files slow down again, reply to this and I will check it the same day" has something to tell their manager, something to recognise next month, and a way back. A user who notices the drive is fast again has a mystery. A mystery solved is not the same as a problem explained, and most people would rather have the explanation.

Cost Two: The Rating Never Asked For

The second cost is the satisfaction score, which a silent close quietly removes from the sample. In many tools the request to rate the service rides on the agent's resolving reply, the message that says the fix is in. In those tools, the status change on its own asks for nothing, and no reminder follows. So a ticket closed silently is a ticket the user was never invited to rate. A desk that closes a third of its tickets silently has a satisfaction figure built from the other two thirds. Those are the tickets where somebody bothered to write. Check how your own tool sends the rating request, because if it is tied to the reply, every silent close is a vote that was never cast.

The figure that results is accurate and misleading at once. Fourteen ratings averaging 9.1 is a true statement about fourteen people. Presented as the desk's satisfaction, it describes the experience of the users who heard from the desk, scored by the users who felt like answering. That is a sample selected twice for contentment. The users who found out by accident, who gave up, who replied to the acknowledgement and got a stranger, are not in it. The question never reached them. They are not dissatisfied in the report. They are absent from it.

Never present that number without the denominator beside it: fourteen ratings from three hundred and ten closes. Fourteen is not a satisfaction figure. It is a response figure, and the response figure is the honest one. It measures how often the desk spoke to the user at the close. A desk that fixes its silent closes watches the number of ratings climb and the score, often, fall. The score was never that high. It had been asked an easy question by a friendly subset.

Cost Three: The Reopen That Is Really a Complaint

The third cost arrives as a reopen, and it is the wrong kind. A reopen is a ticket marked done that the requester replies to, in many tools automatically changing it back to open and counting the event. Reopens are supposed to mean the fix failed, and read in bulk they tell you which fixes fail. A reopen on a silent close means something else. The reply says "Was anything done about this?" or "I see this is marked resolved, nobody contacted me". It is not a report that the fix failed. It is a complaint about being left out, filed in the only place the user could file it.

Mixing the two kinds poisons the reopen number. A desk with a reopen rate of one in ten wants to know whether its fixes are weak or its manners are. The remedies are different. A reopen caused by silence looks identical in the count to one caused by a fix that did not hold. Pull a month of reopens and read the first line of each reply. The ones beginning with a question mark about the ticket rather than the fault are the silent closes coming home. The reading method, and what to do with each kind, is in What a Reopen Is Telling You. Here the point is that a silent close manufactures reopens that are not about the work.

Tools differ in what happens when a user replies to a closed ticket. A desk that closes silently needs to know which case it is in. Some reopen the ticket with its history. Some open a new ticket, which is how Sofia met a stranger. Some bounce the reply because the ticket is closed, which is the silent close followed by a locked door. Test it, as the requester, once. Whichever your tool does, the fix for the complaint is the same: a reply at the close, so there is nothing to complain about.

Cost Four: The Record That Ends on the Wrong Voice

The fourth cost is the record. A ticket closed with a reply ends in the desk's voice: here is what was wrong, here is what we did, reply if it returns. A ticket closed silently ends in the requester's voice, usually "any update?", followed by a status change with a timestamp. A stranger reading that thread next year sees a question and then an ending. They cannot tell whether the question was answered, the problem solved, or the ticket simply swept. The best internal note in the world sits above that ending, and the stranger has to decide whether to believe it.

The monthly review, if the desk runs one, sees the same thing from above. A reviewer sampling closed tickets reads the last entries, and a desk with silent closes shows a pattern. The last entry is a status change by the agent. The last message is by the requester. The gap between them is where the reply should be. Counting those is the simplest audit of a desk's manners there is, and the method is in The Monthly Close Review. A review that finds one in four closes is silent has found the cheapest improvement available to the desk that quarter.

Closing With a Reply Every Time

The rule is one sentence: no ticket changes to Resolved or Closed without a reply to the requester in the same sitting. Not the walk-up. Not the one fixed in person with the user watching. Not the password reset, not the duplicate, not the one where the user said thanks in the corridor. That one especially needs a reply, because the thanks is a confirmation and the reply is where it gets recorded. The reply is the close. The status change is the filing.

The reply has three sentences, and it is the same three every time, which is what makes it quick. What was wrong, in the user's words rather than the technician's: "the month-end folder was slow because the server's index for that share had become stale". What was done, in one line: "I rebuilt the index this morning". What to do if it is not fixed or comes back: "reply to this message and the ticket will reopen with its history, so you will not have to explain it again". A fourth sentence asks for confirmation with a date where confirmation is needed, which is the subject of User Confirmation Without Chasing Forever. Where confirmation is not needed, the third sentence is enough.

Write the reply from the resolution note, not instead of it. The note is the technical record for the desk. The reply is the same facts for the user, with the hostnames and the suspicions taken out. Written in that order, note first, the reply takes under a minute, because the thinking has been done and all that remains is the translation. Written in the other order, or with the note skipped, the reply tends to say "this is now fixed", which is the empty reply in a slightly longer coat.

The channel the ticket came in by does not change the rule. It changes where the reply goes. A ticket raised by e-mail gets an e-mail. A chat ticket gets the closing lines in the chat, and a reply on the ticket as well if the tool keeps them separate. The chat window closes and the ticket does not. A walk-up gets a reply to the ticket the technician opened for it. The user did not ask for it and will be quietly glad of it when the problem returns and they need the number. A phone call gets the same. The reply is not for the conversation that just happened. It is for the one that happens next month.

I closed tickets silently for my first two years on a desk, and I believed I was being efficient. I was being efficient the way a letter is efficient if you write it carefully and do not post it. The fix was embarrassingly small: a saved reply with three blanks, and a rule that the Resolved button came after the Send button. The queue did not get slower. The reopens that were really complaints stopped, and I stopped meeting strangers who turned out to be my own users.

The Closing Reply in Five Situations

The three sentences bend to the situation, and the table gives the shape for the five that cover nearly every close. Read the second column for what changes. The third column is the sentence that does the changing. In every row there is a reply. That is the whole table, and the reason it exists.

The fourth row deserves its own article. Closing a ticket you could not fix is where the silent close is most tempting and most damaging. The technician has nothing good to say, so says nothing, and the user is left with a status that reads as a verdict. Each of those outcomes has an honest sentence, and the sentences are collected in Closing the Ticket You Cannot Fix. A silent close on a ticket that was fixed is a discourtesy. A silent close on a ticket that was not is a decision the user never got to hear about.

Finding Your Silent Closes

You can count your silent closes in an afternoon, and the count is usually the argument that fixes them. Pull last month's closed tickets from the tool, by export or by filter, and for each one look at two things. First is who wrote the last message the requester could see. Second is whether a reply from the desk sits between the last work and the status change. A ticket whose last visible message is the requester's, or the automatic acknowledgement, was closed silently. Most tools record every status change and every reply with who did it and when. So the order is readable from the ticket's history even when the summary view hides it.

Three quicker signs stand in for the full count when there is no afternoon. The first is the ratio of ratings sent to tickets resolved, where the tool ties the rating to the reply. In that case, a desk resolving three hundred tickets and sending ninety rating requests has closed two hundred and ten silently, whatever the technicians believe. The second is reopens whose first line is a question about the ticket rather than the fault. The third is the internal-note-only close. You find it by sorting closed tickets by the agent and reading the last few from each. One technician's tickets all ending in notes and no replies is a habit. A habit is the easiest thing on this list to change.

Count by technician, and then do nothing with the names for a month. The first count is nearly always a surprise to the people doing it, because nobody believes they close silently. They believe they are busy, which is true and different. Share the desk-wide number, agree the rule, put the saved reply in place, and count again in a month. The second count is the one that goes in the review. A technician who learns from the first count will have fixed it by the second. A review that punishes the first count teaches everyone to close silently in ways that are harder to count.

Making the Reply Cheaper Than the Click

The silent close wins when the reply costs more than the click, so the fix is to make the reply cost about the same. Most tools have saved replies under some name: canned responses, macros, templates. The closing reply belongs in one, with the three sentences written and the specifics left as blanks. Inserting it is one click. Filling two blanks is twenty seconds. The rating request, if the tool attaches one, comes along for free. A technician who has the saved reply and still closes silently is not saving time any more. They are skipping a step, and the review will see it.

Make the reply shared, if the tool allows it, so every technician's closing reply has the same shape. A shared reply means the user who raises three tickets a year gets the same three sentences each time, from whoever picked it up. The user learns to read them. A shared reply also means the review can check one thing: was the shared reply used, and were the blanks filled. A desk with six technicians and six personal closing replies has six standards, and one of them is "Closing this ticket."

Then change the order of the buttons, in habit if not in the tool: Send, then Resolved. Some tools let a reply and a status change go out together, as one action. That is the right way to use them, because the reply becomes the thing that resolves. Where the tool keeps them separate, the rule is the reply first, always. That way, a ticket interrupted between the two steps is a ticket with a reply and an old status, which is harmless. Otherwise, it is a ticket with a new status and no reply, which is a silent close with a timestamp.

Finally, give the in-person fix its reply before leaving the desk, or from the technician's phone on the walk back if the tool allows it. The in-person fix has the best confirmation and the worst record. The reply is what turns "they said thanks" into a sentence on the ticket with a time on it. It takes forty seconds. The user, who has already been helped, will mostly not read it. It is still the only written evidence that anything happened.

A Short War Story: The Quiet Quarter at Tollgate Foods

Tollgate Foods, a regional food distributor with a four-person desk, presented a quarterly satisfaction score of 9.2 to its operations director. The director had spent the quarter hearing otherwise from the depot. They asked how many responses that was: twenty-one, from about six hundred and forty closes. Ruth, the desk lead, pulled the closed tickets and found that three of her four technicians closed by status change alone. Every one of the twenty-one ratings belonged to the fourth. The depot office had meanwhile started a shared spreadsheet titled "IT things that were never fixed", thirty-four rows long. Of those, nineteen were tickets the desk had marked Resolved without a word. The depot had stopped raising tickets for most of two months and was e-mailing a driver who knew about printers. So the quarter's falling volume, also presented as good news, was the same failure from the other side. Ruth put a shared closing reply in the tool, made the reply the first step of every close, and counted again a month later. Ratings went from seven a month to about sixty. The score settled at 8.1, and the spreadsheet stopped growing. The lesson was that a satisfaction score from the people you spoke to measures how often you spoke to them. The desk had been measuring one technician's manners and calling it a quarter.

The Closing Reply

Save this as a shared reply with the blanks left in. The first paragraph is the one that changes per ticket. The second is the way back and should not be edited. The confirmation request is included for the common case and deleted when the fix was already confirmed. The whole thing is under a hundred words. The user who reads only the first line has been told the ticket is finished and why.

CLOSING REPLY — SAVED REPLY, THREE BLANKS
Subject: unchanged

Hello ______,

The problem was ________________________________________________.
What I did: ____________________________________________________.

If it is not fixed, or if it comes back later, reply to this message and
the ticket will reopen with its history, so you will not have to explain
it again.

[If confirmation is needed, keep this paragraph:]
Could you ______________________________ before __________ and let me
know it is working? If I do not hear back, I will close this ticket on
__________. A reply at any time will reopen it.

Thank you,
______
Ticket ______

[Delete the lines in brackets before sending.]

Two things to keep and one to resist. Keep the first sentence in the user's words. "The index for the share was stale" means something to them and "rebuilt the search index on fileserver2.example.com" does not. The hostname belongs in the note. Keep the way-back paragraph exactly as it is, because its job is to be recognisable the fourth time the user sees it. Resist adding an apology to the top of every reply. An apology belongs where something went wrong. A closing reply that opens with one on a ticket that went well teaches the user to expect that something did.

Sofia's drive is still fast. Her ticket is still marked Resolved on day three. Her reply still opened a second ticket on day nine. The two tickets are still not linked. So the next technician who searches for "finance drive slow" will find two half-stories and a stranger. One reply, on day three, would have made it one story with an ending. The silent close does not save the reply. It only moves it to someone else's ticket, later, with less in it.

Frequently Asked Questions