|
|
| Line 1: |
Line 1: |
| Part of [[The Playbook]]. This is the part that gives the whole system its name. In infrastructure, a runbook is a standardized, written response to a known failure mode, so the fix doesn't depend on which engineer happens to be on call. Customer Success mostly still runs on tribal knowledge — the best CSM on the team knows exactly what to do when a champion goes quiet, and nobody else does. The Play Library is that knowledge, written down, so the response doesn't depend on who picks up the account.
| | #REDIRECT [[Risk]] |
| | |
| ==Play structure==
| |
| | |
| Every play in the library follows the same shape, so any CSM/TAM/CE can execute one cold:
| |
| | |
| * '''Trigger''' — the specific, observable signal that starts the play (not "the account feels off")
| |
| * '''Owner''' — the role responsible for running it (see [[CSM vs TAM vs Customer Engineer]])
| |
| * '''First 48 hours''' — the concrete first steps, in order
| |
| * '''Escalation path''' — who gets pulled in, and at what point it becomes an [[Incident Response for At-Risk Accounts|incident]]
| |
| * '''Success criteria''' — what "resolved" looks like, stated before you start, not decided afterward
| |
| * '''Close-out''' — how the play gets logged, and what feeds [[The Postmortem (Churn and Save Retros)|the postmortem]] if it didn't work
| |
| | |
| ==Starter plays worth having on day one==
| |
| | |
| * '''Usage Drop Play''' — triggered by a defined percentage decline in core-feature usage over a rolling window
| |
| * '''Champion Departure Play''' — triggered by a bounced email, a LinkedIn job-change signal, or a support contact from an unrecognized name
| |
| * '''Support Ticket Spike Play''' — triggered by ticket volume or severity crossing a threshold after a quiet baseline
| |
| * '''Post-Onboarding Adoption Lag Play''' — triggered by missing the [[SLOs for Customer Outcomes|time-to-first-value SLO]]
| |
| * '''Executive Sponsor Silence Play''' — triggered by a defined stretch with no exec-level engagement ahead of a renewal
| |
| * '''Renewal-at-Risk Play''' — triggered by a health score in the at-risk band inside a defined window before renewal date
| |
| * '''Expansion-Ready Play''' — the positive-signal counterpart: triggered by a thriving health score, run by the growth motion instead of the save motion
| |
| | |
| ==Why standardize instead of trusting judgment==
| |
| | |
| Judgment doesn't scale past the first few hires, and it doesn't survive attrition. A written play library means: consistent response quality across a growing team, faster time-to-action because nobody's improvising step one, and — critically — something concrete to improve. You can't get better at "trust your gut." You can absolutely get better at a play that's been run forty times and revised after each [[The Postmortem (Churn and Save Retros)|postmortem]].
| |
| | |
| ==Where automation fits==
| |
| | |
| Detection (the trigger firing) and drafting (a first-pass outreach email, a briefing summary) can be automated. Whether that draft goes out is a different question — see [[The Confirm Gate]].
| |
| | |
| [[Category:Customer Success Manager]]
| |
| [[Category:Customer Engineering]]
| |
