BrettFullmer: New phase page: Risk (phase 3 of 5) - plays, confirm gate, incident response

2026-09-01T18:04:40Z

New phase page: Risk (phase 3 of 5) - plays, confirm gate, incident response

New page

Part of [[The Playbook]] — phase 3 of 5: [[Onboard]] → [[Adopt]] → '''Risk''' → [[Renew]] → [[Grow]].

==Detecting risk==

Risk starts as a signal from [[Adopt]]: a health score crossing into the at-risk or critical band, or a stalled [[Onboard|onboarding]] clock. The trigger is mechanical, not a judgment call — that's the point. Waiting for consensus that "this account is really in trouble" is exactly the delay a real system removes.

==The Play Library==

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.

Every play follows the same shape, so any CSM/TAM/CE can execute one cold:

* '''Trigger''' — the specific, observable signal that starts the play
* '''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 a declared incident
* '''Success criteria''' — what "resolved" looks like, stated before you start
* '''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 [[Onboard|time-to-first-value target]]
* '''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

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 and — critically — something concrete to improve.

==The Confirm Gate==

This is the discipline that comes straight out of building [[MAC]] and running the [[Spacelift]] practice labs, not out of a CS textbook. Plan and apply are structurally separate on those labs, and nothing touches production without a human confirming; the automation API key is scoped read-only by design. Apply the same boundary here:

'''Detect and draft — automated, no gate.''' An AI agent can watch usage data, flag a health-score threshold, pull account history into a briefing, and draft a first-pass outreach email or QBR deck. None of that touches the customer. Let it run wide open.

'''Send and commit — human, every time.''' Nothing customer-facing goes out — no email, no Slack message to a champion, no committed date, no pricing statement — without a human reading it and hitting send. A bad Terraform apply is usually recoverable; a bad customer email is not. That asymmetry in blast radius is the whole argument for where the line sits.

Every play above should mark each step as either automated (detect/draft) or gated (send/commit). A play silent on this ends up either fully manual and slow, or fully automated and one bad customer-facing message from a real problem.

==Incident Response for At-Risk Accounts==

Most CS orgs let an at-risk account drift in "I'll check on that" limbo for weeks until it either recovers or churns and surprises everyone in the renewal forecast. Declare an account incident when a health score crosses into the critical band, or when a running play's own escalation trigger fires without resolution in its window.

'''Severity levels:'''
* '''Sev1''' — imminent churn, or the customer has already escalated to an executive. Daily standup, exec sponsor pulled in immediately.
* '''Sev2''' — clearly at-risk but not yet in free-fall. Twice-weekly check-in, CS leadership visibility.
* '''Sev3''' — watch status. The triggering play is running; escalate only if it misses its own success criteria.

'''Roles:''' an incident owner (usually the account's CSM or TAM) runs the response and owns the timeline; CS leadership gets visibility on Sev2+ and direct involvement on Sev1; product, support, sales, or the exec sponsor get pulled in depending on whether the gap is technical, commercial, or relational.

An incident closes in one of two states, both logged: '''resolved''' (health score recovers, or the renewal/expansion completes) or '''lost''' (the account churns or downsizes despite the response). Both states feed [[The Postmortem (Churn and Save Retros)|the postmortem]] — a save is just as worth reviewing as a loss.

==Where this feeds==

A resolved risk becomes evidence for [[Renew]]. Every incident and every play run — win or loss — feeds [[The Postmortem (Churn and Save Retros)]], which is what turns this phase from a one-time setup into an actual system.

[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]
[[Category:Technical Account Manager]]
[[Category:AI Agents]]

Risk - Revision history

BrettFullmer: New phase page: Risk (phase 3 of 5) - plays, confirm gate, incident response