Which customers are drifting, learned from the ones who left.
Customer health ranks the accounts you already sell to by renewal and churn risk, trained on the renewals your own book has won and lost. Same engine as scoring, pointed at the other end of the relationship.
In the product. Not on the MCP surface today.
One health question, asked from both ends.
At-risk customers ranks accounts by churn risk, learned from the renewals your book has lost. Renewal and expansion ranks the same accounts by the upside, learned from the renewals it has won. They share a population on purpose: both questions are asked of the same customers, and the difference is which end of the renewal you are looking at.
Everything about this family turns on who is in the population. A risk model built by hand tends to arrive with a target that reads correctly and a population that does not, and the result is a number that looks like churn and is not: every account in the CRM, prospects and dead accounts and duplicates included, scored against every lost deal. That is a perfectly correct answer to "which deals lose", reported as though it answered "which customers leave".
So the population is stated on the card before you pick it. It trains on accounts that are current customers: the account type field on Salesforce, the lifecycle stage on HubSpot.
Your renewals, and only the losses that are really losses.
Success on a risk target is the thing you want to avoid, and naming it precisely is structural work rather than editorial work. The criteria point at the lost-renewal stage on your own deal object, dated by the deal’s close date.
Not every closed-lost record is a departure. Losses that are record-keeping artifacts, a duplicate, a merge, a deal re-opened on the same account shortly after, leave the population instead of counting as losses, because a churn model trained on duplicates and merges learns your CRM hygiene alongside your customers. When that exclusion runs, the model reports how many records left and the rate before and after the cut. When it cannot run on your data, it says that instead.
First-party only, as everywhere else in ax1om: your renewals, your accounts, no pooling across customers.
A symmetric cutoff, and a refusal where the data cannot answer.
The failure this family exists to avoid is a leak that no train/test split can reach. If churned accounts are described as of their real churn date while renewed accounts are described as of a generic cutoff, then when you looked at an account is correlated with the answer, and the model reports a number that flatters itself before any split runs.
ax1om cuts every account by the identical rule. Churned and renewed alike are described as of their own renewal decision, and where a date cannot be resolved it stays unresolved and counted rather than filled in with a guess. The cutoff sources are recorded on the run, so a model built the wrong way is visible in its own record.
Validation is a cohort-out backtest rather than a single split, because a single split on a book with a few dozen seasonally clustered churns can land one renewal quarter in the test fold and read like a result. And where your CRM carries no way to tell a renewal apart from any other deal, the renewal target has no honest reading at all: the preflight refuses before training rather than quietly becoming a general won-business model wearing this one’s name.
"Why this account is at risk", in your own field names.
Every account carries the same per-record factors scoring ships: the fields that pushed this account’s number up or down the most, in your own field names, with the direction each one moved it.
On a risk model the downward direction is the useful half. It is the account-level answer to "why is this one flagged", which is what a CSM needs before an outreach and what a QBR needs behind a retention number.
The score carries its own polarity, so a high risk number reads as risk everywhere it lands rather than as a healthy-looking high score.
Consumed by your team
Health lands on the same rails scoring does. Nothing new to learn, and nothing new to wire.
The account number and its ranked factors write back to fields on the account, so a CSM reads them where they already work the book. Writeback needs a connected CRM.
Export the ranked book, or work it in the app: the account list, the factors behind any account, and the model readout with the backtest and the record-keeping-loss block next to the base rate.
The at-risk list is the bottom tail of one health score, not a second model. One score, two framings: healthy and at risk.
Consumed by your agents
Not over MCP today. Customer health is a trained model family that ships in the product, on the same rails as scoring: your outcomes in, validation gate, prediction with factors out. What agents call over MCP today is conversion scoring, end to end.
We will say so here the day that changes.
What operators ask about customer health
How is this different from a health score I build by hand?
A hand-built health score is a weighted checklist: somebody decides that a support ticket is worth minus ten and a QBR is worth plus five. It encodes an opinion about churn. ax1om learns from the renewals your book actually lost, so the weights come from your outcomes rather than from a workshop, and every account carries the fields that moved its number.
What if my CRM does not distinguish renewals from new business?
Then the renewal target has no honest reading, and ax1om says so before training rather than after. Without renewal typing the model would either find no positives at all or quietly become a general won-business model on a customer population, which is a different question wearing this one’s name. The preflight refuses instead of degrading.
Does a lost deal always count as a churn?
No, and this is the check most hand-built risk models skip. Losses that are record-keeping artifacts, a duplicate, a merge, a deal re-opened on the same account, leave the population rather than counting as losses. The model reports how many left and the rate before and after, so you can see what the cut did.
Can my agent call the health model over MCP?
Not today. Conversion scoring is what is live on the MCP surface; customer health runs in the product. It is the same engine and the same contract underneath, which is why the surface can grow, but we do not claim a surface before it ships.
Learn churn from the churn you already had.
Connect the CRM that holds your renewals, pick the customer population it already knows about, and read what the backtest found before anything routes.