Renewal conversations go badly in a very particular way. The customer says the rollout never really landed. Your team lists eleven months of activity — calls held, features enabled, tickets resolved. Both accounts are accurate, and neither addresses the other, because nobody wrote down at the start what "landed" would mean.
A customer success plan is the one-page document that prevents that conversation. Not a project plan, not a QBR deck, and emphatically not an internal account summary: a short, shared statement of what this customer is trying to achieve, how both sides will know whether it happened, and who owes what by when.
This guide covers what belongs in one, how it differs from a playbook, which accounts justify the effort, a seven-step method for writing it with the customer, a template you can copy, and the three habits that keep it from becoming another document nobody opens after week two.
Key Takeaways
- One page, or it will not be maintained. Length is the single best predictor of abandonment.
- Written with the customer, not about them. A plan they have never read is an internal note.
- Success criteria need a metric, a baseline, a target and a date. "Improve adoption" is an intention.
- Attach criteria to product data so progress updates itself rather than depending on someone's recollection.
- Decompose outcomes into in-product milestones — that is where the customer's team can act between calls.
- For the long tail, automate instead of shrinking. Deliver the same milestones in-product with no meeting attached.
What Is a Customer Success Plan?
Customer success plan: definition
A customer success plan is a short, shared document that states what a specific customer is trying to achieve with your product, how both sides will know whether it happened, and who is doing what by when. Its defining feature is measurable success criteria expressed in the customer's own business terms — not in yours, and not in activity counts.
The distinction that does the most work is outcome versus activity. "Reduce time to close month-end from nine days to five by the end of Q2" is an outcome; the customer's CFO can verify it and would notice if it happened. "Complete onboarding, enable the integration, run training" are activities — necessary, but nobody renews because activities occurred.
Success Plan, Playbook and QBR Deck
| Success plan | Playbook | QBR deck | |
|---|---|---|---|
| Belongs to | The account — and the customer sees it | Your team, internal | The meeting |
| Repeats across accounts? | No — one per account | Yes — that is the point | Format yes, content no |
| Answers | What does winning look like here? | What do we do when X happens? | What happened last quarter? |
| Lifespan | The whole relationship, revised | Until the process changes | Ninety minutes |
The common failure is a "success plan" that is actually a playbook with a customer's name at the top: a list of things your team will do, in your language, with no metric the customer would recognise. It reads well internally and is never referenced again by anyone outside the company.
The Seven Components
Why they bought, in their words, with a number attached. One sentence. Everything else supports it.
Where that number stands today. Without it, improvement is unprovable and every later claim is contestable.
Two or three, each with a metric, a target and a date. More than three and none of them gets attention.
-
4. Stakeholder map
The economic buyer, the champion, the day-to-day owner, and anyone who can block. Note who has never been in a room with you — that person is your biggest renewal risk. The dynamics are covered in the enterprise onboarding playbook.
-
5. Adoption milestones
The in-product behaviours that produce the outcome: teams onboarded, workflow configured, integration live, a weekly-active threshold reached. These are the things the customer's team can act on between calls.
-
6. Risks and dependencies, with an owner each
Including the ones on your side. A plan that lists only the customer's obligations is a contract, not a partnership, and it will be read as one.
-
7. Review cadence
When it is looked at, by whom, and inside which existing meeting. A plan that needs its own meeting will not be reviewed.
Which Accounts Get a Plan
Success plans cost about an hour to write and perhaps ten minutes a month to maintain. That is trivially worth it for a large account and completely unworkable across two thousand small ones. The segmentation that works:
| Segment | Mechanism | Who maintains it |
|---|---|---|
| Enterprise / strategic | Full jointly-authored plan, reviewed monthly. | Named CSM, with the customer. |
| Mid-market | One-page plan, reviewed quarterly, shared read-only. | CSM, lightly. |
| Complex rollouts of any size | Full plan — complexity, not revenue, is the trigger. | CSM plus the customer's project owner. |
| Long tail / self-serve | Same milestones delivered in-product as a checklist and progress view. | Nobody — it is automated. |
That last row matters more than it looks. The instinct for smaller accounts is a shorter document, which produces a thin plan nobody maintains. The better answer is a different mechanism entirely: the same milestones, expressed as an in-product onboarding checklist the customer can see and complete without a meeting — the self-serve equivalent of a success plan.
How to Build One: 7 Steps
- Mine the sales handover before you write anything
- Arrive at kickoff with a draft, not a blank page
- Convert each goal into a criterion with a number and a date
- Capture the baseline while it is still available
- Decompose each criterion into in-product milestones
- Name owners on both sides, including yours
- Attach the plan to a review moment that already exists
1. Mine the sales handover before you write anything
The reasons this customer bought were discussed at length during the sale and are usually recorded somewhere — a call summary, a business case, a proposal. Start there. A plan whose first draft reflects what the customer already told sales earns immediate credibility; a plan built from scratch at kickoff asks the customer to explain themselves twice, which is the first small disappointment of the relationship.
2. Arrive at kickoff with a draft, not a blank page
Bring something 70% right and ask them to correct it. Corrections carry far more information than answers to open questions, and they take a fraction of the time. This is also the moment when you discover that the outcome sales recorded is not quite what the operational team believes it is — which is exactly the kind of thing you want to find in week one rather than month nine.
3. Convert each goal into a criterion with a number and a date
"Roll out to the wider team" becomes "40 of 55 people in the operations team active weekly by 31 March". The test for any criterion: could two people independently look at the evidence in six months and agree on whether it happened? If not, rewrite it. Ambiguity here is not harmless — it resurfaces precisely at renewal, when it is least convenient.
4. Capture the baseline while it is still available
Ask what the number is today, and write it down. Customers rarely have it precisely, and a reasonable estimate agreed at kickoff is far better than a reconstruction attempted a year later by someone who has since changed jobs. This is the single most commonly skipped step, and its absence is why so many success stories cannot be quantified.
5. Decompose each criterion into in-product milestones
An outcome is a lagging measure; milestones are what the customer's team can actually do next week. Break each criterion into three or four concrete steps — integration connected, first workflow configured, second department invited — that can be observed in product data rather than reported in a call. Now progress is visible between meetings, to both sides.
6. Name owners on both sides, including yours
Every milestone and every risk gets one name. Include your own obligations explicitly — the configuration you owe them, the training session you will run, the answer you promised on data residency. A plan listing only the customer's homework will be read as a list of excuses being prepared in advance.
7. Attach the plan to a review moment that already exists
Open it in the first two minutes of every regular call. Not a separate "success plan review", which will be cancelled twice and then quietly stop. The plan should be the agenda, not an item on it.
The One-Page Template
Resist the urge to add sections. Every field you add is one more thing to be out of date in three months, and an out-of-date plan is actively worse than a short one — it teaches everyone that the document is not to be trusted.
Keeping the Plan Alive
✓ Do
- Keep it to one page and one version, shared with the customer.
- Tie criteria to numbers you can read from product data.
- Open it at the start of every regular call.
- Revise it openly when the customer's goals change.
- Show milestone progress in-product, between meetings.
✗ Don't
- Write it for internal reporting and call it shared.
- List activities where outcomes belong.
- Set more than three success criteria.
- Depend on someone's memory for progress.
- Leave your own obligations off the risk list.
The most reliable sign of a healthy plan is unglamorous: the customer references it before you do. If that has never happened, the document is yours rather than shared, and it will not survive the first change of champion — which, in most B2B relationships, is a matter of when rather than whether.
Measuring Whether Success Planning Works
Success planning is itself a programme, and it should be evaluated like one. Four numbers are enough:
- Coverage: share of eligible accounts with a current plan — "current" meaning updated within the review cadence, not merely existing.
- Criteria achievement: share of success criteria met by their stated date. The honest verdict on whether the plans are realistic.
- Milestone velocity: time from kickoff to each adoption milestone. Your early-warning system, and a direct read on time to value.
- Renewal and expansion differential: accounts with a maintained plan versus comparable accounts without one. The number that decides whether the programme continues.
Pair these with a customer health score rather than replacing one with the other: the health score tells you which accounts need attention; the success plan tells you what that attention should be about.
Bringing the Plan Into the Product
The gap that undermines most success plans is the four weeks between reviews, when the customer's team has milestones to complete and no visible reminder of what they are. The plan lives in a document they do not open; the work happens in a product that says nothing about it.
Closing that gap is straightforward. With Kompassify you can publish the adoption milestones as an in-product checklist for that account's users, ticking themselves off as the underlying actions happen, plus short walkthroughs for the steps people get stuck on and an in-app message when a milestone stalls — all segmented so each account sees only its own plan. Your monthly review then starts from evidence rather than recollection. Kompassify is GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.
Put the Success Plan Where the Work Happens
Kompassify turns your adoption milestones into an in-product checklist per account — updating itself as users complete the actions, so every review starts from evidence. GDPR compliant, EU-hosted, and free for under 100 monthly active users.
Start for Free →Frequently Asked Questions
What is a customer success plan?
A customer success plan is a short, shared document that states what a specific customer is trying to achieve with your product, how both sides will know whether it happened, and who is doing what by when. It is written jointly with the customer rather than about them, and its defining feature is that it names measurable success criteria in the customer's own terms — "cut invoice processing from six days to two by March" rather than "drive adoption". Everything else in the document exists to support that sentence.
What is the difference between a success plan and a playbook?
A playbook is yours and repeats across accounts: the standard sequence of actions your team runs for onboarding, for a health-score drop, for a renewal. A success plan belongs to one account and to the customer as much as to you: it captures their goals, their constraints, their stakeholders and their definition of success. Playbooks tell your team what to do; success plans tell both sides what winning looks like here. Confusing the two produces documents full of your activities and none of the customer's outcomes.
What should a customer success plan include?
Seven things: the business outcome the customer bought this to achieve, in their words and with a number; the current baseline for that number, so improvement is provable; two or three measurable success criteria with dates; the stakeholder map including the economic buyer and anyone who can block; the adoption milestones inside the product that lead to the outcome; the risks and dependencies each side owns; and a review cadence with named owners. Anything beyond that is usually there for internal reporting rather than for the customer.
Which customers should get a success plan?
Any account where a human is involved in the relationship and the cost of failure is high enough to justify the hour it takes: enterprise and mid-market accounts, complex or multi-team rollouts, strategic logos, and any account showing early risk. For the long tail of smaller accounts, the answer is not a lighter document but a different mechanism — the same milestones delivered in-product as a checklist and progress view, with no meeting attached. A success plan nobody has time to maintain is worse than an automated path everyone can see.
When should you create a customer success plan?
Draft it from the sales handover before the kickoff call, then complete it with the customer during that call. Waiting until after onboarding is a mistake, because the goals discussed during the sale are still fresh and the customer's attention is at its peak in the first two weeks. Starting from a blank page in front of the customer is also a mistake — arrive with a draft containing what sales promised, and let the customer correct it. The correction is where the real information appears.
How do you keep a success plan from becoming a document nobody opens?
Three habits. Keep it to a single page, because length is what kills maintenance. Attach every success criterion to a number you can read from product data rather than from a conversation, so progress updates itself. And give it a fixed review moment in an existing meeting rather than a separate one — a plan reviewed at the start of every regular call survives; a plan that requires its own meeting does not. If the plan has not been opened in a month, it has stopped being a plan and become an artefact of the kickoff.
What does a good success criterion look like?
It has a metric, a baseline, a target and a date, and it is expressed in the customer's business terms rather than yours. "Reduce time to close month-end from nine days to five by the end of Q2" is a success criterion. "Increase adoption", "improve efficiency" and "roll out to the wider team" are intentions. The test is whether two people could independently look at the evidence in six months and agree on whether it happened — if not, it will be argued about at renewal, which is precisely when you least want ambiguity.
How do success plans connect to in-product adoption?
The plan names an outcome; adoption is the chain of behaviours that produce it. So every success criterion should decompose into specific in-product milestones — teams onboarded, the workflow configured, the integration live, a threshold of weekly active users — that can be tracked without asking anyone. Delivering those milestones inside the product as a visible checklist means the customer's team can make progress between calls, and it means your review meeting starts from data rather than from recollection.