A Fin resolution came back when the same customer contacts you again about the same problem after Fin marked their conversation resolved. Intercom reports the resolution. It doesn't report the return, unless the customer replies in the same thread, and most don't.
This guide is the method for counting them yourself. The four states and what each costs are in Fin resolution states. Here we use those states to find out whether the resolutions held.
Coming soon: Supportman will show which Fin resolutions came back, as an ongoing view instead of a one-off count. Get notified at launch. Want the count now? The Fin audit reads a slice of your conversations and sends back the scored report.
Three ways a customer comes back after Fin
| Return shape | What you see in Intercom | Does Fin's billing deduction fire? |
|---|---|---|
| Replies in the same conversation | The conversation reopens | Yes. The resolution is deducted and not charged, even across billing periods |
| Starts a new conversation about the same problem | Nothing links it to the first one | No. The deduction follows the thread, not the problem |
| Writes in on another channel (email, a different widget) | A separate conversation under the same contact, if the contact matches | No |
The first row is the one every report can see. The second and third are the more common shape once a customer has given up on the thread, which is the same gap described for human-handled conversations in reopened support tickets.
How do you build the came-back cut?
- Pick the window and write it down. Seven days works for most chat issues. Use 14 if the problem involves engineering or a refund. The reasoning is in repeat contact rate.
- Pull the Fin-resolved conversations for a period that ended at least one window ago, so every conversation has had time to come back. Split them by the Fin AI Agent resolution state attribute: confirmed resolved and assumed resolved.
- For each conversation, list the same customer's later conversations inside the window, on any channel.
- Match on the issue. Same customer plus the same intent tag is a repeat. Where tags are missing, read the pair. A customer who asked about billing and then about SSO hasn't come back.
- Record how they returned: same thread, or new conversation.
- Divide. Came-back rate = resolutions with a same-issue return within the window ÷ resolutions in the group. Report it separately for confirmed and assumed.
Sample if the volume is large. Fifty assumed resolutions read carefully will teach you more than 5,000 tallied by script with unreliable tags.
What does it look like with numbers?
Hypothetical: 400 Fin-resolved conversations from a period at least 7 days old. The numbers are made up to show the arithmetic. They aren't benchmarks, and Intercom doesn't publish a typical figure.
| Resolution state | Resolved | Same-issue return within 7 days | Came-back rate |
|---|---|---|---|
| Confirmed resolved | 150 | 6 | 4% |
| Assumed resolved | 250 | 40 | 16% |
| All Fin-resolved | 400 | 46 | 11.5% |
The blended 11.5% hides a four-to-one gap between the two groups. Now split the 46 returns by shape: 9 came back in the same thread and 37 as new conversations. That's 37 of 46, or 80%, that no reopen report would show, and none of which triggered a billing deduction.
How do you read the result?
| What you see | What it suggests | Look at |
|---|---|---|
| Assumed came-back rate far above confirmed | Silence is being counted as success on some intents | The intents the returns cluster on |
| Both rates high on one intent | Fin is giving an answer that doesn't work | The knowledge source behind that answer |
| Most returns are new conversations | Your reopen count understates the problem | Add the customer-level match to your report |
| Returns arrive with a request for a person | The handoff came too late | Turns before escalation. See AI's job stops at the human handoff |
| Low everywhere | Resolutions are holding, or customers who are stuck have stopped writing | CSAT and unrated conversations beside it |
Low isn't automatically good. A customer who gave up on support doesn't generate a repeat. Read the came-back rate next to CSAT, and see measuring whether Fin is resolving conversations for the rest of the set.
What do you change when assumed resolutions come back?
- The answer. Read the Fin reply on the three most common returning intents and compare it with what a teammate says. If the article is thin or out of date, fix it first.
- The ending. Fin's reply that ends the conversation can ask whether it worked. A confirmed resolution is evidence. An assumed one is a guess.
- The handoff rule. If customers return asking for a person, lower the number of turns Fin gets before offering one on that intent.
- The review cadence. Sample assumed resolutions weekly. How to QA Intercom Fin has the five checks and the sampling routine.
What can Supportman do today?
Supportman's Fin view shows Intercom's own resolution state for each Fin conversation next to its CSAT and an AI evaluation score. It displays Intercom's verdict. It doesn't compute a resolution state of its own, and it doesn't detect reopens or repeat contacts. Counting which resolutions came back is what the Fin audit does today: we read a slice of your conversations and send back a scored report. An ongoing version of that view is coming soon, and the Fin Audit Dashboard is the related in-product work. The full set of Fin pages is in the Fin library.
Frequently asked questions
What happens when a customer returns to a conversation Fin resolved?
If they reply in the same conversation asking for more help, the resolution is deducted and not charged, even across billing periods. If they start a new conversation about the same problem, nothing links it to the first and no deduction happens.
Are assumed resolutions more likely to come back?
You can test that on your own data by comparing the came-back rate for assumed and confirmed resolutions, as above. An assumed resolution counts 24 hours of disengagement as success, so it carries less evidence than a confirmed one.
What window should I use for a Fin repeat contact?
Seven days for most chat issues, 14 for anything involving engineering or a refund. Pick one, write it down, and keep it stable so the trend is comparable.
Does Intercom report Fin repeat contacts?
Intercom reports Fin's resolution states, including assumed and confirmed. Matching a later conversation to an earlier resolved one on the same issue isn't part of that reporting, so the came-back count has to be built from conversation history, as above.
What is a good came-back rate for Fin?
There's no published benchmark. Set your own baseline from the last few weeks, split by resolution state and intent, and watch the direction.