Which accounts are quietly stuck?
A health score is a claim about accounts you are not talking to. It is only as good as the usage behind it.
Two ways the list lies to you.
One costs your team a week on accounts that were never at risk. The other drops the at-risk accounts off the list, and a shorter list reads as good news.
Low usage is the signal. That is the whole mechanism, so anything that stops usage being recorded looks identical to an account going quiet.
The first way is loud. A core action stops being recorded, every account that depends on it drops at once, and your team spends the week on accounts that were never at risk.
The second way is silent, and it is the one that costs you. If a detail sent with the usage, something like plan tier, stops arriving, those accounts do not score badly. They fall out of the segment and off the list entirely. A shorter list looks like good news. That is the churn you do not see coming: not an account you scored wrong, an account you stopped scoring.
| How it fails | What you see |
|---|---|
| Loud | A core action stops being recorded. Every account that depends on it drops at once. |
| Quiet | One account stops being recorded. It looks exactly like an account going quiet. |
Nothing stops firing. The list just gets shorter.
The two enterprise accounts about to churn stay invisible for a quarter, and the event volume never moves.
Say an update stops sending plan_tier with a usage signal. The signal keeps firing and the volume is unchanged, so nothing looks broken.
But the health model segments by plan, and enterprise accounts now arrive with no tier. They fall out of the enterprise segment, off the at-risk list, and the two that were about to churn are invisible for a quarter.
- discoveryDiscoveryAttention and consideration through signupCustomer created
Customers added to the register and available for order processing.
public.customers - onboardingOnboardingIntegrations, settings, initial setupFirst order received
Customers with at least one newly received order awaiting production.
public.orders - engagementEngagementRepeat usage and feature depthOrder shipped
Orders that completed fulfilment and have been marked as shipped.
public.orders - retentionRetentionContinuous activity, renewals, habit lock-inInvoice paid
Invoices settled, the point where revenue is realised rather than booked.
public.invoices - expansionExpansionPaid upgrade, additional seats, premium featuresInvoice issued
Customers with an open or sent invoice representing a billable order.
public.invoices
Missing details get caught with the change that drops them.
Describe what keeps accounts healthy in plain language and you get back the signals and fields it takes to measure it, to review before anything is saved.
A dropped field is one of the four things the check looks for, and it is the one review is worst at, because the call is still there and still runs.
When you have a theory about what keeps accounts healthy, describe it in plain language and Skene drafts the measurement plan: the outcome, the questions the data has to answer, and the signals and fields that must exist to answer them. You review the draft before anything is saved.
The flag is one signal. The fields under it are what keeps the account on the list.
Write the rule down as a plan and verification runs against it before anything is wired up: the event that raises the flag, and every field the segment reads once it is raised. Each one comes back ready or missing, so a field that would quietly shrink the list is named while it can still be added.
days_since_last_order never arrives, the flag still fires and the account still falls off the list.You decide
What healthy means, and which fields your segments depend on.
Engineering does
A specific line and a fix they can read. Nothing about your health model.