
customer-health-score
Design, validate, and govern a composite customer health score - product usage and engagement signals combined into one weighted, normalized, decayed, banded account score that flags both churn risk and expansion readiness, backtested against real churn outcomes and recalibrated. Use whenever the user mentions a customer health score, health scoring model, account health, signal weighting, score bands, at-risk account flagging, churn risk score, expansion risk, or says "green accounts keep churning" - even if they never say "health score". Covers B2B account-level rollup and B2C/PLG continuous scoring. Do NOT use for discovering which indicators actually predict churn - use mbfinotti/revops-skills@customer-churn-signals instead.
- Installs
- 21.4K
- Last 24h
- +745
- Trending rank
- #464
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/mbfinotti/revops-skills --skill customer-health-score- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads customer-health-score automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
Customer Health Score
Design, validate, and maintain one composite score that tells a post-sale team which accounts are drifting toward churn and which are ready for an expansion conversation. In ChurnZero's 2025 Customer Revenue Leadership Study (~800 CS and post-sales leaders surveyed), 73% said their current health score does not reliably predict churn.
- Performative score. Someone picks ten metrics, weights them by intuition; CS ignores the result because it predicts nothing.
- Predictive score. Derives its weights from what churned accounts actually did before churning, then proves itself in backtest.
This skill owns the composition and validation that turns one into the other:
- Normalization
- Weighting
- Decay
- Banding
- Segment calibration
- Override governance
- Wiring every band to a play
Which indicators to feed it, and how predictive each one is, is discovery work owned by mbfinotti/revops-skills@customer-churn-signals. Treat signals here at the category level (product usage, relationship/engagement, support, commercial, sentiment) and take the discovered indicator list as input.
Draw on the field's named canon where it genuinely helps:
- Gainsight's DEAR framework (Deployment, Engagement, Adoption, ROI): a balanced-scorecard model of 4-6 weighted metric groups summed into bands. Gainsight cautions that weighting "is highly unique to each company".
- Lincoln Murphy's Success Potential: ties expansion to achieved health ("No Customer Success... No Expansion Revenue").
- RFM-style reads: recency, frequency, and depth of usage.
- Leading-vs-lagging split: adoption trend, sponsor engagement, and response-time trend lead; churn, NRR, and renewal rate only confirm afterward. Score the leading ones.
One composite score, or a separate expansion model:
- One composite, top band gates expansion (default). Already the score being built and validated; a second model costs a month to build and two validation loops to keep. Gating expansion plays on the top band is the dominant practitioner pattern: low bands trigger retention, the top band triggers expansion/advocacy motions.
- A separate expansion model. Justified only when expansion-specific inputs are systematically tracked; otherwise it is a second unvalidated score.
Only vendor case studies support the claim that high health causally predicts expansion; no rigorous published study does. Treat health as necessary but not sufficient for expansion: the top band earns an account the conversation, and fit, whitespace, and budget decide it.
B2B and B2C/PLG share most of the mechanics: per-seat normalization, trend-over-level, an action wired to every band, and the backtest loop are identical in both. Say so when asked. What genuinely differs:
- B2B. Rolls user-level signals up to account level with extra weight on champion/sponsor continuity: renewals hinge on the buying organization, not one user, and flat aggregate usage can hide a disengaged champion (the "silent churn" pattern). Risk concentrates around a renewal date, so weight renewal proximity inside the score.
- B2C/PLG. No CSM and no renewal cliff: scoring is continuous and system-driven, ownership sits with growth/product rather than CS ops, and an involuntary-churn layer (failed payments, dunning) belongs in the score because payment failures correlate with engagement decline.
Interview
Ask before designing. One question per message; offer multiple-choice answers when possible. Skip anything already answered.
- Which motion? (a) CSM-covered B2B with contract renewal dates, (b) PLG/self-serve continuous subscription, (c) B2C consumer subscription.
- How many accounts, and roughly how many churn events in the last 12-24 months? (Decides statistical weighting vs the rules-based cold-start path.)
- Which data sources are actually connected today - product usage data, engagement/meeting records, support system, billing? Rough coverage of each?
- Has signal discovery been done - is there an evidenced list of indicators that preceded past churn (see
mbfinotti/revops-skills@customer-churn-signals), or only a gut list? - Does a health score already exist? If yes: diagnose first or rebuild? (Diagnosis path: see Diagnosing a Broken Score.)
- What segments exist - enterprise vs SMB, onboarding vs mature? (A 70 that is healthy for enterprise is a red flag for an onboarding SMB; segment calibration is mandatory, not optional.)
- How many at-risk accounts can the team actually work per month? (The red band is sized to this, not to statistics.)
- Who owns the scoring logic, who acts on the score day-to-day, and who may override it?
- By what date must the score be live and acted on? (A hard date - a renewal cycle, a board review - promotes the rules-based proxy and the top two signal rungs; a distant date makes statistically fitted weights and a survey category affordable.)
- One-off win or compounding asset - this quarter's at-risk list, or a model that keeps getting better? (A one-off list drops decay, segment calibration, and the standing recalibration cadence; a compounding mandate promotes all three plus fitted weights.)
- What is the effort ceiling - analyst hours, whose data-engineering time, and how much manual logging CS will genuinely do? (Manual logging is what makes stakeholder-continuity signals real; if nobody will log, that category drops to whatever the CRM captures on its own.)
Build order
Build the score rung by rung, ranked by churn actually prevented per hour of analyst time - not by what is cheapest to wire, and not by what scores best in backtest. Effort here is analyst hours, data the product must already emit, ongoing re-fitting, and how legible the score stays to the people who must act on it: a score CSMs cannot reconstruct is expensive no matter how accurate it is.
- efficiency: usage/adoption > commercial/billing > support > stakeholder continuity > sentiment survey
- value (churn caught): stakeholder continuity > usage/adoption > support == commercial/billing > sentiment survey
- effort:
- usage/adoption and commercial/billing: near-zero - the product and billing system already emit the events.
- support: an hour to map tickets to rates and trends.
- stakeholder continuity: a standing job - humans must log meetings and sponsor changes for the input to stay true.
- sentiment survey: a day or two to stand up, plus a standing job to run - low response rates keep it unstable.
Support and commercial tie on value because each catches a blind spot the other cannot - escalation clusters, invoice disputes - and neither substitutes for the other.
Start from the top two rungs plus whatever discovery already evidenced, validate that, then add rungs.
What this order starves:
- Stakeholder continuity. The highest-value input, the one that catches silent churn, and the worst ratio because it depends on humans logging contact. Promote it to rung one in any B2B book with renewal dates, or the moment one green account churns after a champion left - the continuity rule in step 5 makes it mandatory regardless of its ratio.
- Statistically fitted weights and a second, dedicated expansion model. Both lose every round on ratio and are still right eventually. Both need an account base large enough to fit and validate on its own outcomes (tens of churn events per segment), and both buy better signal once it exists.
This ordering is a default, not a law. It shifts with context and with who executes it - re-rank it against everything already known about the user before proposing it:
- A product already emitting rich usage telemetry locks usage at rung one for near-zero effort.
- A customer-success team of one demotes everything that needs manual logging and promotes automated usage and billing signals.
- Fewer than a hundred accounts takes fitted weights off the table entirely (see the cold-start path) and makes monthly CSM interview-validation the strongest check available.
Workflow
- Run the Interview; collect every answer before designing.
- Define the outcome before any signal talk. A score that predicts an undefined event cannot be validated.
- Churn event: non-renewal, cancellation, or no reactivation within N days for B2C.
- Entity level: account for B2B, subscriber for B2C.
- Prediction window: what the score claims to predict, e.g. churn within 90 days.
- Take the indicator list as input - from the customer-churn-signals discovery work or, failing that, the user's best-evidenced candidates - and group it into the categories in references/signal-categories.md. Audit data coverage per category, then build in the Build order ranking above, re-ranked against the user's answers. Never integrate everything at once, and drop any signal that could never trigger a play - if it can't trigger a play, it's a vanity signal.
- Normalize per references/signal-categories.md:
- Rate-normalize by seats/users (500 logins from 50 users is not 500 logins from 1,000 users).
- Read support and sentiment as trends, not counts.
- In B2B, roll user-level signals up to account level with champion/sponsor weighting.
- Weight per references/weighting-and-bands.md: derive weights from correlation with the defined outcome in the churned-vs-retained cohort, never from intuition. Cap every category so no single input can move an account across a band alone, and require at least one stakeholder-continuity input so no combination of usage signals can hold an account green after a champion departs.
- Add decay: every engagement-type signal drifts toward neutral as it ages, so silence reads as uncertainty instead of accumulated green. Score the trend and the level - a falling 75 is a worse account than a stable 60.
- Band: three bands, no more - more bands sound precise and add confusion. Size the red band to intervention capacity first, then improve the score until the same capacity catches more of the churn. Set segment-specific thresholds and weight overrides.
- Validate per references/validation-and-kpis.md: retro-score the historical cohort, use precision/recall (never raw accuracy - churn is class-imbalanced), and run the retro check on what churned accounts scored 60-90 days pre-churn. Iterate weights, decay, and thresholds until the pass floor in the spec section clears. Too few churn events → take the cold-start path in the same reference.
- Wire every band to a play with an owner and an SLA - a band change that triggers nothing is a report, not a health score. Define the override policy: any CSM may override with a mandatory reason code; overrides feed recalibration as labeled disagreements.
- Emit the spec (next section), pilot with a small group before full rollout, review score distribution and misses monthly for the first 90 days, then move to the standing recalibration cadence.
- If your harness has persistent memory, memorize the approved spec - categories, weights, bands, segment overrides, validation results, review date - so later recalibration and diagnosis runs start from it instead of re-interviewing.
The Health Score Spec
Deliver every engagement as this artifact - a document the user can hand to CS ops, RevOps, and the CSM team. Fully worked versions live in references/worked-examples.md.
HEALTH SCORE SPEC - <company/product>, <date>, v<n>
Outcome : churn event definition | entity level | prediction window
Segments : list + per-segment weight/threshold overrides
Signals : category -> weight | inputs (from discovery) | normalization | evidence (outcome correlation)
Decay : per-category drift-to-neutral rule and window
Rollup (B2B) : user->account aggregation method, champion/sponsor weighting
Bands : 3 bands -> score ranges -> wired play, owner, SLA per band
Expansion : top-band gate + the non-health conditions (fit, whitespace, contract timing)
Overrides : who may override, reason codes, how overrides feed recalibration
Validation : backtest window | red-band churn multiple vs base rate | % churned accounts
below green at 60-90 days pre-churn | precision/recall at the red threshold
Triggers : band-change alert -> task/workflow; renewal-proximity weighting (B2B)
Governance : logic owner | acting owner | data owner | review cadence | change log location
Three rules about the spec itself:
-
Every weight carries its evidence. "Adoption-depth trend 35%: churned accounts declined here in 7 of 9 pre-churn quarters analyzed" is reviewable. A bare percentage is folklore. If a weight has no outcome evidence yet, label it a provisional hypothesis with a validation date.
-
The spec has a pass threshold. No standards body publishes a numeric ship-it bar for health scores; these floors are this skill's convention, set because a model that clears less will not survive live noise or earn CSM trust.
- In backtest, the red band must churn at at least 3x the portfolio base rate.
- At least two-thirds of accounts that actually churned must have sat below green 60-90 days before churning.
- No more than ~80% of the book may sit green (a documented practitioner red flag if crossed), independent of backtest results.
Iterate until all three hold. Refuse to ship a score that reads as decoration.
-
The score is versioned and owned. Diffuse ownership produces a score that changes meaning per reader: CS wants adoption, RevOps wants CRM activity, product wants feature usage, and everyone gets a field.
- One owner for the logic (CS ops/RevOps).
- CSMs act and override.
- One data owner.
- Every change logged and announced.
Diagnosing a Broken Score
When the user arrives with a running score ("green accounts keep churning", "the team ignores it"), diagnose every symptom, then fix in the order below - not in the order the symptoms were reported, and not worst-fault-first. The ratio is churn actually prevented per hour, and the deadliest fault is rarely the one that pays back first.
- efficiency: wire band->play > normalize per seat > add decay > cap categories + continuity input > noise guard == ticket-read fix > segment calibration > re-derive weights from the cohort > qualify the expansion gate
- value: re-derive weights == wire band->play > cap categories + continuity input > normalize per seat == add decay > segment calibration > noise guard == ticket-read fix > qualify the expansion gate
- effort:
- decay and the noise guard: near-zero.
- normalization, caps, the ticket read, and the expansion gate: an hour each.
- segment calibration: a day or two of analysis.
- the cross-team coordination that wires plays to owners and SLAs: a week.
- cohort re-derivation: a standing job, which also needs churned-account history the book may not have.
Ties justified:
- An unacted score and a wrongly-weighted one both prevent zero churn - they tie on value and split on effort.
- Normalization and decay tie because each removes one systematic misread of the same book.
- The noise guard and the ticket read are the same trailing-trend machinery applied twice, each buying back a different flavor of CSM distrust.
The table is ordered to match.
| Symptom | Likely fault | Fix |
|---|---|---|
| CSMs ignore or silently distrust the score | No wired plays; no gated override; unexplainable weights | Wire band->play; allow overrides with reason codes; publish the weight evidence |
| Large accounts always look sick (or always healthy) | Raw counts instead of rates | Normalize per seat/user; benchmark against similar-size accounts |
| Score rarely moves; most of book green | No decay - old positive signals accumulate forever | Decay engagement signals toward neutral; recheck distribution monthly (>80% green = broken) |
| Champion left; account stayed green for weeks | Single-category dominance - usage alone can hold green | Cap category shares; require a stakeholder-continuity input that can pull the band down alone |
| Score flaps band-to-band weekly | Single-point noise treated as signal | Score trailing-window trends; require two consecutive readings before a band change fires |
| High-touch accounts flagged red on ticket volume | Ticket count read as risk | Rate-normalize tickets, read the trend; treat zero tickets as possible disengagement, not health |
| Same score means different things across accounts | One global model over unlike segments | Segment-specific weights and thresholds (enterprise vs SMB, onboarding vs mature) |
| Green accounts keep churning | Performative weights - intuition, not outcome correlation; missing relationship/sentiment inputs | Re-derive weights from the churned-vs-retained cohort; add a stakeholder-continuity input |
| Top-band accounts never expand | Health treated as sufficient for expansion | Gate expansion plays on top band, but qualify on fit, whitespace, and contract timing separately |
Re-rank this too: a book with no churned-account history has no cohort to re-derive from, so that rung leaves the list rather than sitting last (see the cold-start path).
Reference
- See references/signal-categories.md for how each signal category behaves inside a composite: normalization, trend windows, rollup, and per-category traps. Category mechanics only; indicator discovery lives in
mbfinotti/revops-skills@customer-churn-signals. - See references/weighting-and-bands.md for deriving weights from outcomes, caps, decay mechanics, banding, segment overrides, and the one-score-vs-two decision in full.
- See references/validation-and-kpis.md for the backtest procedure, precision/recall framing, pass floors, the cold-start path, KPIs, recalibration cadence, and override governance.
- See references/worked-examples.md for a CSM-covered B2B spec and a PLG/B2C spec worked in full, plus a plausible-looking broken score decomposed.
- See
mbfinotti/revops-skills@lead-scoringfor pre-sale scoring - lead scoring predicts who will buy; this skill predicts who will stay and grow. Different outcome, different model. - See
mbfinotti/revops-skills@sales-to-cs-handofffor the sales-to-CS transition where the first health baseline gets set. - See
mbfinotti/revops-skills@revenue-kpi-frameworkfor the org-wide metric tree this score reports into - the composite can serve as a leading input under the retention branch, and that skill sets which level owns it and what guardrail rides alongside it.
FAQ
What does the customer-health-score skill do?
Design, validate, and govern a composite customer health score - product usage and engagement signals combined into one weighted, normalized, decayed, banded account score that flags both churn risk and expansion readiness, backtested against real churn outcomes and recalibrated. Use whenever the user mentions a customer health score, health scoring model, account health, signal weighting, score bands, at-risk account flagging, churn risk score, expansion risk, or says "green accounts keep churning" - even if they never say "health score". Covers B2B account-level rollup and B2C/PLG continuous scoring. Do NOT use for discovering which indicators actually predict churn - use mbfinotti/revops-skills@customer-churn-signals instead.
How do I install customer-health-score?
Run npx skills add https://github.com/mbfinotti/revops-skills --skill customer-health-score in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/customer-health-score/ (personal) or .claude/skills/customer-health-score/ (project).
Which AI agents can use customer-health-score?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is customer-health-score safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains customer-health-score?
It is published by mbfinotti in mbfinotti/revops-skills. It has 21,373 recorded installs.
More from mbfinotti/revops-skills
revenue-kpi-framework
mbfinotti/revops-skills
Design the org-wide revenue KPI framework at the macro level - which metrics matter at each org level from board to IC, how they roll up through a reconciling metric tree with explicit math, who owns each branch, which guardrail counter-metrics ride alongside each owned number, and how the set is gated by company stage and business model. Use whenever the user mentions a revenue KPI framework, a metric hierarchy, a KPI tree, a North Star metric, driver metrics, guardrail counter-metrics, NRR, or which revenue metrics each org level should track - even if they never say "framework". Covers B2B and B2C. Do NOT use for writing the board report itself - use mbfinotti/revops-skills@revenue-reporting instead.
sales-pipeline-hygiene
mbfinotti/revops-skills
Run a periodic, checklist-based hygiene audit over an active pipeline snapshot - stale deals (no stage, close date, or amount change, not logged touches) flagged against segment-specific stage medians, close-date push-count anomalies, and missing forecast-critical fields - producing an exception list with a disposition per flagged deal, a remediation plan, and a pass threshold. Use whenever the user mentions pipeline hygiene, a stale deal audit, pipeline cleanup before a QBR, deals that keep pushing, a close date that keeps slipping, missing fields on deals, or "our pipeline is full of junk" - even if they never say "hygiene". Covers B2B and B2C/high-velocity/PLG. Do NOT use for rewriting stage definitions - use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
revenue-funnel
mbfinotti/revops-skills
Design a company's revenue funnel model from scratch, at the macro level - the stage set, the unit of analysis (lead, buying group, account), the model purpose (process vs planning vs forecast), the cohort-based conversion assumptions behind the plan, and the ownership handoffs between marketing, sales, and CS. Use whenever the user mentions funnel design, funnel stages, a funnel model, conversion rate assumptions, a bowtie model, a demand waterfall, MQL to SQL to opportunity definitions, or marketing-sales handoff design - even if they never say "funnel". Covers B2B and high-consideration B2C. Do NOT use for auditing an existing pipeline's stage definitions - use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
revops-kickoff
mbfinotti/revops-skills
Before starting any RevOps or Sales Ops task, and at the start of every session on an ongoing RevOps project, run this first - it routes the task to exactly one skill of the revops-skills collection or says plainly that none fits, and bootstraps or resumes the project's shared, versioned context artifact so the next session starts warm instead of cold, ending in a short-list plus an ordered skill chain. Run it even when the collection's other skills are already used daily - a new project is a new context. Also use whenever the user mentions a revops kickoff, a new RevOps project, a revops project start, revops or crm skill routing, a periodic RevOps check-in, a recurring RevOps review, "which revops skill do I need", or "where do I start with RevOps" - even if they never name a skill, and even if the request looks like it already belongs to one specific skill. Do NOT use for routing quota-carrying sales tasks - use mbfinotti/sales-skills@sales-kickoff instead.
pipeline-stage-definition-audit
mbfinotti/revops-skills
Audit existing sales pipeline stage definitions against buyer-verifiable milestones and flag the ones built on rep activity instead. Core test - does each stage exit criterion name something the buyer did, said, or agreed to, checkable by two managers independently? Adds stage aging, conversion decay, stage-skip rate, and close-date push diagnostics. Use whenever the user mentions stage definitions, stage exit criteria, stage inflation, stages named after rep activity ("demo scheduled", "proposal sent"), "our stages don't mean anything", or "why is everything stuck in one stage" - even if they never say "audit". Covers enterprise and high-velocity pipelines, B2B and B2C. Do NOT use for designing a funnel stage set from scratch - use mbfinotti/revops-skills@revenue-funnel instead.
sales-forecast-diagnostic
mbfinotti/revops-skills
Diagnose why an existing sales forecast is unreliable and recommend fixes - stage inflation and happy ears, sandbagging, deals without verifiable buyer evidence, stale or mass-pushed close dates, wrong forecast-category assignment, zombie and duplicate opportunities, late-created deals, manager roll-up overrides, and comp incentives that reward bias - separating data-quality from behavioral from genuine demand problems. Use whenever the user mentions forecast accuracy, a forecast miss, reps sandbagging, deals that keep slipping, "why did we miss the number", or "our commit is never right" - even if they never say "forecast". Covers B2B deal-based and B2C/high-volume. Do NOT use for pipeline coverage modeling - use mbfinotti/sales-skills@sales-pipeline-coverage-modeling instead.
Popular education & science skills
teach
mattpocock/skills
Teach the user a new skill or concept, within this workspace.
scaffold-exercises
mattpocock/skills
Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.
paper-context-resolver
lllllllama/rigorpilot-skills
Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default.
caveman-learn
juliusbrussee/caveman
Act on a Caveman learn report - review the ranked token sinks, apply cost-lowering fixes with per-edit consent, and report what those fixes returned. Use when asked to lower an agent's token cost, what caveman has saved, to trim a heavy CLAUDE.md, or to offload re-pasted context into cavemem.
gsap-plugins
greensock/gsap-skills
Official GSAP skill for GSAP plugins — registration, ScrollToPlugin, ScrollSmoother, Flip, Draggable, Inertia, Observer, SplitText, ScrambleText, SVG and physics plugins, CustomEase, EasePack, CustomWiggle, CustomBounce, GSDevTools. Use when the user asks about a GSAP plugin, scroll-to, flip animations, draggable, SVG drawing, or plugin registration.
teach-impeccable
pbakaus/impeccable
DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.