Fullmer Wiki - Recent changes [en]

Incident Response for At-Risk Accounts

BrettFullmer — Tue, 01 Sep 2026 18:07:34 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
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~~]]

Customer Lifecycle Stages

BrettFullmer — Tue, 01 Sep 2026 18:07:34 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
Line 1:		Line 1:
	~~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.~~		#REDIRECT [[The Playbook]]

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

Observability (Customer Health Scoring)

BrettFullmer — Tue, 01 Sep 2026 18:07:33 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
Line 1:		Line 1:
	~~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.		#REDIRECT [[Adopt]]

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

SLOs for Customer Outcomes

BrettFullmer — Tue, 01 Sep 2026 18:07:33 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
Line 1:		Line 1:
	~~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.		#REDIRECT [[Renew]]

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

The Play Library

BrettFullmer — Tue, 01 Sep 2026 18:07:33 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
Line 1:		Line 1:
	~~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.		#REDIRECT [[Risk]]

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

The Confirm Gate

BrettFullmer — Tue, 01 Sep 2026 18:07:33 GMT

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

← Older revision		Revision as of 18:07, 1 September 2026
Line 1:		Line 1:
	~~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.~~		#REDIRECT [[Risk]]

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

Grow

BrettFullmer — Tue, 01 Sep 2026 18:07:18 GMT

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

New page

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

BrettFullmer — Tue, 01 Sep 2026 18:06:30 GMT

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

New page

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

BrettFullmer — Tue, 01 Sep 2026 18:04:40 GMT

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

Adopt

BrettFullmer — Tue, 01 Sep 2026 18:01:42 GMT

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

New page

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

BrettFullmer — Tue, 01 Sep 2026 17:59:05 GMT

New phase page: Onboard (phase 1 of 5)

New page

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

BrettFullmer — Tue, 01 Sep 2026 17:58:01 GMT

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

← Older revision		Revision as of 17:58, 1 September 2026
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==

Customer Lifecycle Stages

BrettFullmer — Tue, 01 Sep 2026 17:49:44 GMT

Add TTV retention-cliff evidence to onboarding section and Sources

← Older revision		Revision as of 17:49, 1 September 2026
Line 4:		Line 4:

	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.		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==		==Adoption==
Line 24:		Line 26:

	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.		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:Customer Success Manager]]
	[[Category:Technical Account Manager]]		[[Category:Technical Account Manager]]

SLOs for Customer Outcomes

BrettFullmer — Tue, 01 Sep 2026 17:48:05 GMT

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

← Older revision		Revision as of 17:48, 1 September 2026
Line 5:		Line 5:
	Vague goals ("delight the customer," "drive adoption") aren't SLOs — they can't be measured or missed. Real SLO candidates:		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."		* '''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."		* '''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. ~~The 2025 SaaS Capital benchmark~~ for ~~private B2B SaaS at~~ $~~25–50K~~ ACV: median 102%, top quartile ~~111~~%.		* '''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.		* '''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.

Line 18:		Line 18:
	==The error budget idea, applied to CS==		==The error budget idea, applied to CS==

	In SRE~~, the~~ error budget is the ~~amount~~ of unreliability you're allowed to spend before ~~you have to stop~~ shipping features and ~~fix~~ reliability instead. 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 forces the conversation before it becomes a crisis.		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==		==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.		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:Customer Success Manager]]
	[[Category:Technical Account Manager]]		[[Category:Technical Account Manager]]

Observability (Customer Health Scoring)

BrettFullmer — Tue, 01 Sep 2026 17:45:45 GMT

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

← Older revision		Revision as of 17:45, 1 September 2026
Line 10:		Line 10:
	* '''Commercial signal''' — contract terms, upcoming renewal date, prior expansion or contraction history.		* '''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.		* '''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 vs. lagging==
Line 40:		Line 44:

	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]].		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 Success Manager]]
	[[Category:Customer Engineering]]		[[Category:Customer Engineering]]

CSM vs TAM vs Customer Engineer

BrettFullmer — Tue, 01 Sep 2026 17:07:17 GMT

Publish CSM vs TAM vs Customer Engineer page

New 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

BrettFullmer — Tue, 01 Sep 2026 17:05:47 GMT

Publish Customer Lifecycle Stages page

New 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)

BrettFullmer — Tue, 01 Sep 2026 17:04:21 GMT

Publish The Postmortem (Churn and Save Retros) page

New 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

BrettFullmer — Tue, 01 Sep 2026 17:03:07 GMT

Publish Incident Response for At-Risk Accounts page

New 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

BrettFullmer — Tue, 01 Sep 2026 17:01:40 GMT

Publish The Confirm Gate page

New 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

BrettFullmer — Tue, 01 Sep 2026 17:00:16 GMT

Publish The Play Library page

New 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

BrettFullmer — Tue, 01 Sep 2026 16:58:42 GMT

Publish SLOs for Customer Outcomes page

New page

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."
* '''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. The 2025 SaaS Capital benchmark for private B2B SaaS at $25–50K ACV: median 102%, top quartile 111%.
* '''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==

In SRE, the error budget is the amount of unreliability you're allowed to spend before you have to stop shipping features and fix reliability instead. 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 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.

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

Observability (Customer Health Scoring)

BrettFullmer — Tue, 01 Sep 2026 16:57:07 GMT

Publish Observability (Customer Health Scoring) page

New 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

BrettFullmer — Tue, 01 Sep 2026 16:55:27 GMT

Publish The Playbook hub page

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

User:BrettFullmer

BrettFullmer — Tue, 01 Sep 2026 16:52:55 GMT

User account BrettFullmer was created

MediaWiki:Common.js

Brett — Fri, 21 Aug 2026 19:41:46 GMT

Add loop attribute, swap in the upgraded 25s video

← Older revision		Revision as of 19:41, 21 August 2026
Line 44:		Line 44:
	if ( !placeholder ) return;		if ( !placeholder ) return;
	placeholder.innerHTML =		placeholder.innerHTML =
	'<video controls preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" style="max-width:728px;width:100%;height:auto;">' +		'<video controls loop preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" style="max-width:728px;width:100%;height:auto;">' +
	'<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">' +		'<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">' +
	'Your browser does not support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.' +		'Your browser does not support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.' +
	'</video>';		'</video>';
	}() );		}() );

MediaWiki:Common.css

Brett — Fri, 21 Aug 2026 19:20:14 GMT

Style video frame

@@ Line 476: / Line 476: @@
 .vector-pinnable-element {
      background-color: var(--bf-card) !important;
+}

MediaWiki:Common.js

Brett — Fri, 21 Aug 2026 19:19:39 GMT

Inject build-flow video via JS

@@ Line 38: / Line 38: @@
 		} );
 	} );
 }() );

Spacelift

Brett — Fri, 21 Aug 2026 19:18:11 GMT

Use JS-injected video placeholder (raw video tag gets sanitized)

← Older revision		Revision as of 19:18, 21 August 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	This page documents how the [[Main Page\|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.		This page documents how the [[Main Page\|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

			== Watch it happen ==

			Brett sketches the architecture, MAC turns it into OpenTofu config, Spacelift plans it and waits for a human to confirm before anything touches AWS. That's the whole loop:

			<div class="wiki-video-frame" id="wiki-video-spacelift-build"></div>

	== Why it exists ==		== Why it exists ==

MediaWiki:Common.css

Brett — Fri, 21 Aug 2026 18:41:26 GMT

Broad safety net: force sidebar columns transparent

Show changes

MediaWiki:Common.js

Brett — Fri, 21 Aug 2026 17:10:06 GMT

Fix logo image sizing

← Older revision		Revision as of 17:10, 21 August 2026
Line 5:		Line 5:
	header.innerHTML =		header.innerHTML =
	'<div class="bf-wrap">' +		'<div class="bf-wrap">' +
	'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="">Brett Fullmer</a>' +		'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="" width="24" height="24">Brett Fullmer</a>' +
	'<div class="bf-mobile-actions">' +		'<div class="bf-mobile-actions">' +
	'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +		'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +

MediaWiki:Common.js

Brett — Fri, 21 Aug 2026 17:04:27 GMT

Inject matching masthead with hamburger

New page

/* Inject a masthead matching brettfullmer.com's header, with a working hamburger menu. */
( function () {
var header = document.createElement( 'header' );
header.id = 'bf-masthead';
header.innerHTML =
'<div class="bf-wrap">' +
'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="">Brett Fullmer</a>' +
'<div class="bf-mobile-actions">' +
'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'<button class="bf-toggle" aria-label="Toggle menu" aria-expanded="false">' +
'<span></span><span></span><span></span>' +
'</button>' +
'</div>' +
'<nav class="bf-links" id="bf-nav-links">' +
'<a href="https://brettfullmer.com/#about">What I Do</a>' +
'<a href="https://brettfullmer.com/#experience">Experience</a>' +
'<a href="https://brettfullmer.com/#sabbatical">AI Lab</a>' +
'<a href="https://brettfullmer.com/blog/">Blog</a>' +
'<a href="/wiki/Main_Page" class="bf-current">Wiki</a>' +
'<a class="bf-cta bf-cta-desktop" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'</nav>' +
'</div>';

document.body.insertBefore( header, document.body.firstChild );

var toggle = header.querySelector( '.bf-toggle' );
var links = header.querySelector( '.bf-links' );
toggle.addEventListener( 'click', function () {
var isOpen = links.classList.toggle( 'open' );
toggle.classList.toggle( 'open', isOpen );
toggle.setAttribute( 'aria-expanded', isOpen ? 'true' : 'false' );
} );
links.querySelectorAll( 'a' ).forEach( function ( a ) {
a.addEventListener( 'click', function () {
links.classList.remove( 'open' );
toggle.classList.remove( 'open' );
toggle.setAttribute( 'aria-expanded', 'false' );
} );
} );
}() );

MediaWiki:Common.css

Brett — Fri, 21 Aug 2026 17:04:26 GMT

Match site header/branding

New page

/* ===== Fullmer Wiki: match brettfullmer.com brand ===== */

@font-face {
font-family: "Alfa Slab One";
src: url("/fonts/AlfaSlabOne-Regular.ttf") format("truetype");
font-weight: 400;
font-display: swap;
}

@font-face {
font-family: "Oswald";
src: url("/fonts/Oswald.ttf") format("truetype");
font-weight: 200 700;
font-display: swap;
}

:root {
--bf-paper: #f2e8d2;
--bf-paper-2: #eaddbd;
--bf-card: #f8f0dc;
--bf-ink: #191410;
--bf-ink-soft: #4a3f33;
--bf-muted: #7a6b58;
--bf-red: #c9342a;
--bf-mustard: #e0a92e;
--bf-teal: #2f7f74;
--bf-slab: "Alfa Slab One", "Rockwell", serif;
--bf-cond: "Oswald", "Arial Narrow", sans-serif;
--bf-serif: Georgia, "Times New Roman", serif;
}

/* ---------- Custom masthead (injected by Common.js) ---------- */
#bf-masthead {
position: sticky;
top: 0;
z-index: 200;
background: var(--bf-paper);
border-bottom: 3px solid var(--bf-ink);
box-shadow: 0 3px 0 rgba(25, 20, 16, 0.12);
font-family: var(--bf-cond);
}

#bf-masthead .bf-wrap {
max-width: 1100px;
margin: 0 auto;
padding: 0 24px;
display: flex;
justify-content: space-between;
align-items: center;
height: 66px;
position: relative;
}

#bf-masthead .bf-name {
font-family: var(--bf-slab);
font-size: 19px;
color: var(--bf-ink);
text-decoration: none;
display: flex;
align-items: center;
}

#bf-masthead .bf-name:hover { color: var(--bf-red); }

#bf-masthead .bf-name img {
width: 24px;
height: 24px;
margin-right: 9px;
}

#bf-masthead .bf-links {
display: flex;
gap: 24px;
align-items: center;
}

#bf-masthead .bf-links a {
color: var(--bf-ink-soft);
font-family: var(--bf-cond);
font-size: 14px;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 1.5px;
text-decoration: none;
}

#bf-masthead .bf-links a:hover,
#bf-masthead .bf-links a.bf-current { color: var(--bf-red); }

#bf-masthead .bf-cta {
font-family: var(--bf-cond);
font-size: 14px;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 1.5px;
background: var(--bf-red);
color: var(--bf-paper) !important;
border: 2px solid var(--bf-ink);
padding: 8px 18px;
border-radius: 6px;
box-shadow: 3px 3px 0 var(--bf-ink);
text-decoration: none;
transition: transform 0.15s, box-shadow 0.15s;
}

#bf-masthead .bf-cta:hover { transform: translate(-1px, -1px); box-shadow: 4px 4px 0 var(--bf-ink); }

#bf-masthead .bf-mobile-actions { display: none; align-items: center; gap: 12px; }

#bf-masthead .bf-toggle {
display: none;
flex-direction: column;
justify-content: center;
gap: 5px;
width: 32px;
height: 32px;
background: none;
border: none;
padding: 0;
cursor: pointer;
}

#bf-masthead .bf-toggle span {
display: block;
width: 100%;
height: 3px;
background: var(--bf-ink);
border-radius: 2px;
transition: transform 0.2s ease, opacity 0.2s ease;
}

#bf-masthead .bf-toggle.open span:nth-child(1) { transform: translateY(8px) rotate(45deg); }
#bf-masthead .bf-toggle.open span:nth-child(2) { opacity: 0; }
#bf-masthead .bf-toggle.open span:nth-child(3) { transform: translateY(-8px) rotate(-45deg); }

@media (max-width: 680px) {
#bf-masthead .bf-mobile-actions { display: flex; }
#bf-masthead .bf-toggle { display: flex; }
#bf-masthead .bf-links .bf-cta-desktop { display: none; }

#bf-masthead .bf-links {
position: absolute;
top: 66px;
left: 0;
right: 0;
flex-direction: column;
align-items: stretch;
gap: 0;
background: var(--bf-paper);
border-bottom: 3px solid var(--bf-ink);
box-shadow: 0 3px 0 rgba(25, 20, 16, 0.12);
max-height: 0;
overflow: hidden;
opacity: 0;
pointer-events: none;
transition: max-height 0.25s ease, opacity 0.2s ease;
}

#bf-masthead .bf-links.open {
max-height: 500px;
opacity: 1;
pointer-events: auto;
}

#bf-masthead .bf-links a {
padding: 16px 24px;
border-bottom: 1px solid rgba(25, 20, 16, 0.1);
}
}

/* ---------- Recolor the wiki body itself ---------- */
body {
background-color: var(--bf-paper) !important;
color: var(--bf-ink) !important;
font-family: var(--bf-serif) !important;
}

.mw-page-container, .mw-body, #content {
background: transparent !important;
}

.mw-body {
background: var(--bf-card) !important;
border: 3px solid var(--bf-ink) !important;
border-radius: 10px !important;
box-shadow: 6px 6px 0 var(--bf-ink) !important;
padding: 30px 34px !important;
}

.mw-body h1, .mw-body h2, .mw-body h3 {
font-family: var(--bf-slab) !important;
font-weight: 400 !important;
color: var(--bf-ink) !important;
border-bottom-color: rgba(25, 20, 16, 0.2) !important;
}

.mw-body a, .vector-menu-content a { color: var(--bf-red) !important; }
.mw-body a.new { color: var(--bf-teal) !important; }

.vector-pinnable-header, .vector-menu-heading, #p-navigation h3, #p-tb h3 {
font-family: var(--bf-cond) !important;
text-transform: uppercase;
letter-spacing: 1px;
}

pre, .mw-highlight, code {
background: var(--bf-paper-2) !important;
border-color: var(--bf-ink) !important;
}

Main Page

Brett — Fri, 21 Aug 2026 17:00:42 GMT

Add self-maintaining index via DynamicPageList4

@@ Line 20: / Line 20: @@
 Remote Customer Success, Customer Engineering, or Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner — I've read that particular org chart before.
-== This wiki ==
+== Index ==
-If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post. Think of it as the deleted scenes, minus the awkward director's commentary.
+If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer. This section is generated automatically from page categories, so it stays accurate as new pages get added — no stale link list to maintain by hand.
 == Elsewhere ==

Spacelift

Brett — Fri, 21 Aug 2026 16:49:10 GMT

Link the how-to guide

← Older revision		Revision as of 16:49, 21 August 2026
Line 1:		Line 1:
	This page documents how the [[Main Page\|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[MAC]], the agent that did most of the hands-on work.		This page documents how the [[Main Page\|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

	== Why it exists ==		== Why it exists ==

How to Use Spacelift

Brett — Fri, 21 Aug 2026 16:48:52 GMT

Write how-to guide with illustrations

New page

[[File:Spacelift-howto-hero.jpeg|thumb|center|500px|Config in, plan reviewed, confirmed, applied.]]
A simple walkthrough of how infrastructure actually gets deployed with Spacelift — the same process used to build the [[Spacelift|labs documented here]]. Written for anyone who already knows what Infrastructure as Code is and wants to see how Spacelift specifically fits into that workflow. Seven steps, no step skipped, nothing applied without a human saying so.

== Step 1: Write your infrastructure as code ==

Describe what you want — a server, a network, a database — as config files (OpenTofu or Terraform) in a Git repository. This is the "shopping list," not the click-through-a-console approach. It's also the part that makes every future change reviewable, since it's just a diff in a file.

== Step 2: Create a Spacelift stack ==

Point Spacelift at that repository and branch. A "stack" is Spacelift's unit of infrastructure — one stack usually maps to one deployable piece of your system (a network, an app, a database tier).

== Step 3: Attach cloud credentials, scoped on purpose ==

Connect the stack to your cloud account. Worth doing deliberately here: automation/read-only access and actual deploy access don't have to be the same credential. Keeping them separate means a compromised or overly-curious tool can look, but can't touch.

== Step 4: Push a change ==

Commit and push. Spacelift picks it up automatically and runs a '''plan''' — a full preview of exactly what would change, added, or destroyed. Nothing has touched the real infrastructure yet.

== Step 5: Read the plan like it matters ==

[[File:Spacelift-howto-confirm.jpeg|thumb|right|280px|The gate that keeps a bad plan from ever reaching production.]]
This is the step people skip when they're in a hurry, and the step that saves you when you are. The plan shows every resource being created, changed, or destroyed — read it the way you'd read a contract before signing it.

== Step 6: Confirm ==

Only after a human clicks confirm does Spacelift actually apply anything to the real account. This is the whole point: plan and apply are two separate, deliberate actions, not one button that does both. It's the difference between "this happened" and "I meant for this to happen."

== Step 7: Check the run history any time ==

Every run — who triggered it, what changed, whether it was confirmed or rejected — stays in Spacelift's history. Weeks later, "why did this change" has an actual answer instead of a guess.

== Why it's worth the extra step ==

None of this is exotic. It's the boring, unglamorous discipline that turns "I hope this doesn't break something" into an actual guarantee — whether the thing pushing the change is a person or, as in [[MAC|this case]], an AI agent working with real credentials. The gate is the same either way, and that's exactly the point.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:Technical Account Manager]]

File:Spacelift-howto-confirm.jpeg

Brett — Fri, 21 Aug 2026 16:48:33 GMT

Brett uploaded File:Spacelift-howto-confirm.jpeg == Summary == How-to guide illustrations

New page

== Summary ==
How-to guide illustrations

File:Spacelift-howto-hero.jpeg

Brett — Fri, 21 Aug 2026 16:48:33 GMT

Brett uploaded File:Spacelift-howto-hero.jpeg == Summary == How-to guide illustrations

New page

== Summary ==
How-to guide illustrations

Spacelift

Brett — Fri, 21 Aug 2026 16:39:16 GMT

Add matching categories

← Older revision		Revision as of 16:39, 21 August 2026
Line 57:		Line 57:
	That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.		That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

	[[Category:AWS ~~Lab~~]]		[[Category:Infrastructure as Code]]
			[[Category:AWS]]
			[[Category:AI Agents]]

Main Page

Brett — Fri, 21 Aug 2026 16:38:51 GMT

Add humor, target keywords, add categories

← Older revision		Revision as of 16:38, 21 August 2026
(2 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	[[File:Brett-~~portrait~~.jpeg\|thumb\|right\|220px\|Brett Fullmer]]		[[File:Brett-cover-art.jpeg\|thumb\|right\|220px\|Brett Fullmer]]
	'''Brett Fullmer~~''' is~~ a Technical Account Manager with 20+ years in enterprise infrastructure and managed services — ~~technical authority~~, ~~human first~~.		Hi, I'm Brett Fullmer — a remote Technical Account Manager / Customer Success Manager with 20+ years in enterprise infrastructure and managed services. Long enough to have been the person a customer calls right after they've already tried turning it off and on again, and somehow still liked me afterward.

			These days I'm doing something a little different. Since 2024 I've been heads-down in an independent AI lab, building LLM-powered automation and AI agent frameworks for technical support and customer engineering — the kind of tooling I wish had existed earlier in my career. I'm not here to tell you AI is going to replace your job. I'm here to tell you it replaced the boring 60% of mine, and I'm still gainfully employable, so everybody can relax.

			Two decades of infrastructure experience, a career built on trust, and right now, a lab full of AWS servers I've built, broken, and rebuilt on purpose, in public, using Infrastructure as Code — because "trust me, it works" is not a deployment strategy.

	== Background ==		== Background ==

	Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line~~. That background is~~ the ~~foundation everything else here is built on top of~~.		Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line — not the one reading from a knowledge base article they've never actually run themselves.

	== Currently ==		== Currently ==

	Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan.		Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein, which is more than I can say for most Terraform I've inherited from other humans. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) — real AWS Infrastructure as Code, not a sandbox with training wheels — exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan on a pitch deck.

	The site's own tagline puts it plainly: '''building with AI, unapologetically.'''		The site's own tagline puts it plainly: '''building with AI, unapologetically.'''
Line 14:		Line 18:
	== What I'm looking for ==		== What I'm looking for ==

	Remote Customer Success / Customer Engineering / Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner.		Remote Customer Success, Customer Engineering, or Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner — I've read that particular org chart before.

	== This wiki ==		== This wiki ==

	If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post.		If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post. Think of it as the deleted scenes, minus the awkward director's commentary.

	== Elsewhere ==		== Elsewhere ==
Line 25:		Line 29:
	* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]		* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
	* [https://linkedin.com/in/brettfullmer LinkedIn]		* [https://linkedin.com/in/brettfullmer LinkedIn]

			[[Category:Technical Account Manager]]
			[[Category:Customer Success Manager]]
			[[Category:Customer Engineering]]
			[[Category:Enterprise Infrastructure]]
			[[Category:AI Agents]]
			[[Category:Infrastructure as Code]]
			[[Category:AWS]]
			[[Category:Remote Work]]

File:Brett-cover-art.jpeg

Brett — Fri, 21 Aug 2026 16:30:13 GMT

Brett uploaded File:Brett-cover-art.jpeg == Summary == MAD-cover-art style portrait

New page

== Summary ==
MAD-cover-art style portrait