The Ticket That Resolved Itself

Summary: A customer reports a problem and then goes quiet, usually because they found a workaround. The ticket ages out and closes as resolved. The support metrics improve. Nothing was fixed, and the strongest signal about a real defect leaves the system labelled as a success.

Pattern

A customer opens a ticket describing something that does not work. Support responds, asks a clarifying question, and waits.

The customer does not reply. After some number of days the ticket auto-closes, or an agent closes it during a queue cleanup, with a note about no response received. The status is resolved. The underlying defect is untouched, and the customer has quietly routed around it — or around you.

What tends to happen

The initial report is often vague, because the customer is describing a symptom in a system they do not have a model of. Support asks for specifics: version, steps, screenshot, account ID.

Gathering that costs the customer more effort than the original report did, and they are already behind on the work the failure interrupted. So they find another way to accomplish the task — a different endpoint, a manual export, a colleague who knows a trick, a competitor's tool for that one job.

Having solved their immediate problem, they have no remaining incentive to reply. From their side the matter is closed. They may even feel mildly guilty about the unanswered message, which makes replying later more awkward, not less.

The ticket ages. An automation sends a nudge, then a final notice, then closes it. In the metrics this appears as a resolved ticket with a short time-to-resolution and no negative satisfaction score, because unanswered tickets do not generate satisfaction surveys.

The defect stays in the product. Six other customers hit it over the following months. Most of them do not open a ticket at all, because the first thing anyone does with a broken feature is look for a way around it.

Why it fails

The system treats silence as satisfaction. It is the single most consequential inference in support tooling, it is made constantly, and it is wrong more often than not.

Silence after a support interaction has several possible causes: the problem resolved itself, the customer found a workaround, the customer gave up, or the customer left. Only the first is good news, and it is not the most common. The tooling cannot distinguish between them and so collapses all four into resolved.

The second failure is that the ticket is treated as the unit of work rather than the defect. A ticket is a conversation, and conversations end. A defect is a property of the product, and it persists whether or not anyone is currently discussing it. When the conversation closes, the only record of the defect closes with it.

The third is that the intake burden is placed on the person with the least context and the most urgency. The customer is asked to produce a reproducible case, which is a skill, in the middle of being blocked, which is the worst moment.

Human layer

For the agent, an unanswered ticket is genuinely ambiguous, and the ambiguity resolves in a comfortable direction. Closing it clears the queue, improves the numbers, and involves no confrontation. Chasing it costs time and mostly yields nothing. Over a few hundred tickets this pressure is not subtle.

For the customer, replying to a support thread about a problem they have already worked around is pure cost with no benefit to them. It is an altruistic act toward a vendor, performed during working hours they are not being paid to donate. Most people decline, and they are being rational.

For the product team, the absence of the signal is invisible. There is no experience of not hearing about something. The defect does not appear in any list, so it does not compete for prioritisation, so it is never deprioritised — it is simply never a candidate. It cannot lose an argument it was never in.

And support metrics reward exactly this behaviour. Resolution rate goes up, time to resolution goes down, and the numbers improve most in the periods when the most tickets are abandoned. Everyone is doing their job as measured.

System layer

Auto-close on inactivity encodes the wrong inference in a rule that runs constantly and is never reviewed. It was configured once to keep the queue manageable, and it does that.

There is no separation between the conversation and the defect. Nothing creates a persistent product-side record when a report arrives, so closing the thread destroys the evidence.

There is no clustering across tickets. Six reports of the same underlying failure, described in six different vocabularies by six customers who do not know the internal name for the thing, are six unrelated closed tickets. Nothing surfaces the pattern because nothing is looking for one.

Satisfaction surveys fire on resolution but not on abandonment, so the population sampled excludes precisely the customers who had the worst experience.

And the reporting path requires the customer to produce diagnostic information that the system could have captured automatically at the moment of failure.

What it costs

The defect persists, and its cost accrues to every customer who encounters it — most of whom never report it, because the first response to a broken feature is a workaround, not a ticket.

The support metrics become actively misleading. A team can improve every headline number by getting worse at follow-up. Once that is true, the metrics stop measuring support quality and start measuring queue hygiene, and decisions made on them point the wrong way.

Product priorities skew toward whatever generates persistent, articulate complaints — which correlates with customer sophistication and available time, not with severity. The loudest problems get fixed. The most common ones may not.

The most expensive cost is not measurable from inside. A customer who works around a defect has downgraded their reliance on the product. They did not churn, complain, or appear anywhere in the data. They simply stopped depending on you for that job, and when renewal comes they will describe the product as useful for less than they once would have. Nothing in any system connects that to a ticket closed months earlier.

Reduction path

Stop inferring resolution from silence. An unanswered ticket should close as unresolved — no response — and that state should be visible and counted. The queue still gets cleaned; the difference is that the number now exists. Watching it is usually enough to change behaviour, because it turns out to be larger than anyone expected.

Separate the defect from the conversation. A report of something broken creates a product-side record that outlives the thread. Closing the ticket closes the conversation, not the finding.

Move the diagnostic burden off the customer. Capture context automatically at the moment of failure — version, request identifier, account, the state that produced the error — so the first response can be an attempt at a fix rather than a request for homework.

Cluster reports by symptom rather than by ticket, including the closed ones. The pattern lives in the aggregate of abandoned threads, which is exactly the data currently being discarded.

And sample the silent ones. A small, periodic outreach to customers whose tickets closed unanswered — asking only what they ended up doing — returns the signal the closure destroyed. The answers are uncomfortable, which is the reason it is worth doing.

If none of this is anyone's current job, that is the thing to fix first — how a scoped engagement handles this kind of instrumentation work is a separate question from whether the work is worth doing.