Silence-as-resolution detector

A ticket with no reply for a week has to go somewhere. Leaving it open forever distorts every queue metric and buries the tickets that still need attention. Closing it on the assumption that the customer is happy invents a fact. A silence detector decides which quiet tickets may close on schedule and which ones need a person first.

The output is a recommendation with a reason attached: close now, wait longer, or hold for review. The ticket state changes only through the workflow rule that consumes that recommendation.

The claim recorded at close matters as much as the timing. Closed without customer confirmation after seven days of silence is true. Resolved is a statement about the customer's experience that nobody verified. Store those as different values, or analytics built on the second one will report a success rate the team never earned.

Cost is the honest motive here. Agents spend real hours chasing tickets that no longer have a customer attached. The model exists to stop that spend without hiding failures inside it.

One global timer fits nothing. A ride-charge dispute and a failed login run on different clocks. Set the silence window per issue type, and set it from how long the customer plausibly needs, not from how long the queue can tolerate.

List the issue types that may never close on a timer. Anything involving money owed to the customer. Anything with a safety or injury report. Anything where the resolution was a promise about future work. Those wait for a person, indefinitely if that is what it takes.

Define the state a ticket must reach before the clock starts. The issue was addressed, a message went out, and that message asked a specific question. A ticket that went quiet because the agent never replied is not a silence case. It is a missed ticket, and auto-closing it hides the miss.

Decide what counts as contact. An opened email is not an answer. A visit to the help center is not an answer. Read receipts tempt teams into treating attention as agreement, and they are wrong often enough to stay out of the rule.

Require at least one follow-up attempt before any automatic close. A message that names the fix and the close date changes what the silence after it means. Without that message, silence only shows that nobody asked.

The strongest safety signal is a positive last reply. When the customer's final message said the problem was gone, later silence is consistent with a fix that held. The classifier that labels that reply supplies the input, and its unclear label should block a timed close rather than permit one.

Account behavior is the second signal, where it exists and where it relates to the complaint. A rider who reported failing unlocks and has taken four rides since is saying something without writing. General product usage proves nothing about a specific problem, so keep the link tight.

Some conditions should hold a ticket every time. A prior reopen on the same issue. An angry final message. A close recorded as a workaround rather than a fix. A ticket that changed hands more than twice. Each one routes to a person instead of a timer.

Weak signals get promoted to strong ones constantly. Days since last contact is not evidence. Count of messages sent is not evidence. Neither says anything about whether the product works. They belong in the scheduling logic and nowhere near the safety judgment.

This example is fictional. A bike-share operator runs docked and dockless bikes in two cities, with support handled almost entirely inside the app. On a given day, four hundred tickets have been silent past their window.

Most look alike. A rider reported a bike that would not unlock, an agent released the reservation and credited the ride, and the rider never wrote back. The last outgoing message named the credit and the close date. The model recommends closing, with the outcome stored as closed without confirmation.

Ticket 8812 is held. A rider was charged for a ride that ended at a dock. The agent asked for the dock number, the rider answered once, then stopped. No refund has been issued, so money is still in dispute. Money open means no timed close, however quiet the thread has become.

Ticket 9034 is held for a different reason. The last rider message reads "fine, whatever." The classifier returned unclear, and the tone was negative. Silence after an unhappy message is not agreement. An agent reads that thread the same day.

Ticket 7750 closes early. The rider wrote that the bike unlocked on the second try and everything was fine, then went quiet. That is a confirmed resolution followed by silence, and it needs no waiting period at all. The record says resolved, confirmed by customer.

Across the four hundred, the model recommends closing most, holds a few dozen, and stamps every closure with how it was reached. The queue shrinks and the failure cases stay visible. Teams usually get the first result and lose the second.

Quiet metric improvement is the classic trap. Auto-close makes resolution time and open counts look better immediately, because the tickets simply left. Track reopen rate and repeat contact rate next to those numbers, or the dashboard rewards the wrong behavior.

Vulnerable cases hide in the quiet pile. Customers with thin language coverage, shared inboxes, or slow internal approvals reply late and get closed most often. Sample closures by segment. A policy that closes one group far more than the others is a policy problem, not a model problem.

Broken notification paths look exactly like silence. A customer whose email bounces, or whose app notifications are switched off, is not declining to answer. Check delivery status before counting a day of silence, and treat a bounce as a reason to try another channel.

Short windows manufacture their own reopens. Closing at three days on issues that take a week to observe produces a wave of second contacts, each costing more than one follow-up would have. The model that predicts which closures come back is the check on this failure.

Timed closes paired with automated action need tighter limits. When an agent that executes refunds and account changes sits upstream, it is possible that no human read the ticket at any stage. One human read before close is a reasonable floor on that path.

A closed ticket has to reopen on a plain reply, with the thread intact and the same ticket number. The customer types one sentence and lands back with the original agent when that agent is available. Anything that makes them restate the problem turns a small failure into a large one.

Set the reopen window generously. Thirty days works as a default, longer for billing disputes. After the window closes, a new contact should still link to the old ticket, so the history travels even when the number does not.

A named person owns the policy, usually the support ops lead. That person sets the windows, the excluded issue types, and the hold conditions, then reviews them quarterly. The model applies rules and does not choose them.

Read a sample of timed closures every month, and read the reopened ones in full. Each reopen names something the policy allowed and should not have. Where a real check is possible instead of a guess, re-running the failing action against the account answers the question that silence left open.