I have spent years as a TAM and CSM watching accounts fall through in ways that made no sense on paper. Health scores were green, the last QBR had gone well, usage looked stable, and then the renewal did not come. Or the account drifted into maintenance mode and quietly disappeared. Or something in an executive conversation shifted just a few degrees, a change in tone or word choice, that should have meant something but nobody caught it in time. Those were not talent failures. The information existed, the people were capable, and the work was being done. What was missing was the layer that turns information into consistent decisions, and that is what I want to talk about: not playbooks, not platforms, not AI, but the thing that sits underneath all of it.
What Most CS Leaders Think an Operating Model Is
Ask a CS leader to describe their operating model and most will give you one of a few answers. The customer journey, usually: onboarding, adoption, value realization, renewal, expansion. Or the lifecycle playbooks, the QBR cadences and success plan templates and health score rules and escalation processes. Or the coverage model across enterprise, mid-market, SMB, and digital. Or the tech stack. All of that matters and none of it is an operating model.
The distinction worth making is this: if your operating model starts with the customer journey, you are describing where work happens, not how the organization actually operates. A true operating model answers a different question, one that most CS organizations have never explicitly addressed: how does information move through this organization to consistently produce decisions and actions? It defines what signals matter, how they get detected, how they are combined into something meaningful, who makes which calls, what actions follow, and how the whole system learns over time. Most CS organizations have a journey and a playbook and a segmentation model and a tech stack. Very few have any clear description of how work flows from customer signal to organizational decision, and that gap is where accounts are lost.
What It Feels Like From the Inside
What makes this hard to diagnose is that it does not feel like dysfunction. Most CS teams operating without this layer are genuinely busy, people are working hard, and the problem hides behind the effort.
The signs are recognizable once you know what to look for, but easy to miss in isolation. Every Monday someone spends part of their morning rebuilding the story of an account before they can figure out what to do with it. Leadership asks for updates that technically already exist somewhere, but nobody fully trusts that the whole picture is in there. Two experienced people look at the same customer and walk away with different reads because they weighted different signals. New hires do not become effective when they finish onboarding; they become effective when they figure out who to ask. The team's strongest performers seem to operate on instinct, because the context that drives their decisions lives in their heads rather than anywhere the organization can access.
None of those things feel like an operating model problem in isolation. They feel like communication gaps, reporting issues, onboarding oversights. Together they point to the same thing: the organization has no shared way of converting information into decisions.
That is exhausting for the people doing the work and invisible to the customer, right up until the moment it is not. When an experienced person leaves, or a champion changes, or a renewal goes sideways, the team realizes the knowledge was never in the system. It was in specific people.
The Layer Most Organizations Skip
Of everything a CS operating model requires, the piece most consistently missing is aggregation into context, and this is not a signal problem. CS teams have plenty of signals: declining usage, a health score trending down, an executive sponsor who recently changed, three open support escalations, a success milestone that nobody has touched in two months. The signals are there. So are the people who could act on them. What is missing is anything that reliably combines those individual facts into a coherent picture of what is actually happening on an account.
Without that layer, the CSM becomes the aggregation engine, spending significant time every week pulling from CRM, support tickets, meeting notes, Slack threads, product data, and email history to answer a question that should already have an answer built into the system: should I be concerned about this customer? The cost compounds over time. Experienced people become indispensable not because they are doing unique work but because the context lives in their heads, and new hires take months to get effective because they are reconstructing history rather than acting on it. Leaders get inconsistent updates because everyone is interpreting the same facts through a different lens. Companies rarely have an information problem. They have a context problem: events get stored exceptionally well, but the understanding that connects those events into a decision does not.
Why Technology Alone Does Not Fix It
When CS leaders recognize this, the instinct is usually to buy a solution: a better platform, a new AI tool, a smarter dashboard. The problem is that aggregation cannot be purchased. It has to be designed. A CS platform can ingest data from multiple systems, but it cannot tell you how your organization should weigh a declining health score against an executive change against three open escalations. Those are not technology decisions. They are operating model decisions, and if they have not been made, no platform can make them for you.
What ends up happening is that AI becomes a very capable summarizer of disconnected information. It produces faster account briefs and cleaner notes and more polished views of data that was always there, but it does not improve the quality of decisions because the logic behind those decisions was never made explicit. A useful way to think about it: data tells you what happened, aggregation explains what it means, decisions determine what to do next, and technology accelerates the process. If the middle two layers are absent, technology makes the first layer faster and nothing else changes.
If that model is implicit, inconsistent, or living in the heads of a handful of experienced people, AI will scale those same inconsistencies with impressive efficiency.
Where to Actually Start
If I were advising a CS leader who wanted to build this, the first thing I would tell them is not to start with technology or process design or AI implementation. Start by answering one question: how do we want decisions to get made? Most organizations have never explicitly answered that. They have documented the journey, built the playbooks, and invested in the tooling, but they have never defined how information should become action.
The place to start is with the decisions that actually matter, not the workflows built around them. What does it mean that a customer is at risk? When does that conclusion trigger an escalation? What signals point to expansion potential? When does executive engagement become necessary? Once those decisions are identified, you work backward: what evidence informs each one, which signals matter and how should they be weighted together, who owns the call, what action follows consistently, which decisions can AI support and which genuinely require human judgment. None of that starts with a dashboard. It starts with getting honest about how judgment actually works inside the organization and making it explicit enough to be shared.
If You Already Have a Platform and Strong Playbooks
A capable CS leader who has invested in Gainsight and built a solid playbook library might read this and reasonably say they already have it covered. My response is simple: I am not questioning whether your team is effective. I am asking whether the effectiveness is systematic or individual. A playbook tells people what to do. A platform gives them a place to work. An operating model defines how the organization thinks, and having the first two does not guarantee the third.
The test I keep coming back to is this: if two experienced people on your team looked at the same account today, would they reach the same conclusion for the same reasons? If the honest answer is probably not, the operating logic is still living inside individuals rather than the organization. That gap has always existed, and for a long time it was simply the cost of doing business in a field that required nuanced human judgment. AI changes the equation in a meaningful way. For the first time, organizations have the ability to preserve not just what happened but how experienced people think about what it means. The logic behind good decisions can be made explicit, built into the system, and continuously improved, and that is a fundamentally different capability than anything CS has had access to before.
The Most Common Mistake When Building One
Most operating model initiatives begin with questions that feel operational and productive: what is the QBR cadence, how often should success plans be updated, what should the health score include, what can be automated. Those are real questions with real value, but they are downstream of the thing that actually matters. If you do not start by defining the decisions the organization needs to make consistently, every process becomes its own justification. QBRs happen because the playbook says so, not because a specific customer has reached a moment where a strategic conversation will actually change something. Health scores get monitored without anyone being able to explain what decision a score of 72 should trigger that a score of 78 would not. Work gets done, but decisions do not necessarily get better.
The second mistake is thinking you can design the operating model in a conference room. The best ones are not invented; they are discovered. Look at your strongest practitioners, not at what they do but at how they think. What signals do they notice that others miss? When do they escalate and when do they wait? What patterns have they built through years of experience that they have never been asked to articulate? In most CS organizations, an operating model already exists, distributed across a handful of people rather than built into the system. The real work is not creating something from scratch. It is making the reasoning that already exists explicit, teachable, and scalable across the whole team. For years, we got good at capturing what happened. Now there is a real opportunity to capture how experts think, and the goal is not better documentation. It is better organizational judgment.
The Shift That Is Coming
The direction Customer Success is moving is right: more commercial accountability, more strategic positioning, more ownership over revenue outcomes. But the conversations about where CS should go have outpaced the conversations about how to get there. A title change does not build an operating model and neither does a new platform. The organizations that actually make this transition work will be the ones that stop designing systems around activity and start designing them around decisions.
That infrastructure is what this industry is only beginning to build.