Customer Success Playbooks skill for Codex

Health scores that would have predicted churn. Codex designs customer success operations from your account, usage and churn data: coverage tiers, onboarding success plans built around a measurable first-value event, a weighted health score that is back-tested against last year's renewals before anyone relies on it, trigger-based plays with owners and deadlines, a renewal timeline starting 120 days out, and customer business review templates.

  • Business & Operations
  • $customer-success-playbooks
  • 159 lines
  • 2 files
  • ~1,800 tokens
  • MIT
  • Updated

Install

curl -fsSL codexskills.dev/install.sh \  | sh -s -- customer-success-playbooks

Installs to ~/.agents/skills/customer-success-playbooks/ for every project on this machine.

104-line POSIX script. No sudo, no telemetry. Read install.sh

Use it in Codex

Start a prompt with $customer-success-playbooks, or pick it from /skills. You can also just describe the task: Codex reads the description below and loads the playbook when your request matches.

What Codex reads before loading it

Designs customer success playbooks for B2B SaaS - segmentation by coverage model, onboarding to first value with success plans, account health scores built from usage, adoption, support, sentiment and commercial signals and back-tested against real churn, trigger-based risk and expansion plays, a renewal timeline from 120 days out, and customer business reviews. Use when asked to build a health score, write CS playbooks, plan customer onboarding, set up a renewal process, prepare a customer QBR or EBR, or reduce churn.

Use it when

  • Churn surprises the team at renewal time
  • You need a health score or want to check whether the current one works
  • Customer onboarding takes too long to reach value
  • Formalising renewals, expansion and customer business reviews

Use something else when

How to check the result

The health score is back-tested on past renewals with recall and precision reported, and every play has a trigger, owner, deadline and exit criteria.

The mistake it prevents

Rolling out a health score built on gut-feel weights that was never checked against which accounts actually churned.

~/.agents/skills/customer-success-playbooks/SKILL.md

--- name: customer-success-playbooks description: Designs customer success playbooks for B2B SaaS - segmentation by coverage model, onboarding to first value with success plans, account health scores… license: MIT ---

Customer success works when every account has a clear next action: new customers reach first value on a known timeline, risk is spotted from data weeks before the renewal, and renewals and expansions follow a calendar rather than a scramble. A health score is only useful if it would have predicted last year’s churn.

Workflow

  1. Gather data: account list with ARR, plan, renewal dates, CSM owner; product usage events; support tickets; NPS/CSAT; billing status; churned and expanded accounts from the last 12-24 months with reasons.
  2. Segment accounts into coverage tiers.
  3. Define the onboarding journey and the first-value milestone.
  4. Build the health score and back-test it.
  5. Write trigger-based plays (risk, expansion, advocacy).
  6. Set the renewal timeline and business review cadence.
  7. Instrument: where each signal lives (CRM, CS platform, warehouse) and who acts on it.

Customer-facing emails, in-app messages and CRM updates are actions on the user’s systems: draft them, and execute or send only with explicit approval.

Segmentation

TierTypical criteriaCoverage
High touchTop ARR accounts or strategic logosNamed CSM, monthly cadence, executive business reviews
Mid touchMid ARRPooled or named CSM with larger book, quarterly check-ins, triggered outreach
Tech touchLong tail, self-serveAutomated onboarding, in-app guidance, email sequences, community; humans on triggers only

Set ARR thresholds from the actual distribution and CSM capacity (book size per CSM varies widely by product complexity; derive it from hours per account per month).

Onboarding to first value

  • Define first value per product as an observable event: “first report shared with a teammate”, “first 100 invoices synced”. Measure time to first value (TTFV).
  • Kickoff (high/mid touch): confirm the customer’s goals, success criteria, stakeholders (champion, executive sponsor, admins), timeline, and technical requirements.
  • Success plan:
# Success plan - <Account>
Customer goals: <1-3 measurable business outcomes, in their words>
First value milestone: <event> by <date>
Stakeholders: champion <name>, sponsor <name>, admin <name>
| Milestone | Owner (us / them) | Due | Status |
|---|---|---|---|
| SSO configured | Customer IT | 11-10 | |
| Data import complete | CSM + customer admin | 11-14 | |
| First workflow live for 1 team | Champion | 11-21 | |
Risks: <e.g. IT capacity, competing project>
  • Escalate when a milestone is more than a week late; onboarding stalls are the strongest early churn signal.

Health score

Build from a few signals that are available for every account and plausibly cause retention, then test them.

ComponentExample signalExample weight
Usage depthWeekly active users / licensed seats, last 30 days30%
Adoption breadthKey features used out of the 4-5 that predict retention20%
SupportOpen high-severity tickets, ticket trend, CSAT15%
SentimentNPS or CSM pulse, champion engagement15%
RelationshipExecutive sponsor identified and engaged in last 90 days10%
CommercialPayment status, contraction requests, discount dependency10%

Score each component 0-100 with explicit bands, then weight. Example usage band: 0 if under 20% seat utilisation, 50 at 20-50%, 100 above 50%. Map totals to Green (70+), Yellow (40-69), Red (under 40), and allow a CSM override only with a written reason and expiry date.

Back-test before rollout:

  1. Compute the score for every account as it stood 90-120 days before its renewal over the past year (or as close as the data allows).
  2. Compare to outcomes (renewed, contracted, churned).
  3. Check: what share of churned accounts were Red or Yellow beforehand (recall), and what share of Red accounts actually churned (precision).
  4. Drop or reweight components that do not separate churned from retained accounts. A simple score that predicts beats a complex one that does not.

Typical SQL shape for the usage component (warehouse with an events table):

select a.account_id,
       count(distinct e.user_id) filter (where e.occurred_at >= now() - interval '30 days')::numeric
         / nullif(a.licensed_seats, 0) as seat_utilisation
from accounts a
left join events e on e.account_id = a.account_id
group by a.account_id, a.licensed_seats;

Trigger-based plays

TriggerPlayOwnerWithin
Health drops to RedDiagnose (usage, tickets, stakeholders), call champion, agree a recovery planCSM5 business days
Champion leaves (email bounce, LinkedIn change, CRM update)Identify new champion, re-onboard, inform sponsorCSM10 business days
Seat utilisation under 30% for 60 daysAdoption workshop, admin trainingCSM / tech touch email2 weeks
Usage above 90% of plan limitsExpansion conversationCSM + AE2 weeks
Repeated severity-1 ticketsSupport escalation review, exec apology if warrantedSupport lead + CSM1 week
NPS promoter (9-10)Ask for review, reference or case studyCSM / marketing2 weeks

Each play: entry criteria, steps, message templates, exit criteria, and how the outcome is logged.

Renewal timeline

Days before renewalAction
120Review health, usage and value delivered; flag risks; agree renewal strategy with AE
90Business review with customer showing outcomes vs success plan; discuss next year’s goals
60Send renewal proposal (pricing, terms, expansion options); identify signer and procurement steps
30Resolve open terms; escalate stuck renewals to leadership
0Signed; update CRM and success plan for the new term

Auto-renewal notice windows in contracts can be 60-90 days; check them and start earlier if needed.

Customer business reviews (QBR / EBR)

Structure: their goals restated, outcomes achieved with their data, adoption and usage trends, support summary, roadmap items relevant to them, recommendations, goals and success plan for next period, asks (from both sides). Lead with their business results, not your feature list. Internal quarter reviews belong to okr-reviews.

Churn analysis

For each churned or contracted account record: primary reason (from a fixed list such as product gap, low adoption, budget, acquired/shut down, competitor, poor experience), whether health predicted it, and what play ran. Review quarterly; feed product gaps to product with ARR attached.

Gotchas

  • Health scores built on opinion (CSM gut feel) with no back-test; they look scientific and predict nothing.
  • Counting logins as engagement; measure the actions that deliver value.
  • Treating all accounts the same; tech-touch accounts drown CSMs and high-value accounts get neglected.
  • Starting renewal conversations at 30 days, after budgets were set.
  • Expansion pitches to accounts with open severity-1 issues.

Output

Segmentation rules, onboarding journey and success plan template, health score definition with back-test results, play library, renewal calendar, business review template, and churn reason taxonomy.

What the zip contains

SKILL.md plus the interface file below. Nothing runs on install.

agents/openai.yamlgenerated from this page

Gives the Codex app a display name, a one-line description and a starter prompt for this skill.

interface:
  display_name: "Customer Success Playbooks"
  short_description: "Health scores that would have predicted churn"
  default_prompt: "$customer-success-playbooks Build an account health score from our usage and support data and test it against last year's churn"

About this skill

Written and maintained by the Codex Skills editors to the same editorial standard as every skill here: a selective description, a real workflow, known pitfalls and a way to verify the work. First published , last updated . MIT licensed. Something wrong or out of date? Tell us.

esc