|
|
| Line 1: |
Line 1: |
| Part of [[The Playbook]]. Most CS orgs let an at-risk account drift in "I'll check on that" limbo for weeks — no owner, no urgency, no cross-functional priority — until it either recovers on its own or churns and surprises everyone in the renewal forecast meeting. Formal incident response exists to make that drift impossible.
| | #REDIRECT [[Risk]] |
| | |
| ==When to declare==
| |
| | |
| Declare an account incident when a [[Observability (Customer Health Scoring)|health score]] crosses into the critical band, or when a running [[The Play Library|play]]'s own escalation trigger fires without resolution in its defined window. 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 this process removes.
| |
| | |
| ==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, no exec pull-in yet.
| |
| * '''Sev3''' — watch status. The triggering play is running; escalate to Sev2 only if it misses its own success criteria.
| |
| | |
| ==Roles==
| |
| | |
| * '''Incident owner''' — usually the account's CSM or TAM; runs the response and owns the timeline
| |
| * '''CS leadership''' — visibility on Sev2+, direct involvement on Sev1
| |
| * '''Pulled-in functions''' — product (if the gap is a roadmap gap), support (if it's an unresolved technical issue), sales or the exec sponsor (if it's a commercial or relationship issue)
| |
| * '''Communication cadence''' — set at declaration, not improvised; a Sev1 with no standup scheduled isn't actually being treated as a Sev1
| |
| | |
| ==Closing an incident==
| |
| | |
| An incident closes in one of two states, both logged: '''resolved''' (health score recovers past the threshold, or the renewal/expansion completes) or '''lost''' (the account churns or downsizes despite the response). Both states — not just the loss — feed [[The Postmortem (Churn and Save Retros)|the postmortem]]. A save is just as worth reviewing as a loss; it's the only way to find out which part of the response actually worked versus which part just happened to coincide with a good outcome.
| |
| | |
| ==Why the formality matters==
| |
| | |
| The value isn't the paperwork — it's that declaring forces an owner, a timeline, and a stated severity into the open, where the account can't quietly fall off anyone's list. Informal "I'm keeping an eye on it" tracking dies the moment that CSM goes on vacation or moves to a different account. A declared incident survives handoffs.
| |
| | |
| [[Category:Customer Success Manager]]
| |
| [[Category:Technical Account Manager]]
| |
