When I was running the consumption program for a large cloud platform, I wasn't thinking about a "CS intelligence stack." I was trying to answer one question: which of our existing customers are quietly stalling, and which are ready for the next workload? We started with about fifty accounts over a million dollars in annual consumption and needed to grow both the number of them and what each one consumed.
So we built what we needed. I stitched together consumption telemetry to see who was actually growing and who had flatlined. We built what we called solution chains : the map of where a customer stalls and what the next workload is that moves them forward, drawn from the patterns of the customers who were already growing in the right direction. On the acquisition side, we ran a parallel program to identify the next set of very large accounts, built an art-of-possible point of view for each one, and ran a blocker-and-sponsorship framework that surfaced red flags early and pulled the right executive in at the right moment to clear them.
It worked. It was not elegant : a hodgepodge of telemetry, pattern templates, and manual research assembled program by program. But when the pieces talked to each other, the intelligence was clear. We could see which accounts were expanding, which were stuck and where, which plays moved them, and where to put scarce attention. Over that stretch we roughly doubled the installed base's consumption and grew from about fifty of those accounts to around two hundred.
I recently went back through the Customer Success Motion Diagnostic I published : the five lifecycle stages, the go/no-go filter, the five apps that emerge from it : and realized I needed to do the same thing I did for GTM before I started building: map what already exists.
This space has moved fast. What used to be a spreadsheet of renewal dates and a health score someone set by hand is now a full category of platforms, customer-facing experience tools, and agents built on top of them. Companies are imagining through AI and agents what we built manually inside a post-sale org years ago. It is genuinely interesting to watch.
So before I scope and build the first app, I went looking. Here's what I found.
What's been built, and where it concentrates
The CS stack in 2026 breaks into six layers. The easiest way to read it is to start with the platforms that own the category and work outward to the tools that feed and surround them.
Layer 1 · Core CS platforms
Where the category consolidated
Gainsight, Planhat, Vitally, ChurnZero, and the now-merged Totango/Catalyst anchor this layer. They own health scoring, playbooks, renewal tracking, and the team workflows a CS org runs on. Gainsight is the enterprise-depth incumbent; Planhat consolidates CRM-adjacent and services functions into one workspace; Vitally leans into flexibility and native customer collaboration. The category is also shifting from dashboards to embedded agents : automated summaries, churn prediction, meeting follow-ups.
This is the system of record for post-sale. It is mature and consolidating, and it does the job it was built for well. What it doesn't yet do is learn across its own accounts and change what everyone does because of it.
Layer 2 · AI-native entrants
Where the market is starting to reimagine the platform
Velaris represents the AI-first alternative : predictive insight with less setup and administrative overhead than the legacy platforms carry. This is the layer that most resembles the GTM stack's observation-and-recommendation tools : it surfaces signal and suggests action, but stops short of closing the loop. Early, pointed in the right direction, and worth watching.
Layer 3 · CRM-native CS
The CRM you already run, extended into CS
Salesforce Agentforce and HubSpot Service Hub push the CRM into CS territory : agents that monitor health signals, draft account summaries, and automate follow-ups. Strong for consolidation-minded orgs that want one platform, weaker than the specialist CSPs on health-scoring depth and playbook flexibility : the same pattern that plays out on the GTM side, where CRM-native tools trail the specialists.
Layer 4 · Customer-facing experience
The front office the customer actually touches
Distinct from the internal CSP back office, a second layer manages the experience the customer sees : onboarding hubs, collaborative workspaces, guided adoption. Rocketlane, GUIDEcx, Dock, Arrows, and Userflow live here. It's growing and still fragmented, and the emerging consensus is that a mature CS stack needs both layers working together, not the CSP alone.
Layer 5 · Signal and measurement inputs
The feeds the health score consumes
NPS and CSAT tools, product analytics like Pendo, and BI layers like Tableau and Looker each supply a slice of signal that no single tool sees in full. Structurally this is the same ingestion pattern as GTM : the health-scoring engine in Layer 1 is only as good as the inputs it can reach. Mature and largely commoditized on its own.
Layer 6 · Support automation
Adjacent, and often confused with CS
Fin, ASAPP, and Decagon target support-ticket resolution : chat, email, voice, in-app : rather than the CS-managed account. Decagon does knowledge-base-driven resolution for technical SaaS companies and belongs squarely here with Fin and ASAPP: it's the same job, done well, at ticket level. This is a fast-scaling category, but it is adjacent to account-level customer success, not the same thing. Resolving the ticket is not the same as growing the account.
One that doesn't fit the six: the Agent OS
Sierra deserves its own callout because it isn't a ticket-resolution tool. It positions itself as an "Agent OS" for building and deploying customer-experience agents across every channel : managed deployment, voice-first, aimed at high-volume consumer brands. That's a platform play, and the market prices it as one : Sierra's 2026 valuation sits around $15.8B against Decagon's $4.5B. Folding it into support automation would miss what it is. I'm flagging it as an emerging category adjacent to the six layers, not a seventh row in the same stack.
What's still missing, for now
When I ran the manual version of this system, the hardest part was never scoring health. It was propagating what worked. We'd find a solution chain that reliably moved a customer to the next workload, or a play that recovered a stalling account, and it would take the better part of a year to make it standard practice across the org : QBRs, enablement, manager coaching, tribal knowledge. By the time the insight became the default, the base had sometimes already moved.
The CS market today has strong observation : health scores : and growing recommendation : agents that draft summaries and flag risk. What it doesn't have is the system that closes the loop automatically. Not just "this account is at risk" but "here's what worked across every account like this one, and here's how the playbook is updating for everyone." And critically: separating outcomes from decision quality, because a good CSM decision on the signal available can still lose a renewal, and conflating the two is how an org stops trusting its own health scores.
Three specific things are still missing:
A CS leader managing a book of accounts needs to know which ones are actually healthy and which just look that way, where to spend scarce CSM attention this week, and where a renewal is quietly slipping. The current tools give per-account visibility. Nobody owns the portfolio intelligence layer that helps a leader run the whole base as a business.
How does a CS leader decide coverage models, segmentation, where to invest playbook and enablement effort? These calls are still made in spreadsheets and QBRs, informed by experience and gut. The signal to inform them better exists. The system that turns it into a decision doesn't.
Every renewal, every churn, every expansion contains information about what worked. Every stall is a signal about what went wrong. That information currently dies in a closed record or a health score nobody revisits. The system that reads those outcomes, finds the pattern, and updates what the whole org does next quarter : automatically, not through the next enablement cycle : hasn't been built yet.
Companies are moving toward this : the platforms are shipping agents, the AI-native entrants are getting closer to trajectory-based signal. The "for now" in the title is deliberate. I expect this space to move fast. But as of today, the loop is still open.
What I'm building, in what order
Five apps come out of the Customer Success Motion Diagnostic. Each maps to a lifecycle stage, passes the go/no-go filter, and has a data gate that must hold before the app produces reliable output. The sequence is not arbitrary : it's ordered by data-gate readiness, not ambition. Each app builds the foundation the next one needs.
Combine usage telemetry, support sentiment, billing, and engagement into one trajectory-based health score. Everything downstream reads from this, so it goes first. The gate is the hardest one in CS: multi-source signal has to be connected and trusted before any score means anything.
Detect renewal risk early : disengagement, flattening consumption, champion change, support escalation : across the whole base, not just the accounts a CSM is watching. It can't run until the health signal is live, so it comes second.
Triggered by the risk or expansion signal. Tells the CSM what to do specifically : re-engage a stakeholder, bring in a sponsor, land a named next workload. One system with the risk monitor, two outputs.
Detect expansion readiness from consumption trajectory and solution-chain position, surface comparable accounts, and generate an art-of-possible for the expanded footprint. The most signal-intensive of the five, which is why it waits until telemetry and CRM are connected and proven.
Assemble the QBR from realized outcomes, surface reference-ready accounts at the moment of value, and feed renewal and expansion outcomes back into playbooks and ICP. This is the app that starts to close the loop : it only works once the four before it are producing outcome data worth learning from.
Why I'm building here
The Customer Success Motion Diagnostic started as a way to document how I think about post-sale : the five stages, the go/no-go filter, the five apps that fall out of it. The natural next step was to build. But first I wanted to know what already exists and what's genuinely missing : not to avoid overlap, some overlap is fine if the approach is better, but to be honest about the problem I'm actually solving.
The research confirmed what I suspected from building this manually: the platform layer and the observation layer are well-served. The learning loop : the thing that turns one CSM's discovered solution chain into everyone's default motion : is not. That's where I'm building. Not because nobody else has thought of it, clearly they have, but because I've run the manual version and I know exactly which parts still happen in spreadsheets and QBRs.
This essay is the customer-success companion to the GTM Intelligence Stack. Same lens, same open loop, a different half of the customer's life. For now : here's the map. Here's what's been built. Here's where I think the gaps still are.