Customer Success: Why Your CS Team Is Reading the Wrong Data
A SaaS company we worked with hadbuilt what their CRO described as a “modern customer success function.” DefinedCSM ownership of accounts, regular business reviews, health scores driven byusage data, renewal motions starting 90 days before contract end, and a cleanhandoff from sales at deal close. The function had grown headcountsubstantially over three years. Net revenue retention had moved modestly. Grossretention had been flat.
We looked at why the CS effort wasn’ttranslating into retention outcomes at the expected rate. The answer waslocated in a place the CS team wasn’t looking. Customers who eventually churnedhad been making contact center support requests at rising rates for monthsbefore the CSM noticed any health-score change. The product usage data showedengagement holding up — these customers were still logging in, still usingfeatures. The support data showed something different — increasing frequency offriction, repetition of unresolved issues, signs that the relationship wasdeteriorating in ways the usage signals couldn’t detect.
The CS function was operating on the dataCRMs and product analytics produce easily, and ignoring the data sitting in thesupport function that carried the strongest churn signals. The customers weretelling the company they had problems through every available channel. Thechannel CS was watching wasn’t the one customers were using.
Most modern customer success health scores combine some mix of theseinputs: product usage frequency, feature breadth, login activity, NPS or CSATscores, support ticket volume, billing status, executive engagement. These areuseful, but they share a common limitation — they capture activity, notexperience. A customer can be active and unhappy. A customer can be using theproduct and quietly preparing to leave.
Several categories of signal that strongly predict churn aresystematically absent or under-weighted in typical health scores.
Conversational sentiment. What customersactually say when they contact support reveals their current relationship withthe product more directly than usage data does. A customer who logs in dailyand tells your support team “I’m getting tired of fighting with this product”is in a different state than the usage data alone would suggest.
Issue repetition. A customer whocontacts support multiple times about related issues — even if each ticket istechnically resolved — is showing accumulated friction that pure ticket-volumemetrics miss. The same number of tickets resolved differently in theirconversational pattern produces wildly different churn outcomes.
Adjacent context. Mentions of internalpressure, organizational change, vendor evaluations, or competitorconsideration in routine support conversations are extremely high-valuesignals. They almost never appear in CRM, but they show up regularly in supportcall recordings and chat transcripts.
Tone of the relationship. The shift fromcollaborative (“can you help us figure out how to…”) to transactional (“I justneed you to fix…”) to adversarial (“we’ve been having this problem for months”)is one of the cleanest signals of relationship trajectory. It’s invisible to anydata source other than the conversation itself.
The structural reason CS doesn’t act on conversation data is that itlives in a different operational system, owned by a different team, withdifferent metrics and different access patterns.
Support tickets are owned by the support function, measured onresolution metrics, and analyzed by support managers. CSMs see ticket counts intheir account dashboards but rarely review the underlying conversations. Goingdeeper would mean listening to calls, reading chats, and translating that intoaccount-level insight — which is operationally expensive without conversation analytics infrastructure.
The result is that the support function has rich customer experiencedata flowing through it daily, none of which is being structured for retentionuse. The CS function has retention responsibility, none of the rich data, and athin substitute in usage analytics.
The fix isn’t reorganization. It’s data integration. Theconversation data needs to flow into the CS function in a structured form —sentiment trajectory, issue repetition, conversational warning signals,adjacent context — so the CS team can act on it without having to listen toevery call.
Organizations that connect these signals tend to make fouroperational changes.
Health scores incorporate conversation signals. Sentiment trajectory across recent support contacts, issuerepetition patterns, language signals of disengagement — all flow into thecomposite health metric alongside usage data. The score becomes more predictivebecause it incorporates the dimension previously invisible to it.
CS gets alerts on conversation triggers.Specific phrases or patterns in support calls — competitive mentions,frustration markers, escalation signals — produce CSM alerts in real time. Thisshortens the window between a warning signal appearing in support and CS beingable to act on it.
Joint customer reviews include conversation context. Periodic account reviews look at recent support conversations, notjust ticket counts. The picture of the customer’s actual experience becomesavailable to the CSM as they plan engagement.
Closed-loop measurement. Customers whereCS intervened based on conversation signals are tracked against outcomes. Thedata refines the trigger criteria and validates which signals are worth actingon.
The harder part of this transition usually isn’t the technology —it’s the cultural one. Customer success teams have historically consideredsupport a separate function with separate concerns. Listening to support callsfelt like operational overhead, not strategic intelligence.
The reframe that works is treating support conversations as the mosthonest form of voice-of-customer data the company will ever capture. Customersin support are not on their best behavior. They’re not curated by the CSM’saccount plan. They’re not phrasing things diplomatically for a quarterlybusiness review. They’re telling the truth about their experience because theyhave an immediate problem they need solved.
That data is too valuable to leave unused. The CS function thattakes it seriously catches churn signals six months earlier than the CSfunction that doesn’t, and the retention difference compounds quarterly untilthe gap becomes structural.
1. Pull last quarter’s churnedcustomer list. Check their support history. Howmany contacts in the 180 days before cancellation? What was the trajectory ofissues? Compare against retained customers in similar segments.
2. Calculate the integration gap. When a customer mentions a competitor in a support call, how longbefore CS knows? If the answer is “we don’t have a process for that,” you havean information delay that’s costing renewals.
3. Listen to 10 support calls fromyour top accounts. Even without analyticsinfrastructure, manual review of conversations from high-stakes accounts willsurface signals your health score is missing.
4. Add one conversation-derived signalto your health score. Even a basic one — recentsentiment direction, repeat contact rate — improves the score’s predictivevalue materially.
5. Build the CSM-to-support data flow. Doesn’t have to be sophisticated. A weekly summary of high-riskconversation signals delivered to each CSM is a starting point. Thefriction-removal often produces immediate retention improvement.
The customer success function is askingthe right question — which of our customers is in trouble — using the wrongdata. The usage metrics tell you what customers are doing. The supportconversations tell you what customers are feeling. Both matter, but only one ofthem changes weeks before retention is decided, and most CS teams aren’treading it. The churn signals were there. The CSMs just didn’t have a windowinto the room where customers were producing them.
The AI terminology chaos is real. Your "divide and conquer" framework is the clarity we needed.
Finally, a clear way to cut through the AI hype. It's not about the name, but the problem it solves.
