Account Health Over User Health

A company-wide retention number hides exactly which team is already walking out the door.

Net revenue retention is the number every board deck leads with, and it is close to useless for telling you what to do on Monday morning. One blended percentage averages an expanding team against a dying one inside the same account and reports the result as 104%. Somewhere inside that healthy-looking figure sits the exact seat cohort that already checked out, and the aggregate exists to bury it, not reveal it.

What to do: Stop scoring retention at the account level and start scoring it below the account, by team or seat cohort. Weight login recency, the share of core features each cohort actually touches, and seat-change velocity, then flag any cohort that drops below threshold a full quarter before the renewal call, not two weeks before it.

Why it works: Churn is decided team by team long before an invoice comes due. A blended average only tells you the account is in trouble after the decision has already been made and it is too late to change it.

Example: Uber never ran its marketplace off one city-wide supply number. It built and open-sourced H3, a hexagonal grid that splits every city into small local cells, and measures driver supply against rider demand cell by cell, triggering surge pricing and driver-reposition nudges exactly where one neighborhood runs thin while the rest of the city reads perfectly healthy. Gainsight, one of the bigger customer-success platforms built for exactly this problem, recommends the same fix for accounts: score health by functional owner, support, product, and adoption, each scored separately, instead of collapsing an account into one number.

Walk it through

There is no public page to point a browser at for this one. An account health score lives inside somebody's private CS tooling, tuned to their own usage data, so there is nothing to screenshot. The exercise below is the worked version I would run on my own account book, using a stand-in account to show the arithmetic.

1. Pick signals that predict a decision, not just activity.

Login recency, the share of core features a cohort has actually touched, and seat-change velocity beat raw session counts every time. A team can log in daily and never go near the feature that makes the product worth renewing.

2. Score every cohort inside the account, not the account as a whole.

Take one stand-in account. Northwind Logistics, 40 seats across three teams.

Ops team      22 seats   daily logins          6 of 8 core features   HEALTHY
Finance team  10 seats   2 logins this month   1 of 8 core features   AT RISK
Exec team      8 seats   0 logins in 45 days   0 of 8 core features   AT RISK

3. Blend it back into one number and watch it lie to you.

Ops added four seats this quarter, so Northwind's account-level NRR reads 104% this quarter. Two of the three teams inside it are already gone in every way that matters, and the blended figure says everything is fine.

4. Set the trigger a full quarter out, and route it to a person, not a dashboard.

An "at risk" cohort flagged the week of the renewal call is a postmortem. The same flag three months out is a save. Send it to the CSM who actually owns the relationship with Finance and Exec, not the AE who only ever talks to Ops.

The read

• The aggregate always lags the account. A blended retention number only moves after enough accounts have already made up their minds, the same way a city-wide supply number only moves after individual neighborhoods have already gone thin.
• The imbalance is local before it is visible. A team stops logging in weeks before anyone even schedules the renewal conversation, and a company-wide number buries that team inside everyone else's activity.
• Predictive scoring only works at the resolution where the behavior happens. Uber's grid is a neighborhood, not a city. Yours is a seat cohort or a team, not the account, and definitely not the whole book of business.

Steal it

Run this on your own accounts this week. Pull every account with more than one team or more than ten seats, and split the usage data by cohort before you look at anything blended. Score login recency, feature depth, and seat-change velocity for each cohort separately, monthly at minimum and weekly for whatever ARR line your CS team can actually sustain that cadence on. The account that reads healthy at the top while hiding a red cohort underneath is the renewal that blindsides you, and the entire point of scoring below the account level is to stop getting blindsided by it.

Defend the same way from the other side. If a vendor's account team ever calls you about "declining usage," ask which team or seat cohort actually triggered the flag before you accept the story that your whole company disengaged. And if you are the one building the scoring system, do not let one loud, happy admin cohort flatter the account's number while three quiet teams stop logging in underneath it. That gap between the top-line score and the cohort feeding it is exactly what this method exists to catch.

Gotchas

• Cohort-level scoring needs cohort-level data. Most product analytics setups tag events by user, not by team or department. You will likely need to add that tagging before any of this works at all.
• One power user can flatter a whole cohort. Weight for breadth of adoption across a cohort, not depth from one enthusiast, or a single champion hides nine silent teammates.
• Honest caution: a health score is a proxy, not a verdict. Uber's grid rebalances on real dispatches every few seconds. Your account score rebalances whenever a human checks it, often no faster than once a quarter. Treat a red flag as a reason to make the call, not as proof the account is already lost.