Closing the Ticket You Cannot Fix

Felix has had the laptop on his bench three times. Amira in claims says the screen flickers for a second or two, several times an hour, badly enough that she has started working from the meeting-room monitor. Felix has run it for a full afternoon each time, on the dock and off it, on battery and on mains, and has not seen it flicker once. It is 11:20 on the third day and he has nothing to say that he has not already said. He opens the ticket's status list and reads the options the tool offers for ending it: Closed, with a reason to pick from a second list. That list includes "Cannot Reproduce", "Won't Fix", "Duplicate" and "Invalid".

He picks Cannot Reproduce, sets Closed, and sends nothing, because there is no good news to send. Amira sees it an hour later in the portal, beside the ticket she raised three weeks ago: Closed, Cannot Reproduce. She reads it the way anyone would read it, which is "we do not believe you", and she does not raise the next ticket. The flicker is still there. The bench, as it happens, is not where she sits.

A non-fix close is a ticket that ends without the problem being solved, and there are six honest kinds. The desk will not fix it, the desk cannot reproduce it, or the user has accepted a workaround. Or the request is out of scope, the ticket duplicates another, or the requester has gone. Each is a legitimate ending, and each is a normal share of any desk's closes. And each is where the silent close does the most damage, because the technician has nothing cheerful to say and so says nothing. This article is part of our Closing Tickets Properly series. And it is about saying each of the six to the user, honestly, in a sentence or two.

It covers why a status or a close reason is never the message. Next come the six outcomes one at a time, with what the user needs to hear for each and what the note records. We cover a decision table across all six, then the three rules that apply to every non-fix close. We finish with the closing phrasings themselves, five replies and one internal note, written to be saved and reused without a joke in any of them.

The Status Is Not the Message

Close reasons exist for the desk, not the user. "Cannot Reproduce" in a status list is a label that lets the desk count how many tickets ended that way, which is useful. That is all it is for. Shown to the user, the same label reads as a verdict handed down without a hearing. The desk sees a tidy category. The user sees three words that imply they were mistaken, with no name attached and no way to answer. Some tools show the close reason to the requester, some do not, and some mail it. Find out which yours does, because a label meant for a report should never be the only thing a person receives.

Tools differ in whether the statuses and reasons can be renamed, and many small-team tools ship a fixed set. It does not matter. The meaning of a close lives in the team's written definition and in the reply, not in the label. A desk that spends an afternoon arguing about whether the status should say "Unable to Reproduce" or "Could Not Reproduce" has spent an afternoon on the wrong word. Whatever the list says, the user gets a sentence from a person. The list is for counting.

One label deserves a special mention, because it appears in many tools and should never be mailed to a human being: "Invalid". A ticket is never invalid. It may be a duplicate, out of scope, or a misunderstanding, each of which has a sentence; "invalid" is a word for a lottery ticket. And the user who raised it is neither. If your tool offers it, use it internally for the handful of tickets created by a mail loop or a test, and nothing else. A person asked for help. The least a close can do is use words.

The rule for all six outcomes is the same as for a fix: the close is a reply, and the status change is filing. The reply carries the honest reason, what happens next, and the way back, and it is sent before the status is set. Everything below is about what goes in the reply for each outcome. The mechanics of closing with a reply every time, and what a status-only close costs, are in Avoiding the Silent Close. This article assumes you have agreed to reply and is about what to say when the news is not good.

Will Not Fix

Will not fix means the desk could fix it, or could try, and has decided not to. The cost is out of proportion, or the change would break something for other people. Or a policy forbids it, or the thing the user wants is a feature nobody is going to build. It is the hardest of the six to say, because it is a decision rather than a limit, and the user is entitled to know who made it and why. "We won't be doing this" with no reason is a door closed from the inside. "We won't be doing this, because the change would remove the audit trail that finance relies on, and I checked with Priya in finance before deciding" is the same answer with a hearing attached.

Say who decided and on what grounds, in one sentence. Then say what the user can do if they disagree. That is usually to ask their manager to raise it as a request with the business case attached. Say that plainly rather than as a brush-off. A will-not-fix close that offers no route to challenge is a policy wearing a ticket. A desk that offers the route finds that most users do not take it, because most of them only wanted to know that somebody had thought about it.

Never dress a will-not as a cannot. "Unfortunately this isn't possible" when it is possible and you have decided against it will be found out the first time the user meets someone for whom it was possible. From then on every cannot the desk sends will be read as a will-not in disguise. I sent one of those once, about a second monitor, and the user turned out to sit next to someone who had three. The conversation that followed was longer than the one I had avoided.

Cannot Reproduce

Cannot reproduce means you tried to make the fault happen and could not, and it is a statement about your attempts, not about the user's experience. Say exactly what you tried: how many times, from where, under what conditions, for how long. "I ran the laptop on the bench for three afternoons, on the dock and off, on battery and mains, with the lid at several angles, and did not see the flicker" tells Amira that the desk took it seriously. It also tells her, usefully, where the desk has not looked: at her desk, on her monitor, in her light. Cannot reproduce is a statement about your afternoon. The fault lives in her morning.

Then say what would help next time, specifically. The time it happened, to the minute, so the logs for that minute can be read. A photograph of the screen, taken with a phone, since screenshots rarely capture a flicker. What was running, what had just changed, whether anyone else nearby saw it. Give the user a short list and a way to send it, and the next report arrives with evidence instead of adjectives. A cannot-reproduce close that does not ask for anything has told the user the matter is closed. One that asks has told them the matter is paused.

Frame it as "closed for now", in those words, with the way back stated. "I am closing this for now so it does not sit open with nothing happening; if it flickers again, reply to this message with the time and a photo if you can, and the ticket will reopen with everything we already know." The user keeps their place in the queue, so to speak, and the desk keeps the history in one ticket. Three cannot-reproduce closes on one fault, each with the time recorded, are a pattern a reviewer can see; three silent closes are three tickets that never met.

Do not imply the user imagined it, even gently, even by tone. "Are you sure it was the screen?" is a question that costs the desk a requester. The fault is intermittent, which is the most common kind of fault there is and the hardest to catch on a bench. The user is the only instrument that has observed it. Treat them as the instrument. Ask for readings.

Workaround Accepted

A workaround is a way of living with a fault rather than removing it. It might be a second route to the same result, a setting that avoids the trigger, or a manual step that replaces a broken automatic one. Workaround accepted means the user has agreed, in so many words, that the workaround is good enough for now and the ticket can close. The honest close says two things that are easy to blur. The problem is not fixed. And the ticket is closing anyway, because the user has what they need and the underlying fault is being tracked somewhere else.

Name where. The underlying fault does not vanish because the ticket closed; it becomes a known error. That is a fault the desk knows about, has a workaround for, and intends to fix properly at some point. It needs a home: a linked ticket, a line in a known-errors list in the knowledge base, or a problem record if the desk keeps those. Tell the user which it is and roughly when it will be looked at again. Put the same reference in the resolution note so the stranger next year knows this was a patch, not a cure. How a desk keeps that list and gets the permanent fix done is the subject of Known Errors and Workarounds.

Get the acceptance in the user's words before closing, not by inference. "Is the export-then-print route workable for you until the printing fault is fixed, or is it costing you too much time?" is a question with two honest answers. The second one means the ticket stays open. A workaround the user is merely tolerating is a ticket that will reopen the first week it costs them an afternoon. And a reopen on a workaround close is the user telling you the acceptance was never given. Ask once, properly, and record the answer. The question is the confirmation request in another form, and the timing rules in User Confirmation Without Chasing Forever apply to it unchanged.

Out of Scope

Out of scope comes in two kinds, and only one of them is a close. The first is a request for something the desk does not support. That might be a personal phone, software the organisation does not own, or a task that belongs to the user's own job. The honest close says so, names the policy or the written scope that says so, and offers whatever the alternative is. That may be nothing more than "the maker's own support line" or "your manager can request that it be added to what we support". The scope document that makes this sentence possible, and what to do when there is not one, is the subject of Saying What You Support. Without a written scope, every out-of-scope close is an argument the desk has to win alone.

The second kind is a request that belongs to a different team, facilities, HR, the application's own vendor, or a project team. And this is not a close at all. It is a transfer. Closing a ticket because the problem is someone else's leaves the user holding a closed ticket and a problem, with the instruction to go and start again somewhere else. Most users will not. Move the ticket to the team that owns it, or raise it with them and link the two. Tell the user who has it now and how to reach them. The handoff that does not drop the ticket on the floor is in Transferring a Ticket Between People or Departments. The only sentence that belongs in a close is the one that says the transfer happened.

Say the scope decision without apology and without sarcasm. "The desk does not support personal phones, so I cannot set up your mail on it; the written scope is on the intranet under IT Support, and if you need mail on a phone, the manager can request a work phone through the usual form" is dull and complete. It gives the reason, the source of the reason, and the way forward. The user may not like it. They will not be able to say they were not told.

Duplicate

A duplicate is a ticket about a fault that another ticket already covers, and there are two cases that the word hides. When the same requester has raised the same problem twice, often by replying to an acknowledgement from a new message, the two can usually be merged into one. In many tools that merge cannot be undone, so check which ticket survives before you do it. When different requesters have raised the same fault, the tickets are not duplicates of each other. They are evidence that the fault is shared. Those tickets should be linked under one name so that the fix, when it comes, reaches all of them. That also makes the count of affected users visible. Merging tickets from different people loses one of their names from the record. Link, do not merge.

Whichever case it is, the user hears which ticket now carries the work and how they will hear about it. "This is the same fault as the ticket your colleague raised yesterday; I have linked the two under one incident so you will both get the fix at the same time; replies to this number will still reach me." The sentence takes twenty seconds and it prevents the thing a duplicate close otherwise causes. That is a user who sees Closed beside their ticket, finds no fix, and raises a third one. A desk that closes duplicates silently manufactures its own duplicates.

Never close a duplicate as a way of making a number smaller. A ticket closed as a duplicate of a ticket that was itself closed as a duplicate is a chain that ends nowhere. A reviewer following it finds that the fault was never worked by anyone. Before marking a duplicate, open the ticket it duplicates and check that it is open and owned. If it is not, the new ticket is not a duplicate. It is the only live copy.

Requester Gone

Requester gone means the person who raised the ticket cannot be reached and the work cannot proceed without them. They have left the organisation. Or they have not answered the question the desk needed answering, after the two nudges a proper confirmation window allows, and nobody else can answer it. It is different from closing on notice after a fix, where the work was done and only the yes is missing. Here the work stopped, and the honest note says so: what was asked, when, how many times, and that the ticket closed because it could not be progressed.

Before closing, check whether the fault affects anyone else, because a requester leaving does not take the fault with them. A ticket from a departed user about a shared printer, a shared mailbox, or a slow application is a ticket about something that is still there. Open a fresh ticket in the desk's own name or a colleague's, and link it to the old one. And close the old one with a note that says where the work moved. If the fault was personal to the requester, their account, their laptop, or their access, the ticket can close with no reply to anyone. There is nobody to reply to. In that case, send one line to their manager if a shared resource or a licence is involved.

When the requester is present but silent, having never answered the "which error did you see" question, the close is a reply. It says plainly that the desk asked, waited, and could not continue. "I asked on the 3rd and the 7th for the exact message you see, and without it I cannot go further, so I am closing this for now; if you can send the message or a photo of it at any time, reply here and the ticket reopens." That is not a reproach. It is a record, and the record is what protects both sides when the ticket comes back. The desk-wide sweep that catches the tickets nobody closed this way is in The Stale Ticket Sweep. The aim here is to never need it for a ticket you could have closed honestly yourself.

The Decision Table

The table puts the six outcomes side by side. It shows the honest sentence the user gets, what stays open after the close, and what the resolution note must record. That lets the stranger next year tell this close from a fix. Read the third column before closing; if something should stay open and does not, the close is premature, whatever the user has been told.

Two patterns run down the table. Every row but one ends with a sentence to a person. And the exception is the departed requester, where there is no person to send it to. And every row records a reason in the note, because a non-fix close with no recorded reason is indistinguishable, a year later, from a ticket somebody gave up on. The reasons are short. They are also the only thing that separates a desk that closes honestly from a desk that closes.

Three Rules for Any Non-Fix Close

The first rule is an honest reason, stated as what it is. A will-not is a decision, and a cannot-reproduce is a limit of the attempt. A workaround is a patch, and a scope close is a policy. A duplicate is a pointer, and a gone requester is a stall. Each has a true sentence, and the true sentence is always shorter than the evasive one, because evasions need padding. A non-fix close needs a reason, a next step, and a sentence that does not begin with "unfortunately".

The second rule is a way forward, however small. That might be a route to challenge, a list of evidence to collect, or a reference to the known error. It might be the alternative support route, the surviving ticket's number, or the reply that reopens. The user leaves the ticket with something to do or somewhere to look, rather than a closed door. A close with no way forward is a verdict, and users do not raise tickets with courts.

The third rule is no blame, in either direction. Not at the user, who reported what they saw; not at a colleague, a vendor or a policy by name in a way that reads as passing the parcel. "The desk does not support personal devices" is a fact; "management won't let us" is a complaint dressed as an explanation. The user did not ask for the desk's opinion of management. State the decision as the desk's, give the reason, and stop.

A fourth rule, for tools that permit it: do not delete. Some tools let a ticket be deleted outright; many never do. The advice is the same either way. A mistaken ticket, a test, a mail loop, is closed with a one-line note or merged into the ticket it belongs to, so that the number still resolves to something. A deleted ticket is a number in someone's inbox that now points at nothing, and a count that no longer adds up. Closing costs ten seconds and keeps the record whole.

A Short War Story: The Verdict Pile at Stonebridge Insurance

Stonebridge Insurance's claims team reported, over about a year, that their claims application froze for three or four minutes at a time. The three-person desk closed fourteen tickets about it from nine different users with the reason Cannot Reproduce and no reply. That was because the application never froze on a technician's machine. The claims team gave up reporting it, named the freeze "the two o'clock" and planned their coffee around it. The team lead later put the cost at a quarter of an hour for each of nine people most working afternoons for a year. When Felix joined and read the fourteen tickets together, the pattern was in the timestamps: every report was between 14:00 and 14:12. That matched a scheduled scan on the file server that locked the application's shared data file while it ran. Moving the scan to 06:00 ended the freeze the same day. Felix closed a fifteenth ticket, raised in the desk's own name and linked to the fourteen. His reply to all nine users said what it had been. The lesson was that fourteen honest cannot-reproduce closes, each recording the time the user saw it and asking for the next one, would have found the scan inside a month. Fourteen silent verdicts hid it for a year. And the people they were handed to stopped asking.

The Five Closing Phrasings

Save these as shared replies and keep the blanks. Each is three or four sentences and follows the three rules: the reason, the way forward, no blame. The first five are replies to the requester. The sixth is an internal note for the requester who has left and cannot be written to. Fill the blanks with the specifics from the ticket, and do not soften the first sentence; it is the one the user came for.

THE FIVE CLOSING PHRASINGS — SAVED REPLIES
Subject: unchanged on every reply

1. WILL NOT FIX
  We have decided not to make this change. The reason is ______________________
  __________________, and the decision was taken by __________ after checking
  with __________. If you think the case for it has not been heard, ask your
  manager to raise it as a request with the reasons attached and it will be
  considered again. I am closing this ticket; a reply reopens it.

2. CANNOT REPRODUCE
  I have not been able to make this happen. I tried ______________________________
  on ______ occasions, from __________, for __________, and did not see it. That
  does not mean it is not happening where you sit. I am closing this for now so
  it does not sit open with nothing happening. If it happens again, reply to this
  message with the exact time, a photo of the screen if you can, and what you were
  doing, and the ticket will reopen with everything we already know.

3. WORKAROUND ACCEPTED
  As agreed, the fault itself is not fixed; the workaround is ____________________
  ________________. The underlying fault is recorded as ______________ and will be
  looked at again by __________. I am closing this ticket on that basis. If the
  workaround stops being workable, reply here and it will reopen.

4. OUT OF SCOPE
  The desk does not support ______________________, as set out in ______________.
  I am therefore closing this ticket. The route for this is ______________________
  ______________. If you believe it should be within what we support, your
  manager can ask for the scope to be reviewed through __________.

5. DUPLICATE
  This is the same fault as ticket ______, which is open and being worked by
  __________. I have ______ the two so that you will receive the fix and any
  updates on that ticket. You do not need to do anything; replies to this number
  will still reach us.

6. REQUESTER GONE — INTERNAL NOTE, NOT MAILED
  Requester ______ has left the organisation / has not responded to requests for
  __________ sent on ______ and ______. Work cannot proceed without it. Closed
  without confirmation. Fault affects others: [ ] no   [ ] yes, raised as ticket
  ______ and linked. Manager informed: [ ] not needed   [ ] yes, on ______.

Adjust the wording to the desk's voice but keep the structure: reason, next step, way back. Where a phrasing needs a name, use a real one. The wording "the decision was taken by the desk" is weaker than "by Felix after checking with Priya in finance", because a name is a person who can be asked. And resist adding a fourth paragraph of apology to any of them. The user wanted an answer. These are answers.

Amira's flicker, for what it is worth, was the meeting-room monitor's cable, which she had plugged into the laptop herself and which no bench would ever have seen. Felix found it on the fourth attempt, at her desk, after a cannot-reproduce close written the honest way had asked her to note the time and send a photo. The photo showed the monitor rather than the laptop screen. The honest close did not fix the fault. It kept the conversation open long enough for the fault to be found, which is the most a non-fix close can do. It is a great deal more than "Closed, Cannot Reproduce" ever did for anyone.

Frequently Asked Questions