Does Intercom's Fin AI 'Resolved' Rate Actually Mean the Issue Was Resolved?
No, not by itself. Intercom's own documentation splits a Fin resolution into two kinds: a "confirmed resolution," where the customer says something like "thanks, that worked," and an "assumed resolution," which is counted when the customer simply doesn't ask a follow-up question after Fin's last answer. Both count identically toward the resolution rate on your reporting dashboard. One of them means the problem went away. The other means the customer stopped talking, and the metric can't tell you which happened.
That gap is exactly what a commenter flagged on Hacker News, pointing at Intercom's own docs: "a Fin 'outcome' can be counted on, not only when a customer confirms resolution, but also when the customer simply does not ask for more help after Fin responds...A very soft resolution metric," they wrote. Intercom's billing runs on that same ambiguity: confirmed and assumed resolutions are charged the identical $0.99-per-outcome rate, so the same fee applies whether the customer said "thanks, that worked" or just went quiet. A customer who gives up and opens a ticket with a competitor's support team, or quietly starts routing around the product, produces the same "resolved" checkmark as one who got exactly what they needed.
What "assumed resolution" actually assumes
The assumption is a reasonable one on average: most people who got a real answer don't reply again, and most people who got a bad answer do. But averages hide the exceptions, and the exceptions aren't random. A customer who doesn't reply might have found the answer wrong and given up on Intercom as a channel entirely, gone looking in your docs, asked a teammate in a shared Slack channel, or just decided the feature gap wasn't worth fighting about. None of those paths write anything back to the conversation Fin just closed. The conversation looks identical whether the customer left satisfied or left annoyed, because "silence" is the one signal Intercom has no way to disambiguate from inside the conversation itself.
This is also, not coincidentally, the reading that's kindest to the number. A support tool billed per resolution has a built-in reason to count generously, and Intercom is transparent about the rule rather than hiding it. That transparency doesn't remove the gap. It just means the gap is documented instead of hidden.
Where Rasmey Sok found the real number
Meridock builds webhook-delivery infrastructure for e-commerce platforms, and its support desk is small enough that Rasmey Sok runs it alone, leaning on Fin AI Agent for the bulk of first-line questions. Most of those are "why did this webhook fail to deliver" variants that Fin answers from the docs and a set of custom answers about retry behavior. The Fin dashboard showed an 81% resolution rate for the quarter, which Rasmey put in a board update as evidence the support load was under control.
Two weeks later, an engineer flagged something odd in the API logs: three customers on the same integration pattern had all had a Fin conversation marked "resolved" in the same week, then reappeared in the churn-risk list within the month. Rasmey pulled the three conversations. Here's one of them:
Customer: Getting 429s on the retry endpoint intermittently, any docs on backoff?
Fin's answer references the standard exponential-backoff doc. The customer doesn't reply again.
Rasmey, re-reading it a month later: They didn't get an answer to the actual question. Our retry endpoint doesn't implement the backoff behavior the docs describe, that's a known bug, engineering just hadn't shipped the fix yet. Fin pointed them at documentation for behavior we don't have.
The conversation had counted as an assumed resolution because the customer never asked a second question in Intercom. What actually happened was they'd opened a ticket with their own team to route around the flaky webhook and started polling the API on a fixed timer instead of trusting retries, which is exactly the kind of workaround that shows up as reduced usage before it shows up as a cancellation. Nothing about that path touched the Intercom conversation again.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat you can check natively, and what it tells you
Before reaching for anything else, Intercom gives you two ways to sanity-check the resolution number against a real outcome:
- Reopened conversations. If a customer returns to the same conversation Fin already marked resolved, that reverses the resolution charge and reopens the thread, per the same pricing documentation, which is the cleanest native signal that "resolved" was wrong. It only catches customers who come back to that exact conversation, though, not the ones who route around Intercom entirely.
- Fin AI Agent CSAT. Intercom surfaces an emoji-based satisfaction survey at specific moments, on positive feedback, at handover to a human teammate, or after a stretch of customer inactivity, and reports a CSAT score for Fin separately from the resolution rate: the percentage of "amazing" or "great" ratings out of every conversation that got rated. A resolution can be assumed with no CSAT rating attached at all, which is worth knowing before treating the two numbers as versions of the same thing.
Put those two together and you have a genuine cross-check for anything that happens inside Intercom. What neither covers is Rasmey's actual case: a customer who didn't reopen the conversation and never left a rating, because from Intercom's side, nothing else happened. The signal that something was wrong lived in the API logs and the churn-risk report, two systems Intercom has no visibility into.
When the next mention happens outside Intercom
The pattern generalizes past this one story. Intercom's reopen and feedback signals only work when the customer's next move happens inside Intercom. Most of the time, it doesn't. A customer who got a bad answer might:
- Mention the same problem in a sales call the next quarter, with no link back to the original conversation
- Post in a shared Slack Connect channel instead of reopening the Intercom thread
- File a bug against the underlying behavior in your public GitHub repo
- Simply stop using the feature, which shows up in usage data weeks before anyone notices
Each of those is a real signal that the "resolution" wasn't one. None of them will ever touch the resolution rate, because the rate is scoped to what happens inside a single Intercom conversation. Checking harder inside Intercom, more CSAT prompts, more manual review of reopened threads, doesn't fix this, because the missing signal was never in Intercom to begin with.
This is the point where the honest fix stops being "read Intercom more carefully" and starts being "read something other than Intercom too." Modem is built for that gap: it connects to Intercom conversations alongside Slack, GitHub, and the rest of a team's support and engineering tools, and instead of trusting the resolved flag, it reads the conversation content itself and matches it against whatever the same customer says next, wherever they say it. When Rasmey's customer opens a GitHub issue about the same retry behavior a month later, or the account shows up flagged in a churn-risk view, that's the same topic Fin marked resolved, now carrying the evidence that it wasn't. We work on Modem, so keep that in mind when you read this part; it's one piece of the customer context graph approach, not a replacement for Fin or for Intercom's own reporting.
Below the scale where a request can quietly resurface three tools away from where it started, Intercom's native signals genuinely hold up. A five-person team with a hundred Fin conversations a month can eyeball reopens and low CSAT ratings and catch most of the false resolutions by hand. The problem shows up as volume grows and the second mention of a request lands somewhere nobody happens to be looking, which is closer to what happened at Meridock than any failure of Fin's answer quality.
The short version
A Fin resolution rate measures how often a conversation ended without the customer asking another question in that same thread. That is a real, useful number, and it is not the same thing as a fixed problem. Intercom's own documentation is explicit about the difference between confirmed and assumed resolutions; the risk isn't that Intercom is hiding the gap, it's that a headline percentage gets reported without anyone checking which kind of resolution made it up. The fix inside Intercom is to weight reopens and CSAT more heavily than the raw rate. The fix for requests that resurface outside Intercom entirely is to have something watching for that, which is a different tool than the one that answered the question in the first place.
For the related question of what a request costs to answer once you're past whether it was truly resolved, see why Intercom's Fin AI is so expensive per resolution. For turning the requests hiding inside Intercom conversations into something a roadmap can act on regardless of how they closed, see how to track feature requests in Intercom.
