Fin Resolution States: Assumed, Confirmed, Escalated, Abandoned

Fin leaves every conversation in one of four resolution states: confirmed resolved, assumed resolved, escalated, or abandoned. The first two both bill at $0.99 and both appear in your resolution rate, but only one of them involves a customer saying anything. The other counts 24 hours of silence as a win.

Below: what each state means and what it bills, what Intercom's model gets right, where it breaks and what that's costing you, and how to find the conversations Fin booked as resolved that plainly weren't.

The four states Fin can leave a conversation in

The state lives on a conversation attribute called Fin AI Agent resolution state, which holds the most recent state for that conversation. Intercom's Fin AI Agent reporting docs define the four values like this:

Note what separates assumed resolved from abandoned. Both are silence. The only difference is whether Fin got an answer out before the customer stopped replying. One bills, one doesn't.

Intercom's Fin AI Agent report template carries a metric for each of these, including a separate assumed resolution rate and confirmed resolution rate alongside deflection rate, answer rate, involvement rate, and escalation rate. They're there by default. You don't need to build anything to see them, though knowing which of those numbers counts what takes a minute. Every Intercom metric, explained covers the rest of the set.

What each state costs

Fin bills on outcomes, not states, and the mapping isn't one-to-one. Intercom's outcomes documentation lists what's billable:

Three billing rules are worth committing to memory:

• One outcome per conversation. Fin can answer six questions and run two Procedures in a single thread and you're charged once.
• A reopen refunds the charge. If a conversation was resolved, confirmed or assumed, and the customer comes back to that same conversation asking for more help, the resolution is deducted and not charged, even across billing periods.
• A new conversation about the same problem is a new conversation. The refund follows the thread, not the customer or the issue.

That third rule is the one that costs you. A customer who gets a bad answer, gives up, and opens a fresh conversation two days later leaves the original assumed resolution billed and intact. Your invoice reads clean. Your repeat contact rate doesn't.

Escalated, procedure handoff, and constrained are three different things

"Fin sent it to a human" describes at least three states with different billing and different meanings, and Intercom uses different labels in different reports. Worth untangling before you build a dashboard on the wrong one.

The trap is Procedure handoff. It looks like an escalation in every human sense, it costs the same as a resolution, and it's the one handoff line that grows your bill. If you've built Procedures that end in a handoff to a team, your "Fin didn't resolve it" bucket is not free, and your escalation rate won't tell you that. Check the outcomes breakdown instead.

The Rules & guidance split under Fin Escalated is the one to read weekly. A rising share there means your own routing rules are pulling conversations out of Fin, not that Fin is failing. Go and review the rules before you go and write an article.

None of these states say anything about how well the handoff went: whether it happened three exchanges too late, or whether the agent inherited any context. That's a separate scoring job, covered in handoff quality scoring and in the argument that AI's job stops at the human handoff.

Fin Voice uses different words for the same states

If you run Fin over phone, the state names change and one of the metrics carries a warning label. Intercom's Fin Voice documentation defines them as:

"Routed to team" is a voice-only label. If someone on your team is quoting it in a chat report, they've pulled it from the wrong dashboard.

Two things differ materially on voice. Assumed resolution doesn't wait 24 hours. A hangup after an answer resolves the call immediately, because there's no thread to come back to. And Intercom flags that the Abandoned metric on phone, calculated as deflection minus resolution, is currently inaccurate. Don't put it in a board deck.

What Intercom gets right here

Most AI agent vendors report a single "resolved" number and leave you to guess what's inside it. Intercom doesn't, and the model underneath is better than its dashboard suggests.

• Confirmed and assumed ship as separate metrics in the default Fin AI Agent report template, and as a filterable conversation attribute, so you can segment on the distinction today without building anything.
• Abandoned is kept separate from assumed. The line Intercom draws is whether Fin got an answer out before the customer went quiet, which is the right place to draw it, and it means you aren't charged for a customer who left mid-typing.
• Escalations are free. When Fin hands off because it couldn't help, you don't pay for the attempt, which is more than several per-resolution pricing models manage.
• 24 hours is a defensible window, long enough that someone who steps away from a chat and comes back after lunch doesn't get counted as satisfied.
• The reopen deduction gives up revenue on Fin's own worst outcomes. A vendor that bills per resolution and then refunds it when the customer comes back is doing something most don't. It covers less ground than it first appears to, which is the next section.

So the taxonomy is sound. The problems start with how it's summarised, and with the one case the refund doesn't cover.

Where it breaks, and what it's costing you

Three things go wrong: the dashboard hides the split, the refund follows the wrong thing, and the population you most need to inspect is the one that leaves no evidence.

The headline number is mostly silence

The Support Performance dashboard reports a single Fin Resolved bucket, and Intercom defines it as covering confirmed and assumed resolutions together. If you only ever look at that tile, you can't tell a customer who said "perfect, thanks" from a customer who read one paragraph and closed the tab.

So split it. The ratio you want is confirmed resolutions as a share of all resolutions. Take a workspace where Fin is involved in 10,000 conversations in a month, at a 52% resolution rate:

83% of that invoice rests on nobody saying anything. The 9% isn't invented: one Intercom customer running Fin in production reported a 12% confirmed resolution rate in the Intercom community forum, in a thread arguing that Fin assumes resolution too readily. Treat that as one team's self-reported number rather than a benchmark. Intercom doesn't publish a platform-wide figure.

Four ways the same conversation costs you twice

The refund rule looks generous until you trace where the money leaks. Each of these bills a resolution for work that a human still ends up doing:

Put numbers on the first row. On the 10,000-conversation month above, if 15% of those 4,300 assumed resolutions were wrong answers the customer abandoned and re-raised elsewhere, that's 645 threads. You paid $639 for answers that failed, and you still have 645 conversations to handle. Neither number appears anywhere in the Fin report.

Rows two and three come from the same community thread. That team's agents were replying during a service outage before customers asked for a human, and every message still landed as a billed outcome. An Intercom support engineer agreed that stepping in early should read as good judgment rather than something to be penalised, and passed the feedback on. No fix beyond turning Fin off during an incident.

Which is a usable rule on its own: if you're mid-incident and proactively messaging affected customers, pause Fin. Otherwise you're paying per apology.

Can you undo a resolution and get the $0.99 back?

Only the customer can, and only one way. There is exactly one documented reversal: the customer returns to that same conversation asking for more help, at which point the resolution is deducted and not charged, even across billing periods. It happens automatically. You don't file anything.

Nothing you do from the Inbox reverses it. Reopening the thread, self-assigning, replying, manually closing it again: none of that touches the charge. Intercom's rule for a teammate joining a conversation is that if the customer already got an answer from Fin and never asked for a person, it counts as resolved and you're charged, whoever ends up handling it. The billing decision keys off what the customer did, not what your team did.

There's also no manual dispute, no admin override, and no "mark as unresolved" flag anywhere in the Fin billing docs. So the only real lever is upstream: the outcomes that never bill in the first place.

• Fin escalates on its own default logic when a customer asks for a human or shows frustration.
• Fin escalates because of a workspace rule you set under Train → Escalation.
• Fin asks a clarifying question, the customer never answers, and the thread auto-closes on the inactivity timeout. That's an abandoned conversation, not a resolution.
• Fin only responds to a greeting, which doesn't count as an answer.
• A technical or logic error stops a Procedure finishing.

One thing worth building around: the deduction only fires on a return to the same thread. An unhappy customer who replies in the original conversation gets you the refund and hands you the quality signal. The same customer starting a fresh conversation gives you neither, and you pay twice. Making "reply to this thread" the easy path is ordinary good support practice that happens to line up with how Fin bills.

The conversations you need to read are the ones with no signal

An assumed resolution is defined by the customer producing nothing: no reply, no rating, no complaint. That's what makes the first two problems hard to fix by watching a dashboard. That same customer is the one least likely to answer a CSAT survey, so Surveyed CSAT can't reach them either. It only ever covers the fraction who respond. The population with the highest chance of a bad answer is the population that generates the least evidence.

Which leaves one artifact to inspect: the conversation itself. Somebody, or something, has to read what Fin said.

For the ratio, don't chase an absolute target. Intercom hasn't published one, and confirmed rates swing hard by channel and by how chatty your customers are. Track the trend on your own workspace and set the alarm on movement:

• Confirmed share drops 5+ points month over month while resolution rate holds flat. Fin is getting quieter, not better; go read the assumed threads.
• Assumed resolutions rising alongside repeat contact rate. Customers are giving up and starting over, and the new thread hides the failure.
• Assumed resolutions rising alongside reopen rate. At least you're getting refunded, but the customer waited 24 hours to be counted as satisfied first.

A five-minute audit of your resolution states

Run this once, then monthly. Everything in this section is native Intercom reporting: no extra tooling, no exports.

1. Build the split. Create a Fin AI Agent report and put confirmed resolution rate and assumed resolution rate on it as separate series. Not one blended resolution rate.
2. Calculate the confirmed share. Confirmed resolutions ÷ total resolutions. Write the number down. That's your baseline, and the trend is what matters, not the level.
3. Sample 20 assumed resolutions. Filter conversations on Fin AI Agent resolution state = assumed resolved and read the last Fin answer in each. Score them as answered / partly answered / wrong. Anything above 20% wrong means your confirmed share is flattering you. Segment the sample by conversation topic if one subject area is doing the damage.
4. Cross-check against repeat contacts. For that same sample, look for a new conversation from the same customer within 7 days. Those are your unrefunded failures. The thread closed; the problem didn't.
5. Separate procedure handoffs from escalations. Pull the outcomes breakdown and confirm how much of your "handed to a human" volume is billed at $0.99. If it's material, the Procedures that end in a handoff are worth a design review.

Step 3 is the one people skip, and it's the only one that reads what Fin actually said. A resolution state records what the customer did, not whether the answer was right. That's what a Fin QA rubric is for, and why resolution rate alone can't tell you if Fin is working.

When the sample turns up answers that were vague rather than wrong, the fix usually isn't in Fin's settings. It's in the article Fin was answering from, which is a case for structuring a help center Fin can use.

Finding the resolutions that weren't

Step 3 of that audit is the bottleneck. Reading 20 threads a month is fine; reading 4,300 is not, and sampling only finds the problems you happened to sample. The scale problem is why most teams look at the resolution tile and stop.

Supportman's Fin dashboard is built around that gap. It lists every conversation Fin took part in, and each row carries Intercom's resolution state next to the things Intercom keeps in separate reports:

• Resolution, straight from Intercom: Confirmed resolution, Assumed resolution, Routed to team, or Abandoned. It's Intercom's verdict, displayed, and we say so in the column itself.
• CSAT where the customer rated, and a predicted score where they didn't, so an assumed resolution still shows something in the column.
• An AI evaluation score on the closed thread. This is the part that matters for assumed resolutions: the score comes from reading the exchange, not from waiting for a rating, so a conversation that ended in silence still gets graded.

Above the list, the page compares conversations Fin touched against conversations it never touched: bad-rating rate day by day, average IQS, time to close, and where the rubric splits across brand voice and tone, technical knowledge, problem resolution, and communication efficiency. If Fin's resolution rate holds steady while its bad-rating rate climbs against your human baseline, the resolutions are getting worse and the rate can't show it.

The limits are worth stating. The dashboard doesn't recompute Intercom's resolution rate, and it doesn't yet detect reopens or repeat contacts for you. Counting which resolutions came back is what the Fin audit does, where we read a slice of your conversations and send back the scored report. The Fin Audit Dashboard is where the flags for this live next, including the one that matters most here: closed without answering.

The related definitions sit in the glossary: resolution rate, deflection rate, and containment rate get quoted interchangeably and count different things, and IQS covers the rubric score above. The rest of what we publish on running Fin is indexed in the Fin library.

Sources and references

Every definition above comes from Intercom or Fin primary documentation, checked on 18 September 2026.

• Fin AI Agent reporting: the Fin AI Agent resolution state attribute and its four values; the metric list in the Fin AI Agent report template.
• Fin pricing: Outcomes: the 24-hour assumed resolution window, the one-outcome-per-conversation rule, and the deduction when a customer returns to a resolved conversation.
• Fin pricing: Outcomes (current version): the outcomes that are never billed, including default and rule-based escalations, unanswered clarifying questions, greeting-only replies, and failed Procedures.
• Fin AI Agent resolutions: the teammate FAQ: a conversation counts as resolved and is charged when the customer already had an answer and never asked for a person, whoever handles it afterwards.
• Fin AI Agent outcomes: billable and non-billable outcomes, and the $0.99 / $9.99 prices.
• Monitor Fin's performance with clarity and confidence: the Support Performance dashboard labels, including Fin Resolved covering confirmed and assumed, Fin Constrained, and Fin Not Active; involvement, resolution, and automation rate definitions.
• Deploy Fin Voice: the voice-channel state names and the note that the phone Abandoned metric is currently inaccurate.
• Fin's flawed assumed resolved & pricing design, Intercom Community: one customer's self-reported 12% confirmed resolution rate and the outage scenario, with Intercom's response. A single customer account, not a benchmark.

Frequently asked questions