Every Intercom metric explained - and what Supportman does differently

Intercom surfaces dozens of support metrics across its dashboards - but many of them sound alike, some don't exist where you'd expect, and a few are locked behind plan upgrades. This guide walks through what each one actually measures, where the reporting gaps are, and how Supportman covers (or plans to cover) the blind spots.

First, a quick lay of the land

Intercom groups its metrics into a few categories: volume and workload (how much is coming in), speed (how fast you're responding), effectiveness (how well you're resolving things), quality and satisfaction (what customers actually thought), and AI and self-serve (what the bots are doing).

The metrics below live across those categories. Some are already in Supportman. A lot aren't - yet. Each section flags which is which.

Volume & workload metrics

New Conversations is the main demand number - how many inbound conversations landed in your inbox in a given period. Sounds obvious. Worth knowing: Intercom groups these by creation date, not the date you first replied. And outbound-only messages don't count.

Conversations Replied To is exactly what it sounds like - what did the team actually respond to? You'll find this in Intercom's Team inbox performance report. It reflects the team assigned at the time of the reply, so if a conversation got reassigned halfway through, the reply credit goes to whoever had it in their queue when they hit send.

Closed Conversations counts every close event - so if a conversation gets closed, then reopened, then closed again, that's two. If you want unique conversations closed for the first time, that's a separate metric called New Closed Conversations. Intercom created the second one specifically to separate it from the first.

What does "closed" actually mean? It's an action, not an outcome. A conversation being closed doesn't mean the problem is gone - it means someone clicked a button. First Contact Resolution (FCR), covered below, is the attempt to measure the actual outcome. Even that turns out to be complicated.

Reopened Conversations - conversations that came back after being closed. A signal that your first resolution didn't quite stick. Intercom tracks the count, but there's no built-in reopen rate. You have to calculate reopened ÷ resolved yourself, in a custom report or export.

For a product this mature, that's a notable gap - and one Supportman is evaluating as a potential differentiator.

Speed & responsiveness metrics

Most of the conversation about support performance centres on speed - how fast did you reply, how quickly did you close. Intercom has solid coverage of this category.

One caveat worth stating upfront: speed isn't always the right thing to optimise for. A fast reply isn't always a good reply. A quick close isn't always a resolved problem. The metrics below are useful - but they tell you how fast, not how well.

Median First Response Time (FRT) measures how long from a customer's first message to the first reply from a real person on your team - not a bot, not an automated message, an actual teammate. It's the first signal a customer gets that someone's there.

A few things worth reading carefully: bot replies don't count. And Intercom's FRT reports group conversations by their start date - so if someone wrote in on Monday and you replied on Wednesday, that 2-day response time shows up in Monday's data, even if you're only looking at Wednesday's report.

Intercom's reasoning is that FRT is a property of the conversation, not the reply - so it belongs to the date the conversation was born, not the date it was answered. The practical consequence: if you filter a report to a single day, you can end up seeing response times longer than that day itself, because slow replies from earlier conversations are bleeding in. It's a design choice that prioritises data consistency over intuitive date filtering.

Average First Response Time is the same idea but uses the mean instead of the median. The problem with the mean is that one conversation left open over a long weekend can throw the whole number off - a single outlier drags the average up significantly. Most support leads prefer the median for exactly this reason.

Median First Response Time From Assignment isolates how fast a teammate responds once a conversation is actually in their queue - separate from any time spent waiting to be routed. Useful for telling apart "we were slow to assign" from "the person we assigned to was slow to reply."

Median Response Time is the median time for any reply across the whole conversation, not just the first. It tells you whether your team's speed holds up mid-conversation, or whether they sprint to the first reply and then slow down.

Median Time to Close is the time from a conversation opening to it being resolved. One thing worth knowing: snoozing a conversation doesn't pause this clock. If you snooze something for three days waiting on a customer, those three days count.

SLA Attainment % - what percentage of conversations met your target response or resolution time. Supportman had a version of SLA tracking but pulled it for now - not because it doesn't matter, but because the goal is to ship something genuinely useful rather than something half-formed.

Effectiveness metrics

First Contact Resolution (FCR) - the percentage of conversations resolved on the first contact, with no follow-up needed. Intercom shows this in its Effectiveness report.

If "closed" can be undone, how do you define FCR? There's no universal answer. Some teams define it as: no customer contact within 7 days on the same issue. Some use agent judgement calls. Some use post-conversation surveys. The choice of window changes your FCR number significantly - and your FCR rate from last week can look different today than it did last week, as more time passes and some of those conversations come back.

Without a clearly defined window and methodology, FCR is hard to trust as a standalone KPI.

Replies to Close - average number of teammate replies before a conversation closes. The assumption baked into this metric is that fewer replies = better. That isn't always true - a complex issue resolved thoroughly in eight replies might be a better outcome than a deflection closed in one.

Reopen Rate - covered above, but it belongs here too: reopened ÷ resolved × 100. Genuinely missing from Intercom as a built-in number. On the radar for Supportman.

Quality & satisfaction metrics

Conversation Ratings (CSAT) is the 5-emoji rating customers can leave after a conversation - Amazing, Great, Okay, Bad, Terrible. The main customer satisfaction signal in Intercom, available on all paid plans.

CSAT % (positive) rolls that up into a single number: positive ratings ÷ total ratings. Intercom defines "positive" as Amazing + Great. Most teams report this single number upward rather than the full breakdown.

CSAT Response Rate - the percentage of closed conversations that actually received a rating. The industry average is somewhere between 10-25%.

That's a significant sampling problem. The people who bother to rate are not a random sample. They're the delighted ones and the furious ones. Everyone in the middle - the majority - stayed silent. A 90% CSAT from 8% of customers is a very different thing to a 90% CSAT from 40%.

CSAT isn't useless - but it should always be reported alongside the response rate, so anyone reading it understands what they're actually looking at.

CX Score is Intercom's answer to the response-rate problem - an AI-predicted satisfaction score for every conversation, no survey needed. No response bias, because there's no survey. It's a Pro add-on and not cheap.

IQS / AI Quality Scoring - separate from how the customer felt, this is an internal quality score: how well did the teammate actually handle the conversation, graded by AI against a rubric. Intercom has something called Custom Scorecards (and more recently Monitors) for this, as Pro add-ons.

Self-serve & AI metrics

Intercom has a growing set of metrics specifically for Fin, their AI agent - resolution rate, involvement rate, automation rate, and more. These track what the AI is doing, not what your human team is doing.

Supportman doesn't report those volume and rate metrics. But one thing it can do: run AI quality evaluations on Fin conversations specifically. If Fin is handling conversations, you can turn on IQS scoring for those too - so you're not just knowing how many conversations Fin resolved, but how well it handled them.

Summary

What Intercom gives you natively: quite a lot on speed and volume. Less than you'd expect on quality and resolution. Almost nothing on reopen rate or CSAT response rate context - two things you need to interpret the metrics you do have.

The biggest gaps: Reopen Rate genuinely missing, rolled-up CSAT % requiring manual calculation, and CSAT data reported without response rate context as standard.

Where Supportman fits: support data should be visible to the whole company, not just the people managing the inbox. That's why Supportman started in Slack - and the product roadmap is built around closing the gaps above.