BrettFullmer: Merged into the 5-phase Playbook restructure — redirect to Risk

2026-09-01T18:07:33Z

Merged into the 5-phase Playbook restructure — redirect to Risk

← Older revision		Revision as of 18:07, 1 September 2026
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~~]]

BrettFullmer: Publish The Play Library page

2026-09-01T17:00:16Z

Publish The Play Library page

New page

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.

==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]]

The Play Library - Revision history

BrettFullmer: Merged into the 5-phase Playbook restructure — redirect to Risk

BrettFullmer: Publish The Play Library page