Customer Success Playbook Builder's Guide
A step-by-step guide to building your first, or next, CS playbook covering onboarding, adoption, renewal, and expansion motions - with the sequence and decisions that actually matter.
What's inside
- Step 1: define your customer segments/tiers before writing anything
- Step 2: build the onboarding motion (milestones, owners, time-to-value target)
- Step 3: build the adoption motion (feature-depth targets, intervention triggers)
- Step 4: build the health-scoring model that feeds renewal and expansion
- Step 5: build the renewal motion (readiness scorecard, script cadence)
- Step 6: build the expansion motion (whitespace, scoring, ownership)
- Step 7: set governance - who owns the playbook, review cadence, versioning
- Rollout plan: pilot segment, feedback loop, full rollout
A CS playbook is not a slide deck - it's a set of decision rules and templates your team runs the same way every time, so outcomes stop depending on who happens to own the account. Build it in this sequence; each step depends on the one before it.
Step 1 - Define Segments/Tiers
Before writing a single motion, decide how many tiers of customer you actually manage differently. Most companies need 2-3:
- Tier 1 (highest ACV / strategic): 1:1 CSM, high-touch, custom success plans
- Tier 2 (mid ACV): pooled CSM, templated success plans, quarterly touchpoints
- Tier 3 (low ACV / long tail): tech-touch, automated email/in-app nudges, no dedicated CSM
Write the ACV or seat-count thresholds for each tier explicitly - vague tiering is the #1 reason playbooks fall apart at scale.
Step 2 - Onboarding Motion
Define, for each tier:
- The single "time-to-first-value" milestone (the specific action that proves the customer got value) and a target number of days to reach it
- Named onboarding steps in order, each with an owner (CSM, customer, or both) and a deadline relative to kickoff
- The handoff criteria from onboarding to steady-state (what has to be true before a CSM stops running weekly onboarding calls)
Step 3 - Adoption Motion
Define:
- The 3-5 core features/workflows that correlate most strongly with renewal in your own data (not assumed - pull it from your churn/renewal history)
- Adoption-depth targets per tier (e.g., "Tier 1 accounts should be on 3+ core features by day 90")
- Intervention triggers - the specific usage-drop threshold that automatically generates a task for the CSM to reach out (e.g., "login frequency down 30% over 2 weeks")
Step 4 - Health Scoring Model
Build a composite score from 3 input categories, each weighted:
- Usage signals (login frequency, feature depth, seat utilization) - typically 40-50% of the weight
- Engagement signals (meeting attendance, response time, survey/NPS response) - typically 25-35% of the weight
- Commercial/support signals (open escalations, payment issues, contract mismatches) - typically 20-30% of the weight
Set 3 bands (Green/Yellow/Red) with explicit score thresholds, and pipe this score directly into the Renewal Readiness Scorecard rather than running it as a separate, disconnected metric.
Step 5 - Renewal Motion
- Standardize the trigger point: readiness scorecard fires automatically at 45 days before every renewal date
- Standardize the script: use a fixed conversation script (see the Renewal Conversation Script Pack) rather than leaving phrasing to each AM
- Standardize escalation: define exactly what "Red" on the readiness scorecard triggers (manager involvement, exec sponsor outreach, weekly cadence)
Step 6 - Expansion Motion
- Require a whitespace map (see the Whitespace Mapping Worksheet) for every account above your Tier 2 threshold, refreshed quarterly
- Score and rank expansion opportunity across the book quarterly (see the Expansion Opportunity Scorecard)
- Assign explicit ownership: is expansion the CSM's job, a dedicated AE's job, or a shared motion? Ambiguity here is the most common reason expansion pipeline goes uncollected.
Step 7 - Governance
- Name a single playbook owner (usually a CS Ops or CS leadership role) responsible for versioning and updates
- Set a review cadence - quarterly at minimum - to update thresholds and scripts based on what's actually working
- Version every playbook document (v1, v2...) with a changelog so the team knows what changed and why
Rollout Plan
- Pilot on one segment (usually Tier 1, since the stakes and visibility justify the extra attention) for one full quarter
- Collect explicit feedback from the CSMs running it - what felt like busywork, what actually changed an outcome
- Revise thresholds and scripts based on pilot feedback before wider rollout
- Roll out to remaining tiers in a staged sequence, not all at once, so support capacity for questions doesn't get overwhelmed
- Set the first full governance review for 90 days after full rollout
How to use it
Work through the 7 steps in order over 2-4 weeks with your CS leadership team, pilot the resulting playbook on one customer tier for a full quarter, then use the rollout plan to expand it to the rest of the book.