Spend enough time working with CS teams and you start to notice a quiet friction between the CSMs on the front line and the CS ops function supporting them. It doesn't usually come out as conflict. It's more like a persistent gap between what ops builds and what CSMs actually use.
The ops team builds a dashboard. The CSMs look at it once during the meeting where it's introduced and then largely stop looking at it. The ops team builds a playbook. The CSMs file it somewhere and carry on doing what they were already doing. The ops team designs a renewal prep process. The CSMs find a way to satisfy the process without it changing how they prepare for the conversation.
This is frustrating for CS ops leaders who have done careful work on tools and frameworks that nobody seems to want. And it's a signal worth understanding.
Because in most cases, the CSMs aren't being lazy or resistant. They're telling you something. The question is whether the ops function is listening.
What the gap looks like up close
The most common version of this friction starts with data.
CS ops teams tend to be built by people who are good with data: who can model churn risk, build health scores, design dashboards, pull reports from the CRM. That's the skill set. It attracts people who find that kind of work interesting and meaningful.
CSMs tend to be built differently. The skill set is relational: reading a customer, knowing when to push and when to hold back, finding the right framing for a difficult conversation. Numbers matter to them, but as context for a relationship, not as the primary signal.
The mismatch is predictable. When ops builds a health score with eight inputs and a weighted algorithm, they're producing something they find meaningful. When they put it in front of the CSM and say "this is how we identify at-risk accounts," the CSM looks at it and thinks: "I already knew that account was at risk. I could tell from the last three calls." The score confirms what they knew or misses something they sensed. It doesn't help them have a better conversation.
This is not an argument against health scores. It's an argument for building them in conversation with the people who'll use them: finding out what information would actually change what a CSM does, not what information is available to measure.
The four things CSMs will tell you if you ask
There are things most CSMs would say to their CS ops counterparts, if someone asked directly and the answer could be given honestly.
"Tell me what to do, not just what's happening."
The most useful CS ops output is not a report. It's a prompt. Not "customer X has a health score of 62" but "customer X has dropped their weekly active user rate for three consecutive months and their renewal is in 90 days; here are the three things that have worked in similar situations." The insight has to connect to an action. If it doesn't, the CSM will process the information and do whatever they were going to do anyway.
"Give me something I can take into the customer conversation."
Data that lives inside the vendor's systems is useful for internal analysis. Data that can be shared with the customer (visualised clearly, framed around the customer's own success metrics, in a format they can send to their manager) is useful for the relationship. The best CS ops tools give CSMs something to show, not just something to know.
"Make the process feel like it's for the customer, not for the company."
CSMs are sensitive to this. When a process feels like it's designed to generate internal reporting data rather than to improve the customer experience, it creates a kind of low-level cognitive dissonance. The CSM fills in the fields because they have to, but they're not invested in the quality of the data. When the process feels genuinely useful (when the renewal prep template actually helps them prepare for the conversation, when the QBR framework produces a meeting the customer looks forward to rather than tolerates), they use it properly.
"Don't change things without asking us."
CS ops functions sometimes make changes to CRM fields, playbooks, and templates without consulting the CSMs who'll use them. From ops, this feels efficient: it's a technical change, it improves the system, it should be quick. From the CSM side, it feels like the tool changed under them without warning, and now they have to figure out a new workflow mid-account. The best CS ops teams have a change management reflex: they test changes with a small group of CSMs before rolling them out, they explain the reason for the change, and they create a feedback channel.
What CS ops actually needs from CSMs
This is a two-way relationship. The friction isn't all in one direction.
CSMs often treat CS ops as an administrative function: something that generates reports for the leadership team and tells them to fill in fields. They don't always see ops as a lever they can pull when they have a problem. "My renewal at-risk cohort is too big to manage manually. Can you help me build a prioritisation model?" is the kind of request that good CS ops teams love and that most CSMs have never thought to make.
The most productive CS ops work happens when the CSM is a genuine input into what gets built, not as a passive subject of observation ("here's how we're going to improve your efficiency") but as a collaborator ("here's a problem I'm stuck on, can you help me solve it?"). That requires CSMs to be clearer about what they actually need, and to believe that asking is worth their time.
It also requires CS ops leaders to make themselves accessible in ways that invite that kind of conversation, not just the formal feedback session in the QBR, but the Slack message that says "I built something that might help with the X problem you mentioned, want to try it?"
The structural fix
The teams that get this right tend to have a structural mechanism for it, not just a cultural norm.
A CS ops "office hours" slot where CSMs can bring process problems or data questions directly. Not a meeting for its own sake, but a standing offer that makes it easy to ask.
A CSM advisory group that reviews significant ops changes before they're rolled out: two or three CSMs who represent different segments and tenure levels, who are explicitly there to stress-test what ops is building against how the work actually feels.
A joint metric: something that measures the effectiveness of CS ops by asking whether CSMs are using the tools, not just whether the tools exist. Adoption of the renewal prep process. Quality of CRM data in high-value accounts. Time between a health score flag and a CSM action. These are the outputs that matter.
The underlying principle is simple: CS ops is a service function. The customer is the CSM. Building for them, not at them, changes the work.
The short version
CS ops builds things CSMs don't use, not because CSMs are difficult, but because the gap between what ops finds meaningful (data, models, systems) and what CSMs find meaningful (conversation-ready insight, customer-facing tools, process that feels like it serves the relationship) is real.
Closing that gap requires CS ops to ask CSMs different questions: not "here's what we built, does it work?" but "what would actually help you in the next thirty days?" And it requires CSMs to treat CS ops as a problem-solving partner, not a reporting function.
The structural version is: advisory groups, office hours, and adoption metrics. The cultural version is: mutual respect between two functions that are genuinely good at different things.
Where Pivotal Path comes in
CS ops that CSMs don't use is CS ops that isn't working. We help CS ops leaders build tools, processes, and feedback loops that close the gap between what's designed and what's actually useful on the front line.
Working on this in your business?
We help UK SMEs and scale-ups turn this kind of thinking into action.
Read next
Building CS Before You Have CS Ops: What to Do First
Why CSMs Burn Out, and What the CS Ops Infrastructure Has to Do With It
Scaled CS: what it actually means and when you need it
The CS Leader's First 90 Days: Why Fixing Things Too Fast Is the Fastest Way to Get Things Wrong
Customer Success Operations: The Next Evolution of Customer Success?
