Fullmer Wiki - User contributions [en]

Customer Lifecycle Stages

2026-09-01T18:07:34Z

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

#REDIRECT [[The Playbook]]

Incident Response for At-Risk Accounts

2026-09-01T18:07:34Z

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

#REDIRECT [[Risk]]

The Confirm Gate

2026-09-01T18:07:33Z

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

#REDIRECT [[Risk]]

The Play Library

2026-09-01T18:07:33Z

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

#REDIRECT [[Risk]]

SLOs for Customer Outcomes

2026-09-01T18:07:33Z

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

#REDIRECT [[Renew]]

Observability (Customer Health Scoring)

2026-09-01T18:07:33Z

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

#REDIRECT [[Adopt]]

Grow

2026-09-01T18:07:18Z

BrettFullmer: New phase page: Grow (phase 5 of 5) - expansion and advocacy

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

==Expansion: a second, smaller onboarding==

The reward for the earlier phases going well, run by the growth motion rather than the save motion — the positive-signal counterpart to [[Risk|the play library]], triggered by a thriving [[Adopt|health score]] instead of a declining one. Treat expansion like a second, smaller onboarding: it has its own time-to-value clock, and skipping that discipline because "they're already a customer" is how expansion deals quietly become the next churn risk. Route an expanding account back through [[Onboard]]'s deploy discipline for the new footprint, not around it.

==Advocacy==

References, case studies, community participation. The lagging proof that every earlier phase worked — and a leading indicator in its own right, since an account still willing to advocate is rarely one about to churn.

==Where this feeds==

Growth and advocacy signals loop back into [[Adopt]]'s health score, and a successful expansion restarts the cycle: the newly expanded footprint gets its own [[Onboard|onboarding]] clock.

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

Renew

2026-09-01T18:06:30Z

BrettFullmer: New phase page: Renew (phase 4 of 5) - SLOs, NRR/GRR, error budget

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

==Should never be a surprise==

If [[Adopt|health scores]] and this phase's targets have been tracked honestly through the earlier phases, the renewal conversation is confirming a decision that was already visible weeks out — not making the case for the first time at the eleventh hour.

==Set targets, not aspirations==

Vague goals ("delight the customer," "drive adoption") can't be measured or missed. Real targets for this phase:

* '''Net Revenue Retention (NRR)''' — [(starting recurring revenue + expansion − contraction − churn) ÷ starting recurring revenue] × 100. Segment by ACV before comparing anything — it's the single most reliable lens for NRR benchmarking, and the spread is wide: SMB tiers run roughly 90–105%, the $25K–50K ACV band sits at a median of 102% (111% top quartile), and enterprise tiers reach 115–125% on the strength of expansion. A single blended company-wide number hides which tier is actually carrying it and which is dragging it down.
* '''Gross Revenue Retention (GRR)''' — the same formula without expansion in the numerator, so it can never exceed 100%. This is where a leaky base shows up even when a few big upsells are making NRR look fine. 95%+ is the generally accepted healthy floor.

GRR and NRR are reported side by side on purpose: a strong NRR built on expansion inside a shrinking base is a warning sign the top-line number hides.

==Segment your targets — one number does not fit every tier==

An enterprise account with a named CSM, a technical champion, and a six-figure contract should have a tighter, higher target than a self-serve SMB account managed at scale. Setting one target across every tier either starves your top accounts of attention or burns your team chasing SMB accounts to a standard they were never priced to receive.

==The error budget idea, applied to CS==

Google's SRE book defines an error budget as the quarterly allowance of acceptable unreliability implied by a service's target: hit a 99.9% uptime target and the budget is the roughly 8.77 hours a year you're allowed to spend on downtime before the team stops shipping features and pivots to fixing reliability instead. It's an explicit, pre-agreed trade-off, not an after-the-fact excuse.

The CS equivalent: how much acceptable churn/contraction risk exists in the base before the team throttles new-logo [[Onboard|onboarding]] intake or [[Grow|expansion]] pushes and redirects capacity to shoring up existing accounts. Most CS orgs never make this trade-off explicit — they just let at-risk accounts pile up quietly while chasing this quarter's expansion number. Naming the budget, the same concrete way Google names it in hours and percentages, forces the conversation before it becomes a crisis.

==Where this feeds==

Target misses should trigger a [[Risk|play]] proactively, not just a reactive health-score dip. A clean renewal is the gate to [[Grow]].

==Sources==

* [https://www.saas-capital.com/research/ SaaS Capital — private B2B SaaS retention benchmark research] — NRR/GRR by ACV segment
* [https://sre.google/sre-book/embracing-risk/ Google — ''Site Reliability Engineering'', "Embracing Risk"] — error budget definition

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

Risk

2026-09-01T18:04:40Z

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

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

Adopt

2026-09-01T18:01:42Z

BrettFullmer: New phase page: Adopt (phase 2 of 5) - health scoring

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

==The gap between onboarded and adopted==

The gap between "onboarded" and "actually using the product for real work." Surface-level login activity can look fine while the account never adopts the workflows that create switching cost. The point where the customer can articulate, in their own words and ideally with their own numbers, what the product is worth to them, is value realization — the moment this phase's signal should shift from "watch it" to "expansion candidate."

==Observability: the health score==

You can't manage adoption you can't see. A customer health score is the monitoring layer of Customer Success — it tells you the state of an account before the customer has to tell you themselves. A health score that only measures sentiment is a lagging indicator dressed up as a dashboard. The useful ones combine:

* '''Product usage and adoption depth''' — not just "did they log in," but which features, how deep, and whether usage is trending up or down. This is the highest-weight signal, because usage drops before satisfaction scores do.
* '''Support signal''' — ticket volume and severity trend, not a raw count. A spike after a quiet stretch matters more than a steady baseline.
* '''Relationship and engagement''' — meeting attendance, response latency, whether the champion is still the champion or quietly changed jobs.
* '''Commercial signal''' — contract terms, upcoming renewal date, prior expansion or contraction history.
* '''CSM/TAM pulse''' — the qualitative gut-check from the human who actually talks to the account. Don't let the model override this; let it flag disagreement instead.

That's five, and five is close to the ceiling, not the floor. Gainsight's own published guidance lands on 4–6 signals as the practical range — usage, support trend, sentiment, executive engagement — and every dimension past that adds noise, not accuracy. Drop any signal the team has no ability to influence, however clean its data source is; a health score is a tool for action, not a trivia dashboard.

A real example of why blending beats any single signal: support-ticket volume alone routinely misdirects attention. Teams that scored health on raw ticket count found their loudest, highest-ticket accounts were often their most engaged customers — while quieter, genuinely at-risk accounts generated no signal at all and slipped through unnoticed. Blending usage alongside support volume catches what raw ticket counts hide.

==Leading vs. lagging==

Leading indicators (usage decline, feature abandonment, unanswered emails) predict a problem before it's visible. Lagging indicators (a formal complaint, a support escalation, a churn notice) confirm a problem that's already arrived. A health score built entirely on lagging indicators is just a churn report with extra steps — weight leading indicators higher, and treat lagging indicators as confirmation, not discovery.

==Score bands and what they trigger==

A workable default, tuned per business:

{| class="wikitable"
! Band !! Meaning !! Action
|-
| 0–40 || Critical || Move to [[Risk|Declare an incident]]
|-
| 41–60 || At-risk || Run the matching [[Risk|play]], proactively
|-
| 61–80 || Healthy || Standard cadence, no special action
|-
| 81–100 || Thriving || Flag for [[Grow|expansion]]
|}

==What breaks health scores==

* '''Overcomplication.''' A score with 40 weighted inputs is a score nobody trusts and nobody can explain to a customer's exec sponsor. Fewer inputs, clearly defensible, beats a black box every time.
* '''Static snapshots.''' A single number hides the story. Track the trend — an account moving from 90 to 65 over three weeks is a different problem than one sitting at 65 for a year.
* '''Mistaking activity for engagement.''' Logins aren't adoption. A user opening the product every day to check one report they could get from an email digest is not a healthy account, even though the login graph looks great.

==Where this feeds==

A dip into the at-risk or critical band routes to [[Risk]]. A thriving score is the evidence [[Renew]] and [[Grow]] both need in hand before their conversations start.

==Sources==

* [https://www.gainsight.com/blog/customer-health-scores/ Gainsight — "Customer Health Score Explained: Metrics, Models & Tools"] — 4–6 signal guidance
* [https://churnzero.com/blog/customer-health-scores-in-the-age-of-ai/ ChurnZero — "Customer Health Scores in the Age of AI"]

[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]

Onboard

2026-09-01T17:59:05Z

BrettFullmer: New phase page: Onboard (phase 1 of 5)

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

==Treat it as a deploy, not a checklist==

Most onboarding programs are a task checklist: accounts created, training scheduled, kickoff call held. None of that is a deploy — a deploy has defined success criteria set before you start, a staged rollout instead of flipping everything on at once, and a rollback or rescue plan if it doesn't go live cleanly. Onboarding should work the same way: a stated time-to-first-value target, a phased rollout across teams or use cases rather than a big-bang launch, and a named rescue path if the customer isn't live on schedule.

==The stakes are concrete==

Customers who reach first value within 14 days retain at 80%+ a year later; customers who miss the 30-day mark retain at only 35–50%. Onboarding speed is close to the single biggest lever a CS org has over year-one churn — which is exactly why it's phase one, not a formality before the "real" work starts.

==Set a real time-to-first-value target==

There's no honest single universal number — benchmarks split sharply by segment (roughly 7 days for SMB, 12 for enterprise, sub-2-days for fast self-serve categories) — but the target should be a specific "aha" milestone, not "onboarding complete." Measure days from contract signature to that milestone, not to some internal completion checkbox.

==Where this feeds==

A customer who hits their onboarding target moves cleanly into [[Adopt]]. One who doesn't is the first entry in the [[Risk|Post-Onboarding Adoption Lag Play]].

==Sources==

* [https://userpilot.com/blog/time-to-value-benchmark-report-2024/ Userpilot — 2024 Time-to-Value Benchmark Report] — TTV medians and the 14-/30-day retention cliff

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

The Playbook

2026-09-01T17:58:01Z

BrettFullmer: Restructure hub around 5-phase funnel: Onboard, Adopt, Risk, Renew, Grow

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

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

# '''[[Onboard]]''' — treat it like a deploy, not a checklist. The single biggest lever over year-one churn.
# '''[[Adopt]]''' — the health score: what to measure, how few signals you actually need, and what breaks it.
# '''[[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.

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.

==Supporting practices==

* '''[[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.
* '''[[CSM vs TAM vs Customer Engineer]]''' — who on the team actually owns which phase.

==Who this is for==

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.

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

Customer Lifecycle Stages

2026-09-01T17:49:44Z

BrettFullmer: Add TTV retention-cliff evidence to onboarding section and Sources

Part of [[The Playbook]]. The timeline that [[The Play Library|plays]] and [[SLOs for Customer Outcomes|SLOs]] run against. Six stages, each with a different job to do and a different failure mode to watch for.

==Onboarding — treat it as a deploy, not a checklist==

Most onboarding programs are a task checklist: accounts created, training scheduled, kickoff call held. None of that is a deploy — a deploy has defined success criteria set before you start, a staged rollout instead of flipping everything on at once, and a rollback or rescue plan if it doesn't go live cleanly. Onboarding should work the same way: a stated time-to-first-value target (see [[SLOs for Customer Outcomes]]), a phased rollout across teams or use cases rather than a big-bang launch, and a named rescue path — usually the [[The Play Library|Post-Onboarding Adoption Lag Play]] — if the customer isn't live on schedule.

The stakes here aren't abstract. Customers who reach first value within 14 days retain at 80%+ a year later; customers who miss the 30-day mark retain at only 35–50%. Onboarding speed is close to the single biggest lever a CS org has over year-one churn — which is exactly why it's the first stage in this list, not a formality before the "real" work starts.

==Adoption==

The gap between "onboarded" and "actually using the product for real work." This is where [[Observability (Customer Health Scoring)|health score]] usage-depth signals matter most — surface-level login activity can look fine while the account never adopts the workflows that create switching cost.

==Value realization==

The point where the customer can articulate, in their own words and ideally with their own numbers, what the product is worth to them. This is the moment a health score should shift from "watch it" to "expansion candidate," and it's the evidence a [[The Play Library|renewal play]] needs in hand well before the renewal conversation starts.

==Renewal==

Should never be a surprise conversation. If the [[SLOs for Customer Outcomes|SLOs]] and health score have been tracked honestly through the prior stages, the renewal play is confirming a decision that was already visible weeks out — not making the case for the first time at the eleventh hour.

==Expansion==

The reward for the earlier stages going well, run by the growth motion rather than the save motion (see [[The Play Library|Expansion-Ready Play]]). Treat expansion like a second, smaller onboarding — it has its own time-to-value clock, and skipping that discipline because "they're already a customer" is how expansion deals quietly become the next churn risk.

==Advocacy==

References, case studies, community participation. The lagging proof that every earlier stage worked — and a leading indicator in its own right, since an account still willing to advocate is rarely one about to churn.

==Sources==

* [https://userpilot.com/blog/time-to-value-benchmark-report-2024/ Userpilot — 2024 Time-to-Value Benchmark Report] — the 14-/30-day retention cliff

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

SLOs for Customer Outcomes

2026-09-01T17:48:05Z

BrettFullmer: Add ACV-segmented NRR/GRR data, sourced error budget, TTV benchmarks and retention cliff, Sources section

Part of [[The Playbook]]. [[Observability (Customer Health Scoring)|A health score]] tells you an account's state. An SLO (service level objective) tells you what state you actually promised to deliver — a measurable target, not a vibe. Borrowed straight from infrastructure: an SRE doesn't say "the site should be pretty reliable," they say "99.9% uptime, measured monthly, with an error budget." Customer Success needs the same discipline.

==Set targets, not aspirations==

Vague goals ("delight the customer," "drive adoption") aren't SLOs — they can't be measured or missed. Real SLO candidates:

* '''Time-to-first-value''' — days from contract signature to the customer hitting a defined "aha" milestone, not just "onboarding complete." There's no honest single universal number — benchmarks split sharply by segment (roughly 7 days for SMB, 12 for enterprise, sub-2-days for fast self-serve categories) — but the retention cliff behind the number is real and worth setting a target against: customers who reach first value within 14 days retain at 80%+ a year later, while those who miss the 30-day mark retain at only 35–50%. Onboarding speed is close to the single biggest lever a CS org has over year-one churn.
* '''Adoption depth by day 90''' — percentage of licensed seats or core workflows actively used, measured against a stated target, not just "some usage."
* '''Net Revenue Retention (NRR)''' — [(starting recurring revenue + expansion − contraction − churn) ÷ starting recurring revenue] × 100. Segment by ACV before comparing anything — it's the single most reliable lens for NRR benchmarking, and the spread is wide: SMB tiers run roughly 90–105%, the $25K–50K ACV band sits at a median of 102% (111% top quartile), and enterprise tiers reach 115–125% on the strength of expansion. A single blended company-wide number hides which tier is actually carrying it and which is dragging it down.
* '''Gross Revenue Retention (GRR)''' — the same formula without expansion in the numerator, so it can never exceed 100%. This is where a leaky base shows up even when a few big upsells are making NRR look fine. 95%+ is the generally accepted healthy floor.

GRR and NRR are reported side by side on purpose: a strong NRR built on expansion inside a shrinking base is a warning sign the top-line number hides.

==Segment your SLOs — one target does not fit every tier==

An enterprise account with a named CSM, a technical champion, and a six-figure contract should have a tighter, higher target and more play intensity than a self-serve SMB account managed at scale. Setting one SLO across every tier either starves your top accounts of attention or burns your team chasing SMB accounts to a standard they were never priced to receive.

==The error budget idea, applied to CS==

Google's SRE book defines an error budget as the quarterly allowance of acceptable unreliability implied by a service's SLO: hit a 99.9% uptime target and the budget is the roughly 8.77 hours a year you're allowed to spend on downtime before the team stops shipping features and pivots to fixing reliability instead. It's an explicit, pre-agreed trade-off, not an after-the-fact excuse.

The CS equivalent: how much acceptable churn/contraction risk exists in the base before the team throttles new-logo onboarding intake or expansion pushes and redirects capacity to shoring up existing accounts. Most CS orgs never make this trade-off explicit — they just let the at-risk accounts pile up quietly while chasing this quarter's expansion number. Naming the budget, the same concrete way Google names it in hours and percentages, forces the conversation before it becomes a crisis.

==Where this feeds==

SLO misses are what should trigger a [[The Play Library|play]] proactively, not just a reactive health-score dip. A pattern of SLO misses across a segment is a [[The Postmortem (Churn and Save Retros)|postmortem]]-worthy signal even before any single account churns.

==Sources==

* [https://www.saas-capital.com/research/ SaaS Capital — private B2B SaaS retention benchmark research] — NRR/GRR by ACV segment
* [https://sre.google/sre-book/embracing-risk/ Google — ''Site Reliability Engineering'', "Embracing Risk"] — error budget definition
* [https://userpilot.com/blog/time-to-value-benchmark-report-2024/ Userpilot — 2024 Time-to-Value Benchmark Report] — TTV medians and the 14-/30-day retention cliff

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

Observability (Customer Health Scoring)

2026-09-01T17:45:45Z

BrettFullmer: Add Gainsight 4-6 signal guidance, blending example, and Sources section

Part of [[The Playbook]]. Before you can run a play, you need to know something's wrong. Observability is the monitoring layer of Customer Success: a customer health score that tells you the state of an account before the customer has to tell you themselves.

==What actually goes into a health score==

A health score that only measures sentiment is a lagging indicator dressed up as a dashboard. The useful ones combine:

* '''Product usage and adoption depth''' — not just "did they log in," but which features, how deep, and whether usage is trending up or down. This is the highest-weight signal, because usage drops before satisfaction scores do.
* '''Support signal''' — ticket volume and severity trend, not a raw count. A spike after a quiet stretch matters more than a steady baseline.
* '''Relationship and engagement''' — meeting attendance, response latency, whether the champion is still the champion or quietly changed jobs.
* '''Commercial signal''' — contract terms, upcoming renewal date, prior expansion or contraction history.
* '''CSM/TAM pulse''' — the qualitative gut-check from the human who actually talks to the account. Don't let the model override this; let it flag disagreement instead.

That's five, and five is close to the ceiling, not the floor. Gainsight's own published guidance lands on 4–6 signals as the practical range — usage, support trend, sentiment, executive engagement — and every dimension past that adds noise, not accuracy. Drop any signal the team has no ability to influence, however clean its data source is; a health score is a tool for action, not a trivia dashboard.

A real example of why blending beats any single signal: support-ticket volume alone routinely misdirects attention. Teams that scored health on raw ticket count found their loudest, highest-ticket accounts were often their most engaged customers — while quieter, genuinely at-risk accounts generated no signal at all and slipped through unnoticed. Blending usage alongside support volume catches what raw ticket counts hide.

==Leading vs. lagging==

Leading indicators (usage decline, feature abandonment, unanswered emails) predict a problem before it's visible. Lagging indicators (a formal complaint, a support escalation, a churn notice) confirm a problem that's already arrived. A health score built entirely on lagging indicators is just a churn report with extra steps — weight leading indicators higher, and treat lagging indicators as confirmation, not discovery.

==Score bands and what they trigger==

A workable default, tuned per business:

{| class="wikitable"
! Band !! Meaning !! Action
|-
| 0–40 || Critical || [[Incident Response for At-Risk Accounts|Declare an incident]]
|-
| 41–60 || At-risk || Run the matching [[The Play Library|play]], proactively
|-
| 61–80 || Healthy || Standard cadence, no special action
|-
| 81–100 || Thriving || Flag for expansion, hand to the growth motion
|}

==What breaks health scores==

* '''Overcomplication.''' A score with 40 weighted inputs is a score nobody trusts and nobody can explain to a customer's exec sponsor. Fewer inputs, clearly defensible, beats a black box every time.
* '''Static snapshots.''' A single number hides the story. Track the trend — an account moving from 90 to 65 over three weeks is a different problem than one sitting at 65 for a year.
* '''Mistaking activity for engagement.''' Logins aren't adoption. A user opening the product every day to check one report they could get from an email digest is not a healthy account, even though the login graph looks great.

==Where this feeds==

The score sets the trigger for [[The Play Library]] and defines the target in [[SLOs for Customer Outcomes]]. When a score crosses into critical, it's the input to [[Incident Response for At-Risk Accounts]].

==Sources==

* [https://www.gainsight.com/blog/customer-health-scores/ Gainsight — "Customer Health Score Explained: Metrics, Models & Tools"] — 4–6 signal guidance
* [https://churnzero.com/blog/customer-health-scores-in-the-age-of-ai/ ChurnZero — "Customer Health Scores in the Age of AI"]

[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]

CSM vs TAM vs Customer Engineer

2026-09-01T17:07:17Z

BrettFullmer: Publish CSM vs TAM vs Customer Engineer page

Part of [[The Playbook]]. [[The Play Library]] is role-agnostic at the trigger level — a champion-departure signal fires the same way regardless of who owns the account — but the three most common customer-facing titles differ in what they're actually equipped, and expected, to do about it.

==Customer Success Manager (CSM)==

Success-oriented and largely non-technical. Owns the relationship end to end: adoption, renewal, expansion, and increasingly commercial ownership that used to sit with a dedicated account manager. The best CSMs have absorbed the commercial skill set — renewal and upsell conversations — the same way the best account managers have absorbed a success-oriented approach instead of a pure quota mindset. Primary owner of the [[Customer Lifecycle Stages|lifecycle]]-stage plays: onboarding, adoption, renewal, expansion.

==Technical Account Manager (TAM)==

A CSM with technical depth added — able to work an actual product or infrastructure issue instead of just routing it, while still owning the relationship and the success outcome. Sits closer to the account than a support engineer, closer to the relationship than a pure technical resource. Best positioned to own plays with a technical trigger: architecture reviews, integration health, anything where "checking the ticket volume" (see [[Observability (Customer Health Scoring)]]) means actually reading the tickets.

==Customer Engineer (CE)==

The deepest technical role of the three, usually weighted toward pre-sales technical validation and post-sales implementation rather than the ongoing relationship. Closest to product and engineering; often the one actually diagnosing why an integration is failing rather than escalating it. In [[The Play Library]] terms, the CE is frequently the pulled-in specialist on a play's escalation path rather than the play's owner.

==Where the lines blur==

Smaller companies collapse all three into one title and expect one person to run the relationship, the renewal, and the technical troubleshooting. Larger orgs split them explicitly, sometimes assigning multiple named roles to a single strategic account. Neither is wrong — but a play library written without stating which model an org runs will get ignored, because "owner: CSM" means something different in a company where the CSM handles integration debugging than in one where a CE always does.

==Why this page exists in the Playbook==

A play with an undefined owner doesn't get run consistently — it gets run by whoever happens to notice the trigger fire, which is exactly the tribal-knowledge problem [[The Play Library]] exists to remove. Naming the role architecture explicitly, before writing the plays, is what makes "owner" in a play template mean something concrete instead of "someone, eventually."

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

Customer Lifecycle Stages

2026-09-01T17:05:47Z

BrettFullmer: Publish Customer Lifecycle Stages page

Part of [[The Playbook]]. The timeline that [[The Play Library|plays]] and [[SLOs for Customer Outcomes|SLOs]] run against. Six stages, each with a different job to do and a different failure mode to watch for.

==Onboarding — treat it as a deploy, not a checklist==

Most onboarding programs are a task checklist: accounts created, training scheduled, kickoff call held. None of that is a deploy — a deploy has defined success criteria set before you start, a staged rollout instead of flipping everything on at once, and a rollback or rescue plan if it doesn't go live cleanly. Onboarding should work the same way: a stated time-to-first-value target (see [[SLOs for Customer Outcomes]]), a phased rollout across teams or use cases rather than a big-bang launch, and a named rescue path — usually the [[The Play Library|Post-Onboarding Adoption Lag Play]] — if the customer isn't live on schedule.

==Adoption==

The gap between "onboarded" and "actually using the product for real work." This is where [[Observability (Customer Health Scoring)|health score]] usage-depth signals matter most — surface-level login activity can look fine while the account never adopts the workflows that create switching cost.

==Value realization==

The point where the customer can articulate, in their own words and ideally with their own numbers, what the product is worth to them. This is the moment a health score should shift from "watch it" to "expansion candidate," and it's the evidence a [[The Play Library|renewal play]] needs in hand well before the renewal conversation starts.

==Renewal==

Should never be a surprise conversation. If the [[SLOs for Customer Outcomes|SLOs]] and health score have been tracked honestly through the prior stages, the renewal play is confirming a decision that was already visible weeks out — not making the case for the first time at the eleventh hour.

==Expansion==

The reward for the earlier stages going well, run by the growth motion rather than the save motion (see [[The Play Library|Expansion-Ready Play]]). Treat expansion like a second, smaller onboarding — it has its own time-to-value clock, and skipping that discipline because "they're already a customer" is how expansion deals quietly become the next churn risk.

==Advocacy==

References, case studies, community participation. The lagging proof that every earlier stage worked — and a leading indicator in its own right, since an account still willing to advocate is rarely one about to churn.

[[Category:Customer Success Manager]]
[[Category:Technical Account Manager]]

The Postmortem (Churn and Save Retros)

2026-09-01T17:04:21Z

BrettFullmer: Publish The Postmortem (Churn and Save Retros) page

Part of [[The Playbook]]. This is the page that turns everything else here from a one-time setup into an actual system. Without it, [[Observability (Customer Health Scoring)|health scores]] go stale, [[The Play Library|plays]] never improve, and the same account failure mode repeats with a different customer's name on it every quarter.

==Blameless, and mean it==

The point of a postmortem is not to find who missed the signal — it's to find what the system missed, because a person will always be the last link in a chain of things the system should have caught earlier. A postmortem culture that assigns blame teaches CSMs to hide problems until they're unrecoverable, which produces exactly the surprise churn the whole system exists to prevent.

==Run one after every [[Incident Response for At-Risk Accounts|incident]], win or loss==

* '''Timeline''' — what happened, in order, from first available signal to close
* '''Root cause, not proximate cause''' — "the champion left" is proximate; "we had no relationship with anyone else at the account" is the root cause, and it's the one worth fixing
* '''What the health score caught or missed''' — did the signal fire in time, or did the score need an input it didn't have
* '''What the play caught or missed''' — did the matching play exist, did it trigger correctly, did the owner follow it
* '''What changes as a result''' — a new play, an adjusted trigger threshold, a new [[Observability (Customer Health Scoring)|health score]] input, a revised [[SLOs for Customer Outcomes|SLO]]. A postmortem with no resulting change didn't do its job.

==Don't skip the wins==

Most CS orgs only postmortem the losses. That means the org only ever learns what fails, never what specifically worked — so a save that happened because one CSM improvised something clever never becomes a documented play, and the next CSM who hits the same signal starts from zero again. Review saves with the same rigor as churns; the output is a new entry in [[The Play Library]] instead of a fix to an existing one.

==Where the output goes==

Every postmortem should produce at least one concrete edit to another page in [[The Playbook]] — that's the test for whether it was worth running. If a postmortem's conclusion is "nothing to change," either the incident really was a one-off, or the review wasn't dug into deeply enough.

[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]

Incident Response for At-Risk Accounts

2026-09-01T17:03:07Z

BrettFullmer: Publish Incident Response for At-Risk Accounts page

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.

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

The Confirm Gate

2026-09-01T17:01:40Z

BrettFullmer: Publish The Confirm Gate page

Part of [[The Playbook]]. This is the chapter that comes straight out of building [[MAC]] and running the [[Spacelift]] practice labs, not out of a CS textbook.

The whole design of the Spacelift setup rests on one rule: plan and apply are structurally separate, and nothing touches production without a human confirming. The automation API key is scoped read-only by design — it hard-fails on anything that tries to trigger a deploy. Read access for tooling, write access for a human, on two separate credentials. That's not a slogan, it's an enforced boundary.

Apply the same boundary to the customer relationship, and you get the Confirm Gate.

==Two tiers of access, not one==

'''Detect and draft — automated, no gate.''' An AI agent can watch usage data, flag a [[Observability (Customer Health Scoring)|health score]] crossing a threshold, pull the 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. This is the equivalent of the mandatory apply confirmation: automation gets you to the edge of the action, a person decides whether to take it.

==Why the line sits exactly there==

A bad Terraform apply is usually recoverable — you have state, you have version history, you can roll back. A bad customer email is not recoverable in the same way; it's read, it's judged, and the relationship absorbs it whether or not you catch the mistake five minutes later. The asymmetry in blast radius is the whole argument for where the gate goes. It's also why "AI is going to replace your job" is the wrong fear: automation removed the boring 60% of the work — the digging through account history, the first-draft QBR deck, the "let me check the ticket volume" busywork — and left the judgment-heavy 40% exactly where it belongs.

==What this looks like in the Play Library==

Every play in [[The Play Library]] should mark each step as either automated (detect/draft) or gated (send/commit). A play that's silent on this ends up either fully manual — slow, doesn't scale — or fully automated — fast, and one bad customer-facing message away from a real problem.

==The tell that a team got this wrong==

If an AI agent is sending customer-facing messages without a human in the loop "because it's usually fine," that's not efficiency, that's an unscoped write credential on a production system. The fix is the same fix as the Spacelift automation key: split the access, not the trust.

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

The Play Library

2026-09-01T17:00:16Z

BrettFullmer: Publish The Play Library 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]]

SLOs for Customer Outcomes

2026-09-01T16:58:42Z

BrettFullmer: Publish SLOs for Customer Outcomes page

Observability (Customer Health Scoring)

2026-09-01T16:57:07Z

BrettFullmer: Publish Observability (Customer Health Scoring) page

Part of [[The Playbook]]. Before you can run a play, you need to know something's wrong. Observability is the monitoring layer of Customer Success: a customer health score that tells you the state of an account before the customer has to tell you themselves.

==What actually goes into a health score==

A health score that only measures sentiment is a lagging indicator dressed up as a dashboard. The useful ones combine:

* '''Product usage and adoption depth''' — not just "did they log in," but which features, how deep, and whether usage is trending up or down. This is the highest-weight signal, because usage drops before satisfaction scores do.
* '''Support signal''' — ticket volume and severity trend, not a raw count. A spike after a quiet stretch matters more than a steady baseline.
* '''Relationship and engagement''' — meeting attendance, response latency, whether the champion is still the champion or quietly changed jobs.
* '''Commercial signal''' — contract terms, upcoming renewal date, prior expansion or contraction history.
* '''CSM/TAM pulse''' — the qualitative gut-check from the human who actually talks to the account. Don't let the model override this; let it flag disagreement instead.

==Leading vs. lagging==

Leading indicators (usage decline, feature abandonment, unanswered emails) predict a problem before it's visible. Lagging indicators (a formal complaint, a support escalation, a churn notice) confirm a problem that's already arrived. A health score built entirely on lagging indicators is just a churn report with extra steps — weight leading indicators higher, and treat lagging indicators as confirmation, not discovery.

==Score bands and what they trigger==

A workable default, tuned per business:

{| class="wikitable"
! Band !! Meaning !! Action
|-
| 0–40 || Critical || [[Incident Response for At-Risk Accounts|Declare an incident]]
|-
| 41–60 || At-risk || Run the matching [[The Play Library|play]], proactively
|-
| 61–80 || Healthy || Standard cadence, no special action
|-
| 81–100 || Thriving || Flag for expansion, hand to the growth motion
|}

==What breaks health scores==

* '''Overcomplication.''' A score with 40 weighted inputs is a score nobody trusts and nobody can explain to a customer's exec sponsor. Fewer inputs, clearly defensible, beats a black box every time.
* '''Static snapshots.''' A single number hides the story. Track the trend — an account moving from 90 to 65 over three weeks is a different problem than one sitting at 65 for a year.
* '''Mistaking activity for engagement.''' Logins aren't adoption. A user opening the product every day to check one report they could get from an email digest is not a healthy account, even though the login graph looks great.

==Where this feeds==

The score sets the trigger for [[The Play Library]] and defines the target in [[SLOs for Customer Outcomes]]. When a score crosses into critical, it's the input to [[Incident Response for At-Risk Accounts]].

[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]

The Playbook

2026-09-01T16:55:27Z

BrettFullmer: Publish The Playbook hub page

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.

==Why this framing==

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 six plays==

'''Instrumentation''' — knowing the state of the fleet before anything goes wrong:
* [[Observability (Customer Health Scoring)]] — the monitoring layer: what to measure and why
* [[SLOs for Customer Outcomes]] — what "healthy" actually means, as a number, per segment

'''Response''' — what happens when the monitor fires:
* [[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:
* [[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==
* [[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 play

==Who this is for==

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.

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