Build a Success Plan customers actually use.

Almost all CSMs have a success plan template, and most of them, if not all, have customers who have not opened it after the kick-off call.

Ask any experienced Customer Success Manager (CSM) how many of their clients have actually looked at the success plan in the last thirty or sixty days, and the answer is most likely a number on the Cartesian plane closer to zero or an absolute zero.
A success plan is one of the most widely used tools in customer success management, and sadly, one of the most consistently ignored by the very customers it is meant to benefit in the long term.

This is more of a design problem than a lack of motivation from the customer. In practice, most CSMs develop the success plan based on the vendor’s processes and timelines, and not the customer’s goals. They feature, among other things, the start and end of the "onboarding journey that the vendor has planned," without focusing on the business outcome the customer cares about; for instance, the anticipated time to value from their perspective.

These documents, as usually developed, are vendor-led and written in the language of the customer drawing from the product's capabilities, instead of building from the customer’s process. As a result, the document sits in the shared folder, unopened, unread until the CSM needs to show proof of work to their manager.    

The purpose of a success plan

A success plan is intended to do one thing: co-create and define the tenets of success, making it visible to both parties and serving as a reference document that guides lifespan of the relationship. This is a live document. It should be flexible to accommodate iterations as circumstances demand.

This may sound obvious, yet most success plans fail at one word 'co-create'. They are simply documents made by the CSM and presented to the customer for review and perhaps sign-off. Success plans developed like this interpret the customer’s aspirations through the lens of the product’s capabilities but does not represent the customer’s goals and perceived milestones. Anything short of this is an internal document with the customer’s logo on it.

Five things good success plans have in common

Brevity
A success plan should be one page long (maximum two for complex enterprise accounts) without losing any of the essential components. If the customer will not be able to scan the document in under five minutes and understand or find all the relevant success factors, it requires rework by both parties. Any length beyond two pages cannot be easily referenced in a live meeting, as such, it qualifies as an internal artifact or a project document.

Outcome-focused
For a one-to-two-page document, it should be outcome-focused, not activity-ridden. For instance, an activity could be “onboarding training completed at x-date.” And a sample outcome could be captured as "reducing invoicing delays by 30% at y-date."

The reason success plans are full of activities is that they are easy to track. Outcomes, on the other hand need meticulous attention and effort to arrive at. If not properly developed, a customer may complete the entire activity list on a success plan and not have a single outcome to show for it. Activities flow easily from success plans thoughtfully developed and outcome-focused.  

Use business language
Do not confuse product adoption with customer value. “Attain 60% feature adoption on core modules” sounds great but it is just an internal metric unless it can be explained and the benefit linked directly to the customer’s business. A more relevant business language framing would be “Enable sales managers to generate their pipeline reports without reliance on the Business Intelligence unit to reduce reporting delays, and free 'the analysts' capacity to focus on other deliverables.”
This is more meaningful as it points to operational efficiency and communicates the goals in a language the customer will use with their internal teams to describe speed, cost control, revenue, and risks.

If you cannot make the translation from internal metric to the business language understood by the VP who authorizes renewal, the success plan will benefit from some more work and reframing.   

Periodic updates
Businesses change and service offerings evolve; hence, success plan should be flexible to changing needs. The plan might have been accurate in January, but less relevant by May. It needs to be reviewed periodically to ensure it stays in sync with innovations and feature release adjustments. The plan must have a review cadence that allows both parties to question if it is still serving the intended purpose.

Easy access
The success plan, a co-created document, should have a home where both parties can easily access it without requiring permission. If the customer needs to ask for it at any point for their internal use, then this is a vendor internal document that happens to have expected customer goals listed. A good place to save it can be Google Doc or Notion page where each partner can independently access it.

Recommendation: a one-page success plan format

Stripped of the clutter to its minimum viable structure, every word on a success plan should earn its place.

The goal
This part carries the most weight. It should not be more than three sentences, clearly articulating the success criteria by end of the contract. A critical question that can guide thinking and development is “What does success look like by the end of the contract?”
The honest answer from both parties, bearing in mind the capabilities of the product shapes everything that follows.

The measures
To know the goal has been achieved, there should ways to measure the same. Without a commonly understood and agreed upon standard, determining which goals have been achieved will be nearly impossible. In the best-case scenario, the measures should be adapted to the metrics already tracked by the customer since what they deem success is what matters the most. Ideally, the metrics should not be more than four.  

The milestones
By when and what needs to happen for the goal to be achieved? Do not overstate the milestones. Keep it simple and succinct to five, not more. This ensures only key checkpoints are stated without flooding the plan.

The dependencies
If the success plan was co-created by both parties, then there will certainly be dependencies. Each partner owes some responsibility to the other to ensure goals are clearly defined, metrics are accurately tracked, milestones are determined, responsibilities are proportionally shared. There is no true ownership if the customer has no obligation toward achieving success.

The review date
Set the date when the plan will be reviewed again to ensure alignment with business goals. Make this flexible to allow an earlier review if things change faster than anticipated. This is what differentiates a living document from a vendor artifact.

Build the success plan from a conversation

The entire architecture of success plan is built on a conversation premised on three questions:

-       What does success look like by using this product?

-       What should happen for success to be achieved?

-       What would be a potential impediment to reaching the goal?

There is always the temptation to lead with some success criteria from the vendor’s library or template. Do not do this. Allow the customer to answer the question in their own words. This gives you an understanding of what they think of the product and its capabilities.

The success plan should not be written by the CSM for presentation to the customer before the kick-off call. The point of the conversation and the questions is to gauge from the customer, a quick answer to the question “If after twelve months you are describing this product adoption as a success, what would you say?” Everything that follows from this is formatting suits the customer's language and framing.