Reopen rate, the number your dashboard undercounts

Intercom can count reopens: the "Reopened conversations" metric exists in reporting, and custom metrics turn it into a percentage. The problem isn't that it counts nothing, it's that it counts one case out of two.

What a dashboard counts, and what it ignores

A closed conversation is an event. A solved conversation is an outcome. Support tools measure the first because it's trivial to instrument: an agent clicks, a status changes, a counter goes up. The second requires looking at what happens afterwards, and nobody looks afterwards.

The direct consequence: two teams reporting the same handled volume can live in opposite realities. One closes 1,000 conversations a month and 950 stay closed. The other closes 1,000 and 200 come back within a week. The dashboard congratulates both.

A definition that holds

A reopen is the same customer coming back on the same topic within a short window. Three parameters, and each one matters.

• Same customer. Watch out for multi-account customers and secondary addresses: plenty of reopens get counted as new conversations because identity never reconciles.
• Same topic. A customer coming back about something else isn't a reopen, that's an engaged customer. Without semantic grouping the two cases are indistinguishable.
• Seven days. Beyond that, causality gets arguable. Under three, you miss the topics where the customer tests the fix before coming back.

What the native counter sees, and what it misses

A reopen, to Intercom, is a closed conversation flipping back to open. Same thread, same id, trivial to link. That case is counted properly, and custom metrics will give you the percentage.

What the counter misses is the customer who didn't reopen anything: they started a new thread. To the tool, two separate conversations about the same problem are two requests. Linking them means understanding they're about the same thing, and a ticketing tool has no notion of topic. The native number is a floor, not a measurement.

The number to aim for

Across the accounts we audit, the seven-day reopen rate on conversations marked resolved sits between 12 and 27%. The range is wide because it spans very different situations, but the order of magnitude is stable: roughly one resolved conversation in six comes back.

Below 10%, verify before celebrating: that usually means reopens through alternative channels aren't being captured. Above 30%, the problem is rarely agent quality, it's almost always a knowledge base gap on a few concentrated topics.

What it reveals that CSAT misses

CSAT is declarative and self-selecting: mostly the delighted and the furious answer it. Reopen rate is behavioural. Nobody follows up out of politeness. When a customer comes back, the problem stayed whole, and that signal doesn't depend on any survey response rate.

It's also the metric that exposes optimistic automated resolutions. A conversation closed by an AI agent and reopened two days later counted as a win in the resolution rate, and as a failure to the customer. That deserves its own piece, we covered it in our analysis of containment rate.

Compute it this week

1. Export a full month of closed conversations, with customer id, closing date and first message.
2. For each customer, look for a conversation opened within seven days of a closure.
3. Group those pairs by topic. Doing it by hand on a sample of fifty is enough the first time.
4. Divide by the number of conversations closed over the period. That's your baseline.

The manual pass is worth doing once, because it shows you the topics as much as the percentage. After that it needs automating: ResponZ computes reopen rate continuously from your Intercom conversations, with the semantic grouping ticketing doesn't have.

A team tracking its reopen rate stops wondering whether it handles enough. It knows what it leaves behind.