Reopen-risk prediction

Reopened tickets cost more than the ones that stay closed. The customer has already waited once, the thread has to be read again, and the second visit usually lands with a different agent. A reopen-risk model scores tickets sitting in pending close and marks the ones most likely to come back.

The output is a ranked list, refreshed daily. Each row holds a ticket, a score, and the reasons behind the score. An agent works the top of that list and sends one message before the auto-close timer runs out. Nothing else about the ticket changes.

The model has no view of whether the fix worked. It reads the pattern of tickets that came back, then finds current tickets that resemble them. That distinction matters as soon as someone asks what is actually wrong with a flagged ticket. The honest answer is that it looks like tickets that failed.

Value shows up as fewer second contacts, not as faster handling. A team measuring this by handle time will watch the number get worse. The follow-ups take time. The return visits they prevent take more.

Every helpdesk counts reopens differently, and the definition decides what the model learns. A customer who answers two days after close is one case. A new ticket about the same problem three weeks later is another. Both are failures of confirmation, and only one of them registers as a reopen in most tools.

Write the rule down and apply it to history. A workable version: any customer contact about the same issue within thirty days of close counts. It counts whether it arrives on the old ticket or a new one. Matching the new ticket to the old one takes real work, and clustering tickets by underlying cause is usually where those links come from.

Exclude reopens that are not failures. A customer returning with a different question has not reopened anything. Neither has one who sends a thank-you note after close. Filter both out of the training labels, or the model learns to flag talkative customers.

Set the prediction window from the close policy. If tickets auto-close after five days of silence, the score has to arrive on day one or day two. A score produced on day six is a report, not a chance to act.

The strongest signals sit in the ticket's own history. Count of agent replies. Count of times the customer restated the problem. Whether the ticket changed hands, and the gap between the last agent message and the close. Tickets that bounced between two teams come back more often than tickets one person carried from start to finish.

Resolution shape matters as much. A ticket closed with a workaround differs from one closed with a fix. A ticket closed by policy, where the answer was no, is its own category. Tag the resolution type at close, and the model gains a feature that no text embedding recovers reliably.

The final customer message carries real signal, and it should enter as a label rather than raw text. The three-way read of that last reply belongs in the feature set, especially the unclear label. Tickets closed on an unclear reply deserve a second look more than any other group.

Some tempting features do damage. Customer tier and account value predict reopens partly because large accounts are more persistent. Feeding them in builds a model that follows up with big customers and quietly drops small ones. Keep them out here, and let tier-based handling stay in triage, where a person set that rule on purpose.

Here is an invented walkthrough. A vendor sells handheld barcode scanners and the warehouse software that runs on them, mostly to regional distributors. On a Monday morning, sixty tickets sit in pending close with the timer running. The model ranks all sixty and puts six above the action threshold. An agent receives that list of six.

Ticket one scores high for a familiar reason. Four agent replies, two handoffs, and a close entered by the agent rather than by the customer. The last customer message said the scanner works in the aisle but not at the dock door. Nobody answered the dock door part.

Ticket two scores high on resolution type. It closed with a workaround: rebooting the base station every morning. Workaround closes on hardware tickets came back often enough in the training data to carry weight, and the reason line says exactly that.

Ticket three is a false positive, and it should be easy to see as one. Long thread, three handoffs, high score. The customer then wrote a detailed message confirming that inventory counts finally match. The agent reads it in fifteen seconds and clears the flag.

The remaining three get one short message each, naming the specific thing that was fixed and asking about the part that was not. Two customers answer. One says everything is fine now. The other reports the dock door failure again, and the ticket reopens on the original thread with the original agent.

That wrongly closed ticket cost the customer nothing. No new ticket, no repeated serial number, no story told twice.

Label leakage is the first thing to check. Any feature recorded after the close will inflate offline accuracy and then disappear in production. That includes the follow-up an agent sent because of the flag. Freeze the feature set at the moment of close and rebuild the training data from that snapshot.

The model changes its own outcome, which breaks naive measurement. A flagged ticket gets a follow-up, the follow-up prevents the reopen, and the prediction now looks wrong. Hold back a small unflagged control group. Without it, nobody can say whether the model helps.

Threshold drift floods the queue. A flag with no capacity behind it is a list that nobody opens. Set the threshold from the number of follow-ups the team can send in a day, then move it when staffing moves.

Silence gets misread as risk. A quiet customer is not automatically an unhappy one, and an aggressive close policy will teach the model otherwise. Keep this model and the decision about what silence permits separate, so one bad assumption does not compound into two.

Old defects poison the features. Once a known bug ships a fix, tickets from before that release stop resembling tickets after it. Retrain on a rolling window, and read the reason lines for causes that no longer exist.

A flag produces a message from a person, not an automatic reopen. Reopening a ticket the customer considers finished creates its own irritation. The agent reads the thread, judges whether the risk is real, and either writes or dismisses.

Dismissals need a reason code, and those codes become the training data worth having. Confirmed by customer. Duplicate of another open ticket. Score driven by thread length alone. After a month, that list says more about the model than any accuracy figure.

Some flags call for a check instead of a question. Where the original failure can be run again, re-running it against the account gives a harder answer than asking the customer for one. Save the question for cases where no such check exists.

The auto-close timer belongs to policy, not to the model. A high score can hold a ticket open for a defined extra period, once, with the reason recorded on the ticket. It cannot hold tickets open forever. Review flagged and reopened tickets each month next to the quality scores on closed tickets, because those two lists overlap more than most teams expect.