Every CS methodology worth its salt endorses the mutual success plan. It's the document that aligns CS and the customer on what success looks like, maps milestones to a timeline, and creates shared accountability for outcomes. The logic is hard to argue with. The practice is harder than it looks.
I've seen a version of this pattern more times than I can count. A CS team introduces MSPs as part of a CS Ops initiative. Templates are built, a CRM field is added, the first few accounts get plans written up. Six months later, the template is being used for new customers during onboarding. Existing accounts haven't been retrofitted. The plans that do exist haven't been updated since they were created. And when I ask CSMs whether their customers actually reference the document, the answer (delivered with varying degrees of candour) is usually no.
The mutual success plan is a great idea that fails operationally in predictable ways. Understanding why is the first step toward building one that doesn't.
The mutual part is the hard part
The name is the tell. A plan that only CS wrote, only CS can access, and only CS references in internal reviews isn't mutual. It's a CS planning document with aspirational language. It documents what success looks like from CS's perspective, not what success the customer is actually trying to achieve.
Getting to genuine mutuality requires something most CS functions don't build time for: a structured conversation, early in the relationship, where CS asks the customer to articulate their success criteria and then writes those down in the customer's language. Not the features they want to use. Not the onboarding milestones. The business outcomes they're trying to change: the number they're hoping to move, the problem they're trying to stop having, the thing they'll point to in twelve months and say "that's why we bought this."
That conversation is harder to have than it looks. Customers aren't always sure what success looks like. The person in the room at kickoff is often not the person whose business outcome is at stake. And getting them to commit to metrics in writing (metrics they'll be held to) can create a resistance the CSM wasn't expecting.
The teams that do this well have a structured intake process: a set of questions asked consistently at kickoff, recorded in a shared document or CRM object the customer can see, reviewed at defined intervals. The plan isn't something CS hands to the customer. It's something CS builds with the customer, in a process the customer expects.
Three ways MSPs fail operationally
The plan gets made and never updated. A success plan that documents milestones at month one and is never opened again isn't a plan. It's a kickoff document. Customer priorities shift. Timelines move. The contact changes. If the MSP doesn't reflect the current state of the relationship, it's generating false confidence and hiding drift. CS Ops needs to build an update rhythm into the process, not assume CSMs will remember to update documents proactively.
The metrics are the wrong ones. The most common mistake in MSP design: using the metrics CS tracks rather than the metrics the customer uses to evaluate the relationship. A CSM might track login frequency and feature adoption. The customer's CFO is tracking cost-per-resolution or time-to-value. If the plan is full of CS-side metrics, it won't land in a customer review, and it won't be useful for making the renewal case, because the customer doesn't recognise the numbers as their own.
The plan is accessible to CS but not to the customer. A document that lives in Salesforce and is shared via PDF at QBRs is not a living plan. If the customer can't reference it independently, it's not meaningfully shared. The companies doing this well have found ways to put the plan somewhere the customer can actually access (a shared doc, a portal, a linked Notion page) and built a norm of reviewing it together at defined checkpoints.
What makes them work
Lighter is usually better. A two-page document with three customer-defined success criteria, a timeline of four or five milestones, and a monthly-updated status column does more work than a comprehensive ten-page template that nobody finishes. The goal is a document both sides actually use, not one that comprehensively documents the relationship for CS's internal purposes.
Connection to the renewal timeline matters. The MSP should explicitly link customer-defined success criteria to the renewal conversation, not as a commercial threat, but as a genuine checkpoint: "at renewal, we're going to review whether these three outcomes were achieved, and that's the basis on which we'd recommend continuing." That framing makes the plan consequential rather than theoretical.
And the CSM introduction of the MSP matters more than the template. If the CSM presents the plan as "here's a form I need you to fill in," it's going nowhere. If they present it as "I want to make sure we're working toward the things that actually matter to your team, and this is how we stay honest with each other about whether we're getting there," it lands differently.
CS Ops and the MSP infrastructure
A good MSP programme is a CS Ops problem from end to end. The template design, the intake process, the CRM fields, the update rhythm, the review triggers, the linkage to QBR structure and renewal prep: all of it needs to be designed, not improvised by individual CSMs.
The failure mode CS Ops is specifically solving for: MSP adoption that varies by CSM rather than being systematically implemented. In the absence of a process, some CSMs use the plan well, most don't use it consistently, and the insight about whether the programme is working gets obscured by individual variation.
Questions worth sitting with
- When did your CS team last review whether customers are actually referencing the success plans CS wrote?
- Are the success criteria in your MSPs defined by the customer, or by CS on the customer's behalf?
- If a customer's CFO asked to see their success plan tomorrow, could they find it without asking the CSM?
The short version. Mutual success plans fail in the same ways across different CS teams: one-sided authorship, metrics that don't match customer priorities, plans that never get updated, and documents the customer can't access. CS Ops makes the difference between an MSP programme that's a cultural norm and one that's a compliance exercise. The goal is a lightweight, genuinely shared document that both sides actually use, not a comprehensive template that lives in the CRM and generates false confidence about relationship health.
Working on this in your business?
We help UK SMEs and scale-ups turn this kind of thinking into action.
