Closed Doesn't Mean Resolved: How to Find Customer Problems That Keep Coming Back

First contact resolution (FCR) measures the percentage of customer issues resolved during the first support interaction without requiring another contact about the same problem. It's useful for measuring support efficiency, but it doesn't always prove that the customer's underlying problem stayed resolved. A closed conversation is a record of an action a teammate took. It isn't, by itself, evidence of an outcome.

Support teams have gotten very good at measuring conversations — first reply time, close rate, CSAT per thread. Customers don't experience conversations. They experience problems. This page covers FCR's formula and how to proxy it in Intercom, then the more useful question underneath it: how do you actually know whether a problem went away?

What does "resolved" actually mean?

FCR, sometimes called first call resolution from the phone-center era, asks whether the customer needed to come back about the same thing. Email, chat, and Messenger all count. A new conversation about a different issue is not a miss.

FCR (%) = (conversations that did not reopen inside a defined window ÷ conversations marked resolved) × 100

Intercom doesn't ship a native FCR report. Most teams proxy it with reopen rate against a documented window — 24 hours is tight for email, 72 hours is a common B2B default. Three definitions have to be fixed before the percentage means anything: what "resolved" means, the follow-up window, and whether a second contact is the same issue or a new one. See every Intercom metric explained for close vs. reopen events.

There's no single industry number worth copying onto an Intercom inbox. Channel mix, product complexity, and whether Fin handles tier-one questions all change the rate. Published call-center ranges — often quoted around 70–80% — describe a different channel and a different "contact." Use your own baseline.

Closing a conversation isn't evidence the problem disappeared

Intercom's own guidance is that you should only close a conversation once it's fully resolved for the customer, and it recommends snoozing rather than closing while you're waiting on a customer or teammate. That's the right default. But Intercom's own documentation also concedes the harder case: after a customer hasn't replied for a week, it says closing may be reasonable because they may have already found a solution. Nobody did anything wrong there. There simply isn't enough evidence either way.

That ambiguity shows up constantly in ordinary support work:

• The customer stops replying after a suggested fix.
• A temporary workaround gets offered and accepted.
• The fix is waiting on engineering and the conversation gets closed anyway.
• The same problem resurfaces in a new conversation days later.
• A new conversation opens because a different symptom of the same root cause appears.
• An agent solves part of the request and closes the whole thing.

None of these are Intercom's fault, or usually an agent's fault. They're the ordinary shape of asynchronous support, where "closed" is a teammate action and "resolved" is a claim about the customer's experience that the conversation itself can't fully verify.

The problem with First Contact Resolution

FCR is genuinely useful for answering "how often do customers need additional help?" It's weaker at answering "did this customer's underlying goal eventually succeed?" — because it carries an assumption that doesn't hold for asynchronous SaaS support: fewer contacts equals better support.

A billing question might legitimately close in one exchange. A data-sync problem might legitimately need logs, an engineering ticket, a deployment, and a customer verification step over five days — several contacts, correctly used, ending in success. The desirable outcome isn't one contact. It's the customer's goal being achieved with reasonable effort. FCR, measured as a pure contact count, can't tell those two cases apart.

Repeat contact rate gets closer

Repeat contact rate is usually defined as: the same customer contacting support again about the same issue within a defined window. Definitions of that window vary widely across vendors — some use 24 hours, some use a 7–30 day range. There's no universal standard, which is itself a useful signal: pick a window, document it, and hold it stable, the same discipline FCR needs.

The distinction that most repeat-contact content blurs: repeat customer contact isn't the same thing as a repeat issue. A customer contacting support Monday about billing and again Friday about SSO isn't evidence Monday's conversation failed — those are two different problems. A customer contacting Monday because CSV exports fail, and again Friday because CSV exports still fail, probably is a repeat issue. Counting contacts without matching the underlying problem produces a repeat-contact number that's mostly noise.

Intercom already exposes reopened conversations and describes them as a potential signal of a recurring issue or a follow-up. But a conversation being reopened is a narrower event than the same underlying problem reappearing in a different conversation — the second case is where most real repeat problems actually live, and it's invisible to reopen-rate reporting alone.

Five ways a closed conversation can hide an unresolved problem

The second row matters most. Unknown is a legitimate classification. A customer going quiet after a suggested fix is different evidence from a customer saying "that worked," and treating both as resolved is what makes FCR and CSAT read healthier than the underlying support experience actually is.

Stop tracking tickets. Start tracking customer problems.

The stronger framing: resolution isn't an event, it's a hypothesis that later customer behaviour can confirm or contradict. Conversation A closes with a suggested fix and no reply — resolution status unknown. Seven days later, Conversation B says the same export is still broken. Conversation B doesn't just add a new ticket to the count; it changes what you know about Conversation A. That's new evidence about an outcome you'd already filed away.

That gives you an intelligence loop instead of a one-shot score:

Conversation → inferred problem → outcome evidence → subsequent behaviour → updated outcome

Applied to a real conversation, that's four questions worth asking on top of the transcript itself:

1. What was the customer actually trying to achieve? Not the literal first message — the underlying goal it was in service of.
2. What evidence do we have about the outcome? Classify it as confirmed resolved, likely resolved, partial/workaround, confirmed unresolved, or unknown — and let unknown stand as its own answer.
3. Has the same problem appeared before, for this customer? Same underlying issue, not just the same customer contacting again.
4. Did support promise a next step, and what happened afterward? A close that named "engineering will follow up by Friday" is only resolved if Friday's follow-up actually happened.

How to find these customers in Intercom today

This doesn't require another product to start. Intercom already exposes most of the raw material:

• Reopened conversations — Intercom's own reopen-event tracking is the closest built-in signal to a repeat issue on the same thread.
• Customer conversation history — check a customer's other recent conversations before treating a new one as unrelated.
• Intercom's AI Topics — automatically groups conversations and can surface a spike in one topic worth investigating for a shared root cause.
• Tags — a consistent intent tag is what turns "same customer contacted twice" into "same problem contacted twice."
• Snoozed conversations — a growing snooze queue on the same intent is often an unresolved problem waiting to become a reopen.
• Explicit unresolved language — "still doesn't work," "same issue," "again" are cheap to search for and rarely false positives.
• Follow-up workflows — a scheduled check-in message converts silence from "assumed resolved" into an actual data point.

Intercom's own Fin reporting already draws a version of this distinction: it separates confirmed resolution from assumed resolution, where an assumed resolution can mean nothing more than the customer didn't ask for a human or leave negative feedback. That's Intercom acknowledging, in its own product, that positive evidence of resolution and the absence of evidence of failure aren't the same thing. The gap above that is longitudinal — Intercom's Topics Explorer and CX Score aggregate at the topic level; the open question is what happened to this customer's specific problem across their subsequent conversations, not the topic's volume in aggregate.

AI makes problem-level support analysis practical

The historical path was tags → spreadsheets → manual QA — accurate, but too slow to run on every conversation. An LLM can now reasonably attempt goal extraction, semantic problem matching, outcome classification, commitment extraction, and longitudinal matching across a customer's conversation history, at a volume manual review never reached.

The failure mode to guard against is letting the model quietly upgrade an absence of evidence into a positive result — turning "customer stopped replying" into "problem solved." The whole point of treating unknown as a real state is that it survives contact with an AI classifier instead of getting rounded away by one. See calibrate AI customer support QA for how to check a model's classifications against a human-reviewed set before trusting it at scale.

The metric worth watching alongside FCR

Rather than a new named score, track same-issue repeat contact rate: the percentage of customers who contact support again about the same underlying issue within a defined window. Segment it by:

• Issue / intent
• Customer segment
• Agent or team
• AI vs. human handling
• Product area

It's operationally understandable in a way a proprietary composite score isn't, and it's the metric that actually tests the thesis above: are the same problems coming back, and to whom.

The bigger shift — from conversation intelligence to customer-problem intelligence

Most support tooling, including Supportman's current CSAT and QA scoring, treats each conversation as an independent unit: conversation happens, gets rated or scored, posts to Slack, done. The framework above treats a conversation as one piece of evidence in a longer-lived customer problem — customer → problem → conversations → outcome → follow-through — where a later conversation can retroactively change what you know about an earlier one.

That's the layer we're exploring next. It's a different question from "find unresolved conversations" (Intercom's Topics, Trends, CX Score, and Fin resolution reporting already do a lot of that) and different again from "find repeat contacts" (an established metric on its own). The question is whether the customer's problem actually went away — which needs a memory across conversations, not a better score on any single one.

Frequently asked questions