Customer health
Customer health is computed from Events and Entitlement use, never typed in, and it moves rescue, expansion and Success Manager Tasks.
Customer health is computed from what a Customer does, never typed in by a person. Every Startup has it with no setup, because every Verb emits an Event and every Offer declares its Entitlements.
Computed, never set
A Customer's status is a projection of its Events. No Verb writes it, so it cannot go stale and no one can mark a Customer healthy to hide a risk.
| Status | Computed from |
|---|---|
trialing | An accepted Offer, with no Customer.activated yet |
activated | Customer.activate ran: the Customer reached the Offer's first value |
atRisk | Any health input crossed its line |
churned | Every Subscription canceled and no open Order |
wonBack | A new Subscription or paid Order after churned |
A Customer is a Customer forever, so churned is a state, never a deletion. Customer status is distinct from Subscription status: one Customer can hold an ending Subscription and an active one.
Five inputs
The health of each Customer reads five inputs, all from records the Startup already keeps.
| Input | Reads | At risk when |
|---|---|---|
| Entitlement use | Use against each Entitlement this Period | Use falls below half the Customer's own median for a Period |
| Activation | Days since the Offer's activation Event | The activation window closes with no Customer.activated |
| Usual interval | The gap since the Customer's last activation Event | The gap passes twice the Customer's usual interval |
| Open Conversations | Conversations past respondBy, and resolutions reversed in 7 days | Either one is open |
| Failed charges | Subscriptions in pastDue | Any one is pastDue |
The usual interval is the median gap between the Customer's last ten activation Events. A household that logs dinner nightly is quiet after two days; a clinic that runs payroll twice a month is quiet after 30.
The rule is a versioned Policy
The inputs and their lines are a Policy: a versioned definition, tested like every other. Each new Variant replays the Startup's past Events. It ships only when it predicts the next 90 days of cancels no worse than the current Version.
The Studio holds the default Policy. A Startup tunes it like any other definition, through a Change, and keeps every Version.
Three moves
Health exists to set the next action. Each signal starts exactly one move.
| Signal | Move | Run by |
|---|---|---|
| Quiet past twice the usual interval, or no activation in the window | One Message offering help with the last failed step | Silence watch |
| Use reaches an Entitlement's bound | The Offer's declared atBound outcome: stop, overage or upgrade | Usage upsell |
A Customer at or above onboarding.handSetupLine turns atRisk | A Task for the Success Manager with the inputs that moved | Success Manager |
At the bound the Customer decides, never the Startup's Founder. Each Offer declares what happens there, and any approval belongs to the Customer's own admin.
A silence that traces to a defect opens an Issue instead of a second Message. The Customer hears once, and the cause gets fixed.
Measure
Customer health is the share of outside paying Customers whose status is not atRisk at the window's end. The Success Manager owns it, and Month-3 retention shows whether it predicted right.
A SaaS for clinic intake forms sees a 12-seat clinic fall from 300 submissions a week to 40. The clinic turns atRisk, and the Success Manager's Task shows the cause: a front-desk hire was never invited. The invite goes out with a two-minute walkthrough, and usage recovers within the week.
Next
- Before a term renews: the usage review and the notice.
- Cancellation: the save window, when health was not enough.
- Retention: where the three moves run, and who is accountable.