Your Org Chart Is Destroying Customer Intelligence

Here is a message a customer might send to support:

We've had to export this into Excel every week because your reporting doesn't handle our regional structure. Our VP is getting frustrated and we're looking at Acme before renewal.

A good support agent catches more than the reporting question. They answer it, and they might tag the ticket as a feature request, mention the frustrated VP to the account's CSM, or note the competitor. Then the ticket closes. The rest of what the customer said now lives in a tag, a Slack message, or a note on a closed ticket, and it depends on the right person happening to see it.

The message reached only support, which filed it as a ticket. Here is how each of the other teams would read it, if it reached them:

Product sees a missing workflow: regional reporting.
Documentation sees a possible gap. Maybe the capability exists and the customer can't find it.
Customer success sees a renewal at risk, with an executive now paying attention.
Sales sees a competitor named inside an existing account.
Marketing sees the customer's own description of the job they're trying to do.
Leadership sees one instance of a pattern, if any report is counting it.

Filed by where it happened

A conversation is filed by where it happened, not by what it contains.

Tickets end up as support data, sales calls as sales data, QBRs as CS data, and research interviews as product data. Each team reads its channel for the questions it owns and files the conversation under its name.

The customer didn't organize what they said around your org chart. They wrote to support, and the message held information that product, CS, sales, and marketing could each use.

One common fix for scattered customer data is to bring the sources into one place. That helps, but support still reads a ticket as a support ticket, even when a sales call sits next to it in the same tool.

What gets lost

The conversations are still on file. They aren't read together, so a risk the customer raised in one of them can go unaddressed until the renewal.

The stated want doesn't get checked against the need. A customer may describe a feature as if it were the solution, because that's the closest thing they can name. If twelve customers ask for "CSV export," it's tempting to conclude that customers need CSV export. Read what came after those requests, and you may find that twelve customers need regional reporting, and CSV is the workaround they invented. In that case the request came up on sales calls, and the need for regional reporting showed up in support tickets and CS calls, which a different team reads.

One problem gets logged as twelve. The same gap shows up in twelve accounts, as twelve tickets, handled by different people, each one closed as resolved. The pattern only shows up if someone reads the twelve tickets together, and each one was read alone by whoever handled it.

A renewal risk gets filed as a reporting ticket. In the example above, the customer said their VP is frustrated and they're evaluating a competitor. That sentence sits in a closed ticket in the support tool. The CSM preparing for the renewal call reads the CRM and the call notes, and the ticket isn't in either.

Each team handled what it was asked to handle. Connecting the conversations across teams wasn't part of any of those jobs.

The truth is in the sequence

Reading conversations in the order they happened can change what each one means.

A customer says in a QBR that they're happy. Two weeks later, they ask support how to export all of their data. Someone who read both, in that order, would ask whether the customer is preparing to leave.

Support promises a fix next week. Three weeks later, there's no fix, and the customer asks again, a little shorter this time. Read together, the two tickets show a commitment that wasn't kept. If different people handled the two tickets, the second agent may not know a fix was promised.

Voice of the customer is what the customer said. We use "customer evidence" for what they said, what they did, what your team did or didn't do, and the order those events happened in.

Every team holds part of it

Sales teams that record discovery calls have the problem in the customer's own words, before anything was built or promised.

But the customer doesn't stop talking once the deal closes, and sales isn't the only team hearing things the rest of the company needs to know. Sales often captures the problem as it was understood before the deal closes. Support hears what it's like to live with the solution. CS watches the relationship and expectations change. Product hears what customers want changed. None of those views is the whole account.

A customer's statement can be wrong or incomplete, so treat it as evidence to weigh. Any conclusion drawn from it should point to the sentence it came from.

Reading the whole conversation

Four habits make this practical:

Read all of it. Read past the part that answers your team's question.
See what happened around it and after it. Check the ticket before it, the call after it, and any promise it refers to.
Read the sequence. Put the account's conversations in date order before drawing conclusions.
Show the evidence. Link each conclusion to the conversation and sentence it came from.

Teams can start on this without new software. Pick the last five accounts that churned or downgraded. For each one, pull every conversation from every team for the six months before, put them in date order, and read them as one story. Then ask what each team would have needed to see, and when.

The customer didn't organize their story around your org chart. Your systems did.

This is the work we built Resonant IQ to do. It reads the conversations in the tools your teams already use, reads them by account and over time, and ties each finding to the specific conversation and timestamp it came from. The aim is that the renewal risk inside a reporting ticket reaches the person who owns the renewal.

What this doesn't settle

Reading conversations together shows you where to look, but it doesn't prove why an account left. A pattern across teams is still an inference until someone checks it.

Conversations also capture only what people said. A customer who never writes in leaves nothing in the conversations to read.

Reading across teams also means more people can see what customers wrote. Decide who should have access to which conversations before widening it.

This post starts a series on what gets lost when customer conversations are read one team at a time. Related reading: the customer data fragmentation problem, why churn often starts in the sales call, and the churn signals hiding in support tickets.