This post is adapted from a CS Collective webinar with Jenna McLaughlin, Pendo's Sr. Director, GTM & Success, and Jay Nathan, Balboa's CEO.

Every Customer Success (CS) leader I talk to wants to run a proactive team. It's on every roadmap, in every board deck, in every hiring pitch. And when you sit with a Customer Success Manager (CSM) for a day, the work is still reactive: tickets, escalations, QBR prep, renewal panic. The intent has been universal for five years, but reality hasn't moved much.

That deserves a harder look, because the pressure around it is higher than it's ever been.

Customer churn costs U.S. businesses an estimated $168 billion a year, and that number has pulled retention out of the CS team's job description and into the CFO's strategy deck. 

New logos cost more to acquire than they used to. Boards are asking revenue leaders to show efficiency, not just growth. The math has shifted: you grow by protecting what you have and expanding the accounts you already serve. That's the mandate CS teams are operating under, and most of their tools weren’t built for this.

The CS platform model was built for a world that no longer exists

The dashboard-and-playbook model that powered CS for the last decade made sense when customer books were manageable, renewals were predictable, and teams had time to review accounts manually. 

In 2026, that world is gone. Books are bigger, NRR targets are tighter, and the volume of signals coming off a customer base (like product usage, support interactions, CRM activity, billing changes, stakeholder turnover) is something no team can read by hand anymore. Yet most teams are still trying.

The result is three structural problems that show up in almost every CS org we work with.

CSMs assemble a picture of an account by hopping between four or five tools, which means the picture is stale by the time it's complete. Data is fragmented across product, CRM, support, and billing, with no single system stitching it together fast enough to matter. And the health score they finally land on is built from rules someone wrote months ago, refreshed weekly at best. By the time it lights up red, the account disengaged weeks earlier.

The biggest cost of this is all the saves that never happened, the accounts where the warning signs were sitting in data the team owned, and no one had time to notice. Every CS leader has that list in their head: accounts they wish they'd looked at six weeks earlier. That's the real number behind NRR drag.

A static health score is an autopsy. It tells you what happened, based on rules someone wrote a year ago. It doesn't tell you what's about to happen.

Four things that won't fix this

Before talking about the shift, it's worth naming what won't get you there.

  1. Adding headcount. Headcount-driven CS breaks at today's cost structure. As books grow and customer expectations accelerate, hiring to be proactive doesn't pencil out.
  2. Optimizing existing cadences. A tighter QBR schedule or better health-score weighting doesn't offset rising cost-to-serve or prevent churn in AI-first customer journeys. Incremental improvements on a broken model don't compound.
  3. Tracking activity metrics. Touches, calls, and ticket close rates tell you if your team is busy. They don't tell you whether you're retaining revenue. Legacy metrics reward activity, not impact, and boards are no longer confusing the two.
  4. Bolting AI onto the existing stack. Treating AI as an add-on preserves the same workflows underneath. The output moves faster; the operating model stays the same. That's not the shift.

The shift is about the unit of work

The old model's unit of work is the account review: manual, weekly, comprehensive, and late. The CSM opens eighty dashboards Monday morning, assembles a picture, identifies who needs attention, and gets to work. By Wednesday, the picture is already outdated.

The new model's unit of work is the signal: a behavioral change in product usage or relationship health that predicts a future outcome, surfaced when it happens and routed to the person who can act on it. The CSM stops reviewing dashboards and starts responding to signals. The week reorganizes around that shift.

Proactive CS, done right, has three components. Continuous monitoring, so the system watches every account every day and CSMs don't have to. Contextual prioritization, so the question isn't "which accounts are at risk" but "which account do I call first today, and why." And action surfaced inside the workflows the team already uses, like CRM, Slack, or the inbox. 

Where AI actually fits

AI is well-suited to this problem for a specific reason: the work proactive CS requires is exactly what machine learning does well.

No human team can monitor every account continuously. A model can. No team can cross-correlate hundreds of signals across an entire book of business, catching the combinations that predict churn before they're obvious. ML does this in ways humans can't match on volume. And the next step after surfacing risk, explaining which drivers contributed to a score and what to do about it, is something AI can generate per account, per day, at scale.

This is the rare case where the operating model and the technology are matched. The question CS teams should be asking is whether their tools are built for this model or the old one.

Three questions worth taking back to your team

Before your next staff meeting, consider these.

  1. How does a CSM on your team find out an account is in trouble, and how many days of warning do they get?
  2. If you doubled every CSM's book tomorrow, which part of their week breaks first?
  3. If your team received a prioritized list of accounts every Monday morning instead of a dashboard, what would they do differently?

Those answers tell you where you actually are, and the gap between the answer and where you want to be is the work.

Watch the full webinar with Customer Success Collective.