“Resolved” is a judgment call, not a stopwatch
Teams under metric pressure learn to close chats fast, because a low average handle time looks good on a dashboard. But a chat closed before the customer's problem is actually solved is not a win — it is a future re-contact plus a dent in trust. The status should reflect the customer's reality, not the agent's queue.
When reopening is the right move
- The customer replies after the close saying it did not work — reopen, do not make them start over.
- You promised a follow-up (“I'll confirm once the refund clears”) and now have the answer.
- You closed on an assumption — “that should fix it” — and never got confirmation it did.
- A related issue surfaces that the customer clearly considers part of the same thread.
In each case, continuity is the gift: the customer keeps the context, and you keep the accountability.
When a follow-up beats a reopen
Not every loose end needs the chat itself reopened. If the resolution is genuinely done and you just want to check in, an async follow-up — an email, a proactive message on their next visit — is lighter and less likely to feel like you are reopening a wound. Reopen when the problem is unfinished; follow up when the problem is finished but the relationship deserves a nudge.
The quiet cost of premature closes
Closing too early rarely produces an angry message — it produces silence, a lower rating, and a customer who next time skips chat and just churns or disputes the charge. Because the damage is quiet, teams optimizing for handle time often never see it. Watch re-contact rate alongside handle time; a falling handle time with a rising re-contact rate means you are closing chats, not solving problems.
Make it easy to pick the thread back up
Reopening only works if the history is intact. Agents should be able to see the full prior transcript, who the visitor is, and what was promised — so the customer never re-explains. In MyLiveChat, conversations and transcripts are retained and searchable, and a returning visitor can be recognized, so continuing a thread is a matter of reading the history rather than reconstructing it from scratch.
Pick the thread back up properly
When a conversation is reopened, the first message decides whether the customer feels
remembered or feels like they are starting again. The difference is almost entirely in whether
the agent read the previous thread before replying.
Open by demonstrating you have the history. “I can see we replaced the adaptor last week
and it is doing the same thing — let me pick this up from there” tells the customer
they do not have to re-explain, which is the single most common frustration with returning to a
resolved issue.
Do not ask them to repeat troubleshooting that is already in the record. Being walked through
the same three steps a second time is what turns a mildly annoyed customer into an angry one,
and the transcript is right there.
Say plainly that the first attempt did not work, rather than treating the reopen as a fresh
incident. Acknowledging it directly — “that clearly did not fix it, sorry”
— costs nothing and defuses most of the tension the customer arrived with.
If the reopen is going to a different agent, the handover note matters more than usual. What
was tried, what was ruled out, and what was promised should all be visible without reading the
whole history, because under pressure the whole history will not be read.
An individual reopen is routine. A pattern of reopens is a diagnosis, and it usually points at
something other than the agent who closed the conversation.
The common causes are worth naming. Closing on the customer’s first sign of agreement
rather than on confirmed resolution — “I will try that, thanks” is not a fix.
Targets that reward closing quickly, which produce exactly this behaviour and are usually invisible
to the people who set them. Fixes that address the symptom while the cause persists. And
instructions the customer could not actually follow but did not want to say so.
Read reopened threads as a set every month. They cluster tightly, and the clusters name the
problem: one product area, one canned response, one workaround that does not hold. That reading is
considerably more useful than the individual conversations.
Be careful not to treat the reopen rate as a performance stick. The moment agents believe
reopens count against them, they stop closing conversations at all, and you have traded a
measurable problem for an unmeasurable one.
What to measure
Track reopens as a share of resolved conversations, split by how long after closing they
happened. A reopen within a day usually means the conversation was closed prematurely; one after
a fortnight is more likely a genuine recurrence, and the two need different responses.
Watch which resolution paths generate the most reopens. If one workaround accounts for a
disproportionate share, it does not work and the documentation saying it does should be changed.
Also compare reopen rates against average handling time — if handling time is falling while
reopens rise, you are not getting faster, you are moving the work later.