Analyzing Intercom conversations: the feedback channel nobody reads in aggregate

Support conversations carry churn signals weeks before anything else — and almost nobody analyzes them as a whole. Why agent tagging fails, what to extract instead, and how to do it at any scale.

Your support inbox is the highest-quality feedback channel you own. It is specific, it is timestamped, it is attached to a real account with a real invoice, and people write in it at the exact moment the product failed them. It is also, in most companies, the channel nobody ever analyses as a whole.

The reason is structural rather than lazy: support is measured on resolution. A ticket answered in nine minutes and closed with a thank-you is a total success by every metric the team is judged on — and it can simultaneously be evidence of a product defect that fifty other customers hit silently. Support closes the conversation. Nobody counts it.

Why agent tagging doesn’t solve this

The standard answer is “tag conversations and report on the tags.” It reliably decays, for reasons worth naming precisely — because they’re the same reasons that make any manual taxonomy fail, only accelerated by time pressure:

Tags are built for routing, not analysis. They answer “who handles this?” — so they describe your org chart, not your product.
They’re applied under time pressure. An agent with a queue picks the first plausible tag. Consistency across five agents and six months is a fiction.
They’re applied at the start. A conversation that opens as “login problem” and turns out to be a billing bug keeps the login tag forever.
The list grows and never merges. Eighteen months in, you have “billing,” “invoice,” “payments” and “Billing (new)” — four names for one theme, so the counts under-report every one of them.

You can hold this line with real discipline — a locked tag list, a monthly review, one owner. Most support teams cannot, and shouldn’t have to: their job is answering people, not maintaining a research instrument.

What to extract from a conversation

Support conversations differ from reviews and survey responses in one important way: they are dialogues, not statements. That changes what you pull out of them.

The customer’s opening message is the signal. It’s the unprompted description of the problem, in their words, before an agent reframed it. Analyse that; the rest of the thread is your team talking.
The request behind the question. “How do I export to CSV?” is a usability finding if it arrives forty times, and a feature request if the answer is “you can’t.” The distinction only appears in aggregate.
Emotion, separate from sentiment. Frustration, urgency and resignation predict churn far better than a negative/positive label. “This is the third time this week” is a different risk level from “minor annoyance.”
Repetition per account. One person opening five conversations about the same thing is a churn candidate, not five data points.

The threading detail matters more than it sounds: count conversations, not messages. A thirty-message back-and-forth is one problem experienced once, and treating each message as an item silently weights your entire analysis toward whichever issues happened to be hardest for your team to resolve.

The earliest churn signal you own

Here’s the operational reason this channel deserves the effort. Cancellation is a decision made weeks before it’s executed, and the evidence is almost always in the support history: three conversations in a month where there was previously one, a tone shift from curious to terse, a question about exporting data.

None of that is visible in a ticket-by-ticket view — each of those conversations was handled perfectly and closed. It’s only visible if you look at conversations per account, over time. That’s the analysis worth building, and it’s the one thing tag-counting can never give you.

Three ways to actually do it

Approach	How	Where it breaks
Manual sampling	Read 50 random conversations from last month, code opening messages against a fixed theme list	Doesn’t scale, doesn’t repeat, sampling hides small-but-rising themes
Export + AI chat	Export conversations to CSV, batch the opening messages into an AI chat, ask for themes	Taxonomy drifts per batch; no per-account view; and support text is dense with personal data — see the GDPR note below
Continuous pipeline	Sync conversations automatically; label and cluster every opening message; track per-account patterns over time	Costs a subscription; you stop owning the taxonomy problem

A warning specific to this channel for the middle option: support conversations are the most personal-data-dense feedback you have. Names, emails, order numbers, screenshots, occasionally passwords people shouldn’t have pasted. Bulk-exporting them into a general chatbot is the single riskiest version of the “paste it into AI” habit — worth understanding what GDPR actually requires before you do it, not after.

How Sentriment handles this channel

Our Intercom connector syncs conversations, analyses the customer’s own words, and keeps them in the same theme space as your reviews, in-app feedback and survey responses — so “checkout is broken” is one theme regardless of which channel each person reported it through. Personal data is redacted before anything is stored, the historical backfill draws on the first 1,000 imported items free on every plan, and each identified user accumulates an explainable health score, so the account opening its third frustrated conversation this month surfaces before it cancels.

The same applies to Zendesk, and the pattern generalises: the value isn’t in reading support tickets faster, it’s in seeing the shape of them at all.