Jump to content

The Playbook: Difference between revisions

From Fullmer Wiki
Publish The Playbook hub page
 
Restructure hub around 5-phase funnel: Onboard, Adopt, Risk, Renew, Grow
 
Line 1: Line 1:
Most Customer Success functions are still run on vibes: a spreadsheet, a gut feeling about which accounts are "fine," and a QBR deck built the night before. Every other function touching production risk — infrastructure, security, finance — long ago moved to systems: instrumentation, defined targets, standardized response procedures, and a blameless review when something breaks. Customer Success hasn't caught up, and the gap shows up as surprise churn.
Most Customer Success functions are still run on vibes: a spreadsheet, a gut feeling about which accounts are "fine," and a QBR deck built the night before. Every other function touching production risk — infrastructure, security, finance — long ago moved to systems: instrumentation, defined targets, standardized response procedures, and a blameless review when something breaks. Customer Success hasn't caught up, and the gap shows up as surprise churn.


The Playbook is an attempt to close that gap: treat the customer base the way a reliability engineer treats a fleet of production systems.
The Playbook is an attempt to close that gap, laid out as five phases every account moves through — and a system underneath each one, so none of it depends on tribal knowledge.


==Why this framing==
==Why this framing==
Line 7: Line 7:
Twenty-plus years in enterprise infrastructure and managed services means being the person a customer calls right after they've already tried turning it off and on again. That job runs on the same discipline as [[Spacelift]] and the practice labs on this site: plan and apply are structurally separate, nothing touches production without a human confirming, and every failure gets a real postmortem instead of a shrug. The Playbook applies that same discipline to the customer relationship instead of the AWS account.
Twenty-plus years in enterprise infrastructure and managed services means being the person a customer calls right after they've already tried turning it off and on again. That job runs on the same discipline as [[Spacelift]] and the practice labs on this site: plan and apply are structurally separate, nothing touches production without a human confirming, and every failure gets a real postmortem instead of a shrug. The Playbook applies that same discipline to the customer relationship instead of the AWS account.


The other half of the framing: since 2024, building AI agents (see [[MAC]]) that now do the boring 60% of this job. The Playbook is written for a world where automation already handles detection and drafting — the open question isn't whether AI touches the customer relationship, it's exactly where the human has to stay in the loop. [[The Confirm Gate]] is the chapter that answers that.
The other half of the framing: since 2024, building AI agents (see [[MAC]]) that now do the boring 60% of this job. The Playbook is written for a world where automation already handles detection and drafting — the open question isn't whether AI touches the customer relationship, it's exactly where the human has to stay in the loop. [[Risk]] is the phase that answers that.


==The six plays==
==The five phases==


'''Instrumentation''' — knowing the state of the fleet before anything goes wrong:
# '''[[Onboard]]''' — treat it like a deploy, not a checklist. The single biggest lever over year-one churn.
* [[Observability (Customer Health Scoring)]] — the monitoring layer: what to measure and why
# '''[[Adopt]]''' — the health score: what to measure, how few signals you actually need, and what breaks it.
* [[SLOs for Customer Outcomes]] — what "healthy" actually means, as a number, per segment
# '''[[Risk]]''' — the play library, the confirm gate, and incident response for accounts that cross into critical.
# '''[[Renew]]''' real targets instead of aspirations: NRR/GRR by segment, and an error budget for how much risk is acceptable before you throttle growth.
# '''[[Grow]]''' — expansion as a second, smaller onboarding, plus advocacy.


'''Response''' what happens when the monitor fires:
Each phase feeds the next a clean [[Onboard|Onboard]] sets up [[Adopt]], a dip in [[Adopt]] routes to [[Risk]], a resolved [[Risk]] becomes evidence for [[Renew]], and a clean [[Renew]] is the gate to [[Grow]] — which loops back into [[Adopt]] for the next cycle.
* [[The Play Library]] — standardized runbooks for recurring account signals
* [[The Confirm Gate]] — where automation stops and a human has to sign off


'''When it breaks''' — the failure path, done properly instead of ad hoc:
==Supporting practices==
* [[Incident Response for At-Risk Accounts]] — declaring, staffing, and running a save motion
* [[The Postmortem (Churn and Save Retros)]] — the blameless review that feeds back into every other page here


==Supporting concepts==
* '''[[The Postmortem (Churn and Save Retros)]]''' — the blameless review that closes the loop after every incident, save, or loss, and is what makes this a system instead of a one-time setup.
* [[Customer Lifecycle Stages]] — the timeline the plays run against, from onboarding to advocacy
* '''[[CSM vs TAM vs Customer Engineer]]''' — who on the team actually owns which phase.
* [[CSM vs TAM vs Customer Engineer]] — who on the team actually owns which play


==Who this is for==
==Who this is for==

Latest revision as of 17:58, 1 September 2026

Most Customer Success functions are still run on vibes: a spreadsheet, a gut feeling about which accounts are "fine," and a QBR deck built the night before. Every other function touching production risk — infrastructure, security, finance — long ago moved to systems: instrumentation, defined targets, standardized response procedures, and a blameless review when something breaks. Customer Success hasn't caught up, and the gap shows up as surprise churn.

The Playbook is an attempt to close that gap, laid out as five phases every account moves through — and a system underneath each one, so none of it depends on tribal knowledge.

Why this framing

[edit]

Twenty-plus years in enterprise infrastructure and managed services means being the person a customer calls right after they've already tried turning it off and on again. That job runs on the same discipline as Spacelift and the practice labs on this site: plan and apply are structurally separate, nothing touches production without a human confirming, and every failure gets a real postmortem instead of a shrug. The Playbook applies that same discipline to the customer relationship instead of the AWS account.

The other half of the framing: since 2024, building AI agents (see MAC) that now do the boring 60% of this job. The Playbook is written for a world where automation already handles detection and drafting — the open question isn't whether AI touches the customer relationship, it's exactly where the human has to stay in the loop. Risk is the phase that answers that.

The five phases

[edit]
  1. Onboard — treat it like a deploy, not a checklist. The single biggest lever over year-one churn.
  2. Adopt — the health score: what to measure, how few signals you actually need, and what breaks it.
  3. Risk — the play library, the confirm gate, and incident response for accounts that cross into critical.
  4. Renew — real targets instead of aspirations: NRR/GRR by segment, and an error budget for how much risk is acceptable before you throttle growth.
  5. Grow — expansion as a second, smaller onboarding, plus advocacy.

Each phase feeds the next — a clean Onboard sets up Adopt, a dip in Adopt routes to Risk, a resolved Risk becomes evidence for Renew, and a clean Renew is the gate to Grow — which loops back into Adopt for the next cycle.

Supporting practices

[edit]

Who this is for

[edit]

CS leaders scaling a motion past the point where tribal knowledge holds it together, and senior CSMs/TAMs who want a system instead of another "be customer-obsessed" slide. See The Playbook (book) for the long-form version of this argument.