Good CSMs can't fix a broken architecture

Beyond The Click · Vol. 36 · June 25, 2026

Most customer success conversations about churn end up focused on the customer success manager. After all, nearly half of CSMs miss targets. “Were they proactive enough? Did they catch the signals in time? Did they run the right playbook?” But, for a CS leader who really wants to solve this problem, that approach is barking up the wrong tree.

Welcome to Beyond The Click by Balboa. Today we are taking a hard look at what in the world is wrong with CS architecture today, and how product analytics data can help fix it, including:

Your CRM was never built for this 🌡️
Data is siloed from the people who prevent churn 🔒
CSPs solved one problem but created another 🔀
What a better system looks like 🔮

Let’s dive in.

Your CRM was never built for this 🌡️

Salesforce and HubSpot are great at recording what happened to a deal. They were designed around bookings, opportunities, pipeline management, and sales compensation. But asking a CRM to power forward-looking customer success decisions is a bit like asking a thermometer to tell you the time. It can hold the data, but it cannot synthesize the data into what a customer needs next.

This matters because the CRM is still where most CS teams live. And every signal that doesn’t fit neatly into an account record ends up sitting somewhere else, which means it often ends up nowhere useful at all.

Illustration of a man with a hammer, for whom every problem looks like a nail

Data is siloed from the people who prevent churn 🔒

Product analytics, aka how customers actually use the product everyday, is the single most direct evidence of whether a customer is getting value. It carries more predictive weight than support tickets, NPS scores, or the last QBR. But for most CS orgs, it’s completely out of reach.

Historically, this data has lived with the product org, while customer success has had minimal access to it. The data most predictive of churn became the least available to the people responsible for preventing it.

The result is that CSMs end up connecting the dots on instinct. A glance at a health score here, a last-login date there, an open ticket count somewhere else. Some CSMs are amazing at this! But most are in an impossible position: they’re being asked to synthesize fragmented signals across dozens of accounts, manually, and without the tools to do it reliably.

CSPs solved one problem but created another 🔀

Customer success platforms like Gainsight, ChurnZero, and Planhat were built to fix this issue. They layered an analytical view on top of CRM data and gave CS teams a dedicated home for health scoring, playbooks, and renewal forecasting.

While this was a step forward, they created a new problem in the process: a second system of record. Two databases trying to maintain two versions of the truth through a fragile two-way sync, creating a permanent tax on data integrity. CS gained some autonomy but lost some coherence.

The deeper issue is what these tools ask humans to do with the output. Every platform gives you attributes one at a time and then expects a CSM to combine them into a judgment + action. That works reasonably well for a book of 20 accounts. It doesn’t work for a growing, multi-product business where customer journeys are complex.

What a better system looks like 🔮

The teams who really take this problem seriously have stopped asking CSMs to synthesize signals and started building systems that do it for them. In the best case, this looks like a single predictive model that ingests product usage, CRM history, support activity, and billing patterns, and produces one continuously updated score for each account, with the reasoning behind it.

Here, the model does the synthesis. The human does the judgment and the work.
This kind of architecture doesn’t require a data science team or a year-long build. Most companies already have the data; the question is whether it’s accessible and clean enough to put to work.

The first step for any CS org is a data readiness assessment. If your team is still synthesizing signals by hand, then the ceiling on your NRR is lower than it needs to be.