Playbook Index
Prism Customer Success Handbook — Section 3.0
What a playbook is
A structured response to a defined trigger, instantiated on an account with a fixed set of tasks. Playbooks exist so that the response to a known situation is consistent, complete, and visible — rather than depending on what the CSM happens to remember on a busy week.
They are not scripts to follow blindly. Every playbook below assumes the CSM applies judgment to the specific account; the playbook guarantees nothing important gets skipped.
The three types
| Type | Playbooks | Counts toward Risk Level? |
|---|---|---|
| Risk | Health Decline (3.1 Health Decline), Renewal Risk (3.2 Renewal Risk), Low Adoption (3.3 Low Adoption), Champion Departure (3.4 Champion Departure) | Yes |
| Lifecycle | New Customer Onboarding (3.6 New Customer Onboarding), Renewal Motion (3.7 Renewal Motion), Churn & Offboarding (3.8 Churn & Offboarding) | No |
| Opportunity | Expansion Opportunity (3.5 Expansion Opportunity) | No |
The type distinction is functional, not cosmetic. Only Risk-type playbooks count toward Risk Level and can put an account into the At-Risk state (1.6 Health Scoring Methodology).
- Lifecycle playbooks are work that's supposed to happen. An account in onboarding isn't at risk for being in onboarding.
- Opportunity is a positive signal. Counting an expansion conversation toward risk would invert the meaning of the entire risk model.
How playbooks fire
| Type | Trigger mechanism | Customer contact |
|---|---|---|
| Risk | Automatic, on threshold or condition — except Champion Departure, which is manual (see 3.4 Champion Departure) | CSM decides timing and content |
| Lifecycle | Automatic, on event — handoff received, renewal checkpoint reached, Will Not Renew set | CSM executes |
| Opportunity | Automatic, but requires CSM qualification before any customer contact | Gated |
Why Risk playbooks fire automatically: the point is catching what a human would miss across a large book. A risk process that depends on the CSM noticing first is not a system — it's the CSM's memory with extra steps.
Why Opportunity is gated: an auto-generated expansion approach to an account the CSM knows is quietly frustrated would be actively damaging. The trigger surfaces the candidate; the CSM decides whether it's real.
3.4 Champion Departure is the exception — it is never auto-generated. Prism has no way to detect that a person left; every available proxy (bounced email, unresponsive contact, decaying engagement score) is lagging and ambiguous, while a CSM hearing it on a call is immediate and certain. Automating it would produce a worse signal that fires late in the one situation where speed matters most. Full reasoning there.
Manual instantiation is always available. The CSM can start any playbook on any account. Automation is the floor, not the ceiling — a CSM who sees a problem the triggers don't cover starts the playbook anyway.
Stacking
Playbooks stack. They are not suppressed.
Multiple playbooks can be active on one account simultaneously, and this is deliberate: stacking is itself the Risk Level signal. Two active Risk playbooks means Compounding (1.6 Health Scoring Methodology) — a state the composite health score cannot express. Suppressing overlapping playbooks to keep the account list tidy would hide exactly the case the model exists to surface.
Apex Labs is the canonical example: Health Decline and Low Adoption active together, producing a Compounding Risk Level that neither playbook alone would show.
But dedupe strictly: the same playbook type cannot be active twice on one account. A second Low Adoption trigger on an account already running Low Adoption changes nothing and adds noise.
Cooldown
After a playbook completes, the same type cannot re-fire on that account for 30 days.
Without a cooldown, an account with chronically low adoption generates an endless treadmill: complete the playbook, the condition is still true, it fires again immediately. The CSM learns to ignore that playbook, and the signal dies.
The cooldown assumes the CSM's judgment: if the situation genuinely warrants re-running it sooner, manual instantiation is available. What the cooldown prevents is the system insisting on it.
Stale playbooks
An incomplete playbook stays open. It is flagged stale after 30 days without task completion, but it does not auto-close.
Auto-closing would hide the finding. Playbook abandonment is a real signal read at the quarterly system review (2.3 Operating Rhythm): playbooks that consistently go uncompleted mean either the playbook is wrong for the situation or capacity is genuinely short. Both matter, and silently clearing them destroys the evidence.
Escalation within a playbook
Any active playbook can be escalated by the CSM — an explicit judgment that this needs elevated attention (2.7 Escalation Management). Escalation:
- Forces Risk Level to Critical, overriding the computed tier
- Triggers the comms cadence obligations in 2.7 Escalation Management
- Notifies the Director of CS
Escalation is the CSM's judgment overriding the arithmetic. The model computes; the human decides.
The standard playbook page
Every playbook in this section follows the same structure:
| Section | Contents |
|---|---|
| Trigger | The exact condition that fires it — matching the code where automated |
| Objective | What resolution looks like, in one sentence |
| Owner | Who is accountable (usually CSM; may shift for technical response) |
| Entry criteria | What must be true for the playbook to be appropriate |
| Procedure | Step by step, with the reasoning behind each step |
| Templates | Embedded email and conversation templates (also collected in 4.1 Email Template Library) |
| Escalation path | When and to whom this escalates |
| Exit criteria | What must be true to close it — and what doesn't count as resolution |
Playbooks at a glance
| # | Playbook | Type | Fires on |
|---|---|---|---|
| 3.1 | Health Decline | Risk | Composite health drop over a defined window |
| 3.2 | Renewal Risk | Risk | Renewal approaching on an account with risk indicators |
| 3.3 | Low Adoption | Risk | Product Adoption below threshold |
| 3.4 | Champion Departure | Risk | Manual — CSM logs the departure |
| 3.5 | Expansion Opportunity | Opportunity | Healthy + strong plan progress / usage depth |
| 3.6 | New Customer Onboarding | Lifecycle | Sales handoff received |
| 3.7 | Renewal Motion | Lifecycle | Renewal checkpoint reached |
| 3.8 | Churn & Offboarding | Lifecycle | Will Not Renew set, or notice received |
Exact trigger thresholds are documented on each playbook page and must match lib/health/triggers.ts and lib/playbooks/templates.ts where the playbook is implemented.
Not yet built
Playbooks 3.6 New Customer Onboarding, 3.7 Renewal Motion, and 3.8 Churn & Offboarding do not exist in the CSP — the playbook engine currently implements the five Risk and Opportunity playbooks only. Cooldown, stale flagging, and Lifecycle-type playbooks are scoped in BUILD_BACKLOG.md for the v2 push.
Related pages
- 1.4 Customer Lifecycle — the states playbooks reference
- 1.6 Health Scoring Methodology — Risk Level, and how playbooks drive the At-Risk state
- 2.3 Operating Rhythm — where playbook review sits in the week and quarter
- 2.4 Account Prioritization Framework — how active playbooks rank against each other
- 2.7 Escalation Management — escalating a playbook
- 4.1 Email Template Library — templates collected from every playbook