--- name: scoring-customer-health description: >- Builds a weighted 0-100 customer health score from adoption, engagement, outcome, support, and sentiment inputs, sets healthy/at-risk/critical thresholds, and back-tests the score against actual churn and renewal history before it is trusted. Use when the user says health score, customer health scoring, health scorecard, red-yellow-green accounts, DEAR framework, account risk score, "which accounts are at risk", "our health score is wrong", "recalibrate our scorecard", "what weights should we use", or asks how to segment scorecards by tier or lifecycle stage. Use this skill whenever the task is deciding what goes into a health score, how inputs are weighted, or whether the score actually predicts churn. Do NOT use for running the save play once an account is already flagged (see preventing-churn), for renewal forecasting or expansion sequencing (see planning-renewals-and-expansion), or for presenting health to a customer in a review (see running-executive-business-reviews). metadata: version: "1.0" --- # Scoring customer health Build one weighted, back-tested health score that predicts renewal and churn, and set the thresholds that trigger action. One job: score design, calibration, and validation. Acting on a flagged account, forecasting renewal dollars, and running the customer-facing review are out of scope. ## Scope check before you start Confirm three things exist before designing anything, because a score built on unavailable data is a scorecard nobody updates: - At least 4 quarters of renewal and churn outcomes to back-test against. - Product telemetry at the account level, not just company-wide aggregates. - A named owner who will refresh the score on a stated cadence. If back-test data does not exist, say so, ship the score as **provisional**, and schedule validation at 4 quarters. Do not present an unvalidated score as predictive. ## Workflow Copy this checklist into your reply and tick items as you complete them: ``` - [ ] 1. Frame the model (cadence, scale, segmentation) - [ ] 2. Select 4-6 inputs across the DEAR categories - [ ] 3. Define the per-input scoring rule (raw value -> 0-100) - [ ] 4. Assign weights totalling exactly 100 - [ ] 5. Set the three health bands - [ ] 6. Back-test against churn history; fix and re-test until it separates - [ ] 7. Wire thresholds to triggers and write the scorecard spec ``` **1. Frame the model.** Answer four framing questions before touching data, because these decisions determine everything downstream: how often the score refreshes (daily, weekly, or monthly), which metrics are in, whether all metrics carry equal weight, and whether each metric is data-derived or CSM opinion ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Use a numerical 0-100 scale rather than traffic lights, because a numerical scale "provides more detail" and supports thresholds and trend analysis ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). **2. Select inputs.** Choose 4-6 signals that correlate with success or risk ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Cover all four DEAR categories so the score is not pure usage telemetry: **D**eployment (license and feature activation), **E**ngagement (customer and decision-maker interactions), **A**doption (which features are actually used), **R**OI (outcomes achieved against the customer's stated goals) ([Gainsight Communities](https://communities.gainsight.com/predictive-health-scoring-321/build-a-foundational-health-scoring-framework-using-dear-26486)). Add support (ticket volume and resolution time) and sentiment (NPS/CSAT) as the friction and loyalty reads ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Judgment step — you choose the inputs. Decision criteria, in priority order: the signal must be (a) available for every account in the segment, (b) movable by a CSM action, (c) measured at least as often as the refresh cadence, (d) different from the other selected signals. Drop any input that fails (a) or (c); a partially-populated input silently biases scores toward accounts with better instrumentation. **3. Define the per-input scoring rule.** For each input, write an explicit mapping from raw value to a 0-100 sub-score with stated cut points. This is the step most teams skip, and the sources do not supply it — Gainsight does not state how raw usage, support, or sentiment data convert into metric scores. Write the mapping yourself and record it, because without it the same account scores differently depending on who builds the query. Use percentile-within-segment for continuous signals (DAU/MAU, tickets per seat) and milestone-completion for binary signals (SSO configured, integration live). For stickiness, anchor against segment norms rather than absolutes: average DAU/MAU is about **13% for SaaS overall** and roughly **40% for B2B SaaS** measured against workdays ([Gainsight](https://www.gainsight.com/essential-guide/product-management-metrics/dau-mau/)). For products with a Monday-Friday pattern use **DAU/WAU** instead, because the 7-day denominator has a shorter lag; for low-frequency products use WAU/MAU or MAU/QAU; for sporadic, necessity-driven products drop stickiness from the score entirely ([Gainsight](https://www.gainsight.com/essential-guide/product-management-metrics/dau-mau/)). **4. Assign weights.** Weights must sum to exactly 100, because otherwise band thresholds are not comparable across segments. Start from Gainsight's published example — usage 40%, support 25%, sentiment 20%, executive engagement 15% ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)) — and treat it as a starting hypothesis only. That weighting is explicitly an example, not a validated model; the source's own instruction is to derive weights from historical churn and renewal data ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Give greater weight to the metric matching the current strategic priority: when the company goal is driving feature usage, adoption carries more weight ([Gainsight Communities](https://communities.gainsight.com/predictive-health-scoring-321/build-a-foundational-health-scoring-framework-using-dear-26486)). **5. Set the bands.** Default to **Healthy 71-100 / At Risk 31-70 / Critical 0-30** ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Treat the 71 and 31 boundaries as hypotheses to be moved in step 6, the same as the weights. A 40-point At Risk band is too wide to drive action on its own, so pair it with score *trend* (see Gotchas). **6. Back-test, fix, and re-test.** This is the step that makes the score real. Non-negotiable procedure: - Compute the score as of 90 days before each renewal date for every account that renewed or churned in the last 4-8 quarters. - Build the confusion table: churned-and-scored-Critical/At-Risk (true positive), churned-and-scored-Healthy (false negative), renewed-and-scored-Critical (false positive). - Compute the churn rate within each band. **The score passes only when churn rate falls monotonically from Critical to At Risk to Healthy and the Critical band's churn rate is at least 3x the Healthy band's.** Below that separation the score is not predictive and must not be used for staffing or forecasting. - If it fails, change one thing at a time — first weights, then band boundaries, then input selection — and re-run the back-test. Only proceed to step 7 once it passes. - Record the false-negative accounts by name. Each one names a signal the score is missing, which is the highest-value input to the next revision. Set weights from historical data on what actually predicts churn and renewal, and re-test often as new products, journey stages, and segments appear ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). **7. Wire thresholds to triggers and write the spec.** Define thresholds in a rules engine so score adjustments fire automatically as behavior changes — for example, adoption dropping below a set level triggers immediate action ([Gainsight Communities](https://communities.gainsight.com/predictive-health-scoring-321/build-a-foundational-health-scoring-framework-using-dear-26486)). Configure manual score overrides for high-risk situations the telemetry cannot see, such as loss of the executive sponsor or a known product underuse ([Gainsight Communities](https://communities.gainsight.com/predictive-health-scoring-321/build-a-foundational-health-scoring-framework-using-dear-26486)). ## Segmenting the model Run separate scorecard models per segment and lifecycle stage, with automation to move an account between models as it progresses ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)). Emphasize these inputs: | Segment | Weight toward | |---|---| | Onboarding accounts | Onboarding milestone completion, login activation, support volume | | Mature accounts | ROI delivery, product depth, NPS/CSAT, upsell activity | | High-touch accounts | CSM sentiment, executive engagement, QBR cadence, roadmap alignment | | Digital / tech-touch accounts | In-app activity, knowledge base usage, feature adoption trend | ([Gainsight](https://www.gainsight.com/blog/customer-health-scores/)) ## Worked example Input: a mid-market B2B SaaS account, 120 licenses, weekly refresh, scored 90 days pre-renewal. ``` Deployment — 78/120 licenses activated (65%) -> 55 x 15% = 8.3 Adoption — DAU/WAU 0.31 vs segment median 0.44 -> 40 x 35% = 14.0 Engagement — 1 exec touch in 90d (target 3) -> 33 x 15% = 5.0 ROI — 1 of 3 kickoff success criteria met -> 33 x 20% = 6.6 Support — 14 tickets/quarter, 2 breached SLAs -> 45 x 10% = 4.5 Sentiment — CSAT 4.2/5, no NPS response this cycle -> 70 x 5% = 3.5 ``` Output: score **41.9 -> At Risk**; trend -19 points over two refreshes, which triggers the drop rule independently of the band. Dominant deficit is adoption (14.0 of a possible 35.0), so the diagnosis routes to an adoption gap, not a support or sentiment problem. ## Output format Produce a scorecard spec in this exact structure — downstream, an ops team implements it verbatim, so every cut point must be numeric and unambiguous. Wording inside cells is yours. ``` ## Health scorecard: / Refresh cadence: Scale: 0-100 Owner: | Input | DEAR category | Source system | Raw -> sub-score rule | Weight | |---|---|---|---|---| | | | | | % | ... | TOTAL | | | | 100% | Bands: Healthy -100 | At Risk - | Critical 0- Overrides: -> force band ### Back-test result (n = , window = ) | Band | Accounts | Churn rate | Renewal rate | Separation ratio (Critical churn / Healthy churn): Pass threshold: >=3.0 False negatives: -> missing signal: ### Triggers | Band or condition | Automated action | Owner | SLA | ``` If the back-test has not been run, replace that section with `STATUS: PROVISIONAL — not validated against churn outcomes` and state the date validation is scheduled. ## Gotchas - Weighted sub-scores must be normalized to the same 0-100 range before weighting. Gainsight does not state whether weighted values are normalized or whether weights must total 100, so teams routinely mix a 1-5 CSM sentiment rating with a 0-100 usage percentile and the sentiment input silently contributes almost nothing. - Score *level* is a worse predictor than score *trend*. An account that fell from 85 to 72 is still "Healthy" by band while it is actively churning; flag any drop of 15+ points in one refresh period regardless of the resulting band. - Health score and NPS measure different things and will disagree. A promoter contact at an account with collapsing usage is a single happy admin, not a healthy account; when they conflict, weight the telemetry and go verify with the economic buyer, not the responder. - Generic re-engagement email ("we haven't seen you in a while") inflates the adoption input without changing value delivered — it brings casual users back for a day and increases MAU more than DAU, which worsens the stickiness ratio ([Gainsight](https://www.gainsight.com/essential-guide/product-management-metrics/dau-mau/)). Exclude campaign-driven logins from the adoption input window. - CSM-sentiment inputs drift optimistic near renewal because the same CSM owns the number and the outcome. Cap opinion-based inputs at 20% of total weight, or require a second reviewer for any sentiment input above a Healthy threshold on an account whose usage is declining. - Aggregating usage at the contract level hides departmental collapse in multi-team accounts. Score the largest department separately when one team is more than half of seats, because that team's exit is the churn event. - Do not benchmark stickiness across categories. Ecommerce averages **9.8%** and finance **10.5%** DAU/MAU, versus **13%** for SaaS overall, and it is unrealistic to expect a ratio to move from 10% to 50% without changing the product's underlying utility ([Gainsight](https://www.gainsight.com/essential-guide/product-management-metrics/dau-mau/)). ## Calibrating targets Size the ambition of the score's thresholds against retention benchmarks so the model flags a population the team can actually work. Median GRR across more than 1,000 private B2B SaaS companies is **91%**, with a stated floor of **GRR at least 90%** for parity with peers ([SaaS Capital](https://www.saas-capital.com/wp-content/uploads/2025/09/RB32WS1-2025-B2B-SaaS-Retention-Benchmarks.pdf)). At 91% GRR roughly 9% of revenue churns annually, so a Critical band containing 25% of accounts is miscalibrated and will burn CSM capacity on false positives — tighten the band until Critical plus At Risk approximates the historical churn-plus-downsell population.