Set up an at-risk model
You want to know which of your customers are drifting toward not renewing. This is the guide for that goal, and it is the one where picking the card rather than building the target by hand matters most.
What it represents
At-risk customers is the third of the four cards on Create a Score. It ranks accounts you already sell to by churn risk, learned from the renewals your own book has lost.
Everything about this goal turns on one thing: 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. The most common version is a score whose records were every account in the CRM · prospects, dead accounts, partners, duplicates · and whose target was every lost deal. That model is a perfectly correct answer to the question “which deals lose”, reported as though it answered “which customers leave”.
The card exists so that picking the goal produces the goal. Pick it when the record you want ranked is an account with a live relationship. Pick Renewal / expansion when you want the same accounts ranked by the upside instead.
Behind More starting points there is an older Churn Risk entry on the same object. It targets the same outcome, it carries no population, and it stays selectable so scores built on it still resolve. Use the card.
How it’s calculated
The population line reads Trains on: accounts that are current customers. On Salesforce that is the account type field; on HubSpot it is the lifecycle stage. It is the single most consequential sentence in this setup, and it is on the card before you click it.
Success, on this target, is the thing you want to avoid. The criteria the card fills point at the lost-renewal stage on your deal object · Renewal - Lost on a standard Salesforce org, the generic closed-lost stage on HubSpot, where the preset has no renewal typing to point at · dated by the deal’s close date. The word success is doing structural work here rather than editorial work: it names the event the model is learning to anticipate, and on a risk target that event is a departure.
Not every closed-lost record is a departure, and this card is the one that says so. Under the success definition a one-line note reads: “Losses that are record-keeping artifacts · a duplicate, a merge, a deal re-opened on the same account · leave the population instead of counting as losses.” That is a definition field, not a courtesy: a churn model trained on duplicates and merges learns your CRM hygiene alongside your customers. When the exclusion runs, the result carries a Record-keeping losses block right where the base rate shows · how many records left, identified from your loss reasons or from a new deal opened on the same account shortly after, and the rate before and after the cut. When it cannot run on your data, the block says that instead, and every loss counts.
A model of this family also swaps its cutoff discipline. Rather than measuring each account from its own outcome date, it anchors on the renewal decision and looks back a fixed window before it, so every account is described at the same distance from the moment that decides the answer.
Set it up
-
Pick the At-risk customers card
Third of the four at the top of Create a Score. It is the card that carries the customer population, which is the reason to start here rather than from the criteria builder.
A greyed card with a sentence in place of the population line means this connection type has no resolved definition yet. That is stated rather than filled in with a guess.
-
Read the Trains on line, and mean it
Trains on: accounts that are current customers. Check it against how your org actually marks a customer. Many teams do not use the standard field, and on this goal a population that does not resolve is not a cosmetic problem: it is the difference between a churn rate and a loss rate across your whole book.
The same line reappears above Success definition once the form opens, and it updates if you edit the population. Once you edit it, the product stops claiming the preset's sentence and describes what is actually there instead.
-
Confirm Connection and Primary entity
Primary entity arrives set to Accounts, which is the object a churn question is asked about. One row per customer, one score per customer.
Leaving it on Accounts while re-pointing the success criteria at any lost deal is exactly the shape that produces a loss-rate model wearing a churn label. If you want deal outcomes ranked, that is Won business, and it is one card away.
-
Check the success criteria against your renewal stages
Success criteria holds the lost-renewal condition. Read it against your own stage picklist. The distinction that matters is between a renewal your customer declined and an ordinary deal your team lost, because only the first is churn.
If your org does not separate the two at all, this is the moment you find out, and the preflight in step 7 will say so in as many words.
-
Confirm the Success date field
Success date field is the close date on the renewal deal. This model anchors its lookback on that date, so an account whose renewal date cannot be resolved is left unresolved and counted as such rather than filled in from an average.
That is deliberate. A census-filled renewal date would give every account a plausible-looking history built from a date nobody recorded.
-
Set the readout to More at risk
What does a high score mean here? sits under the success criteria, and the card sets it to More at risk. Its hint states the consequence: "At risk · watch · stable bands, high scores read as attention."
This is the control that makes the readout follow the question. Before it existed, polarity was inferred from which catalog entry a score started from, so a hand-built churn score could congratulate its author on a conversion rate. Check it explicitly here, and check it again on any score you built through Advanced.
-
Press Create score and read the preflight
Checking your data... runs four checks on this card: the population resolves to real records, a success date is set, the connection carries renewal typing at all, and record-keeping losses can be told apart · a loss-reason field, or the deal dates a re-opened-deal link needs. This starting point is the one where the last two earn their place.
A pass reads back a count and the population sentence. It never asks whether you are sure you want to predict churn · you already answered that by picking the card.
If the preflight refuses
No records match this cohort means the customer filter matched nothing, and on this goal that is the most likely refusal you will meet, because customer marking is the least standardized field in most CRMs. Two exits are offered. Use Won business instead is offered with its reason stated: it runs on your open pipeline, which does not need a customer flag. Include every record instead clears the population and re-runs. The second one deserves a moment of thought rather than a click. Clearing the customer filter on a churn target is precisely the shape this card exists to prevent, and if you take it you should read the resulting base rate as a loss rate over your whole account book, not as a churn rate.
We did not find renewal typing in this connection means the connection carries no renewal-typed records to learn from, and the block names what it looked for: a renewal type on the deal object, or a renewal stage on the stage field. The exit is Use Won business instead, because that question uses the deal outcomes you already have. There is no version of this refusal that can be argued past, and a preset that quietly degraded into a general loss model instead would be the original failure with better manners.
Only 14 records in this cohort is a warning and does not block. Fewer than 30 records is too thin to read a rate from, and the count travels with the result.
We cannot tell administrative losses apart on this data is also a warning, never a block. It means the check found neither a loss-reason field nor the deal dates a re-opened-deal link needs, so every closed-lost record will count as a loss, duplicates included · and the result says so rather than implying the exclusion ran. Fixing it is CRM work, not score work.
What it means for you
The bands read differently on a risk score
A conversion score bands as hot · warm · cold, and high is where the opportunity is. A risk score uses the same three bands at the same cut points and renames them, because the top band is now the accounts you should worry about:
- At risk · the top band, from 80 up, red. These are the accounts the model puts closest to the churn pattern it learned. It is a rank, not a verdict, and not a percentage of anything.
- Watch · the middle band, 50 to 79, amber. Enough signal to be worth a look, not enough to escalate.
- Stable · the bottom band, below 50, green. On a risk score, low is good, and the color follows.
The renaming is not decoration. On a risk target every word around the number has to invert with it, or the readout describes a departure using the vocabulary of a win. The same contract that renames the bands renames the rate · you will read churn rate, not conversion rate · and retitles the per-band chart accordingly. If you meet a surface that still describes your churned accounts as having converted, that is a defect worth reporting, not a nuance.
What the number is called also inverts. On a conversion target it is conversion likelihood; on this one it is churn risk. Neither is ever described as a chance or a percentage of anything, on either side. It is a rank from 0 to 100.
Reading it for this goal
A high base rate on this model is not the problem it would be on a conversion score. On a lead score, “more than half your records succeeded” means the target is too broad and the model has little to separate. On a churn target it means your book lost more renewals than it kept, which is a business finding rather than a modeling defect, and the warning copy is polarity-aware so it should not tell you otherwise.
Do compare the rate you get to the churn rate you already believe. If the model reports a rate several times higher than the one your finance team reports, the population is the first place to look, not the model.
When Advanced is the right door. Take Start from scratch (custom) when your customer definition needs more than one condition · a status, a contract flag, and an exclusion for internal accounts · or when churn in your business is recorded somewhere other than a deal stage. Advanced asks you the population question too, so custom means you define who is in, not that nobody is. Whatever you build there, set What does a high score mean here? to More at risk yourself. It is the one attribute a custom score cannot inherit from anything.
An edited card keeps its lineage instead. The score records which of the six definition fields moved · including which losses count as losses · and the create flow says so in one line: “You changed which records are included from the At-risk customers starting point.” The saved score carries the equivalent note. It never blocks, and Keep my version retires the note once the change is confirmed as intended.
Check your understanding
Someone builds a churn score by hand. The population is every account in the CRM, the target is every lost deal, and the result comes back with a 62.7% base rate and a readout warning that more than half the records succeeded.
Nothing there is a bug. Every number is a correct answer to the question that was actually asked, which was “what share of this company’s deals are lost” · a number about the whole deal book, not about customers. Read it back against the card. Trains on: accounts that are current customers is the line that would have replaced the account book with the customer book. The lost-renewal criteria are what would have replaced every lost deal with a declined renewal. More at risk is what would have stopped the readout congratulating anyone. Three controls, all on the front of the card, and the target definition is what was wrong rather than the model.