---
name: customer_success_playbook
description: Run customer success end to end: design onboarding journeys with milestone arcs, build weighted health scores, detect churn signals and run save motions, execute expansion plays, and escalate at-risk accounts through a tiered path. Triggers on "customer success", "onboarding journey", "health score", "churn signals", "retention playbook", "expansion playbook", "save motion", "QBR", "escalation", "account at risk".
---

# Customer Success Playbook

## Purpose

Turn a customer from "signed" into "renewing and expanding" on purpose, not by accident. Customer success is a set of repeatable motions: get the customer to first value fast, watch their health continuously, catch risk while there is still time to act, grow the accounts that are healthy, and escalate the ones that are not. This skill gives you each motion as a working playbook you can run against a real account book.

## Workflow

### 1. Segment the book

Before anything else, decide who gets what level of attention. Sort accounts by annual contract value:

- **Enterprise** (over $100K): dedicated CSM, quarterly business reviews, executive sponsor, white-glove onboarding. A workable load is about 1 CSM to 20 accounts.
- **Mid-market** ($25K-$100K): pooled or shared CSM, semi-annual reviews, trigger-based outreach. Roughly 1 to 50.
- **SMB** ($5K-$25K): tech-touch. Digital engagement, automated campaigns, in-app guidance. Roughly 1 to 200.
- **Self-serve** (under $5K): fully automated. Help center, community, email sequences.

Match the onboarding model to the same split: under $1K ACV goes self-serve, $1K to $25K goes tech-touch, above $25K goes high-touch. High-complexity products earn a higher touch level than the contract alone suggests. Everything below assumes you know which segment each account sits in.

### 2. Design the onboarding journey

Worked milestone arcs, stall detection, and metric definitions live in `references/onboarding-journeys.md`. The shape that matters:

1. **Day 0:** welcome and orientation. The customer knows what happens next and who owns it.
2. **Day 1-3:** first activation. The one binary event that proves they felt core value.
3. **Week 1:** first real outcome. Real work done in the product, not just configuration.
4. **Week 2-4:** habit formation. Repeat usage of the core workflow, team members joining.
5. **Day 30-60:** value proof and expansion conversation. The customer's own before/after numbers, recorded.
6. **Day 90:** formal handoff from onboarding to steady-state CS, with the success criteria and stakeholder map transferred, not just the login.

Track time-to-first-value as a median per segment. Cohorts that reach first value in 7 days retain far better than cohorts that take 30. Treat onboarding as a funnel with drop-off analysis at each milestone, and read support tickets as diagnostics: a week 1-2 spike means setup friction, clustering on one feature means a product or doc gap, and tickets going quiet by week 4 with no milestones hit means adoption is stalling, which is worse than a high ticket volume.

### 3. Build the health score

Worked models, the spreadsheet version, and refresh rules live in `references/health-scoring.md`. The structure:

1. Pick dimensions from product usage, engagement, relationship (champion strength, multi-threading), business/financial, and sentiment (NPS, CSAT, ticket tone). Usage usually carries the most weight, around 30-40%.
2. Normalize every signal to 0-100 so different scales do not distort the total.
3. Compute the weighted sum. Bands: **healthy** above 70, **at-risk** 40-70, **critical** below 40.
4. Pair every score with a trend. A healthy score that is declining deserves the same attention as a flat at-risk score.
5. Recalibrate the weights at least every 90 days against what actually churned.

Login frequency alone is a lagging indicator. By the time logins stop, the customer has already decided. Weight ticket sentiment, feature breadth, stakeholder engagement, and the power-user-to-seat ratio alongside it. Run the score with `bin/health_score.py` when you need a repeatable calculation from a JSON input.

### 4. Watch churn signals and run the save

The full signal table (signal, threshold, severity, response) lives in `references/churn-signals.md`. The highest-severity patterns: 50%+ login decline over 30 days, zero use of the core feature for 14+ days, data export initiated, seats removed, a support ticket spike that suddenly stops, and a lost champion. Watch for silence: no support interaction in 60 days plus declining logins plus missed reviews is a stronger churn signal than angry tickets. Angry customers are still asking you to fix it.

When an account crosses a threshold:

1. **Diagnose before you discount.** Deep engagement followed by a wall means a product or support problem; never-engaged means the account was never a fit, and the fix is sales qualification, not a save motion.
2. **Quantify the risk.** ARR at risk, days to renewal, churn probability, cost of the save versus cost of the churn.
3. **Run the intervention.** At-risk accounts get a bi-weekly check-in and a root-cause plan; critical accounts get the executive save packet within 24 hours.
4. **Start renewals at 90-120 days out.** A first renewal touch at 30 days is a reaction, not management.

Fix involuntary churn first. Billing failures are a bounded engineering problem with a direct revenue impact: smart retries and proactive payment notifications recover more revenue per effort than any save campaign.

### 5. Run expansion plays

Expansion signals and the propensity scoring model live in `references/expansion-plays.md`. The logic:

1. Track net revenue retention: (starting MRR + expansion - churn - contraction) / starting MRR. Below 100% means the existing base is shrinking; fix retention before pushing expansion.
2. Score expansion propensity per account: usage near plan limits, multi-team adoption, requests for higher-tier features, promoter NPS, QBR attendance. Above 70 on a 100-point scale, run the playbook now; below 40, focus on adoption first.
3. Pick the motion that fits the trigger: seat expansion when headcount grows, tier upgrade when usage passes ~85% of quota, module cross-sell when an adjacent workflow need appears, new-department land when another team shows interest, and a value-led uplift conversation at renewal for long-tenured flat accounts.
4. Treat expanded scope like a new customer: new use cases need their own activation within 45 days or they become contraction risk at the next renewal.

### 6. Escalate by tier

The urgency matrix, escalation protocol, and escalation memo template live in `references/escalation-paths.md`. The rules:

1. Classify urgency before acting. P0: churn threat on a large account, 2-hour acknowledgment signed or copied by an executive, executive sponsor looped immediately. P1: churn threat on a standard account, 4 hours, CSM manager looped. P2: at-risk signals with no explicit threat, 24 hours, standard CSM workflow. P3: general support, normal SLA routing.
2. Acknowledge, then quantify (ARR at risk, days to renewal, churn probability), then classify the root cause as process, technical, communication, or expectation mismatch. Only then propose a remedy.
3. Never promise credits, SLA extensions, or contract changes without authorization. Say what you can offer and what needs approval.
4. Every handoff names one owner, one deadline, and one escalation trigger. Ambiguous ownership is how escalations die quietly.
5. Close the loop in writing and document it in the CRM. If it is not written down, it did not happen.

## Output Contract

Deliver, in plain language:

1. **The segmentation**: every account in its segment, with the touch model and CSM load it gets.
2. **The onboarding journey**: the milestone arc with dates, the activation event, the metrics tracked, and the stall signals watched.
3. **The health model**: the dimensions, weights, bands, trend rule, and a scored book or a worked example run through `bin/health_score.py`.
4. **The signal watchlist**: which signals are monitored, with thresholds, severity, and the response each triggers.
5. **The expansion plan**: NRR baseline, propensity scores for the top accounts, and the motions queued.
6. **The escalation matrix**: urgency tiers, SLAs, routing, and the escalation memo format for the first real use.

## Operating Rules

- A health score without a trend is decoration. Always pair the number with its direction.
- Silence is a signal, not satisfaction. Watch for accounts that go quiet.
- Diagnose the churn cause before running a save motion. A save campaign cannot fix a fit problem.
- Renewal work starts at 90-120 days out. Thirty days is a reaction.
- Never promise commercial terms without authorization, even mid-escalation.
- Expansion goes to healthy accounts first. Growing an at-risk account deepens the exposure.
- Every handoff names one owner, one deadline, one escalation trigger. No exceptions.
- Never invent benchmark numbers. Use the team's own trend as the target; published figures are directional context only.
- Recalibrate health weights at least quarterly against real churned and retained accounts.

## Supporting files

- `references/onboarding-journeys.md`: milestone arc, touch models, onboarding metrics, stall and ticket-pattern diagnostics.
- `references/health-scoring.md`: weighted model build, normalization, the early-stage spreadsheet model, stage-appropriate scoring, refresh rules.
- `references/churn-signals.md`: signal table with thresholds and severity, save motions, silence rule, renewal cadence, involuntary churn.
- `references/expansion-plays.md`: NRR formula and benchmarks, expansion propensity scoring, the five expansion motions, QBR structure.
- `references/escalation-paths.md`: urgency tiers and SLAs, the escalation protocol, churn risk quantification, escalation memo template.
- `bin/health_score.py`: computes a weighted health score from a JSON input, with status bands and recommended actions.