Set up won-business scoring

You want the deals already in your pipeline ranked by how likely they are to land. This is the guide for that goal.

What it represents

Won business is the second of the four cards on Create a Score. It ranks open deals by win likelihood, learned from how your own deals have historically resolved.

Pick it when the record you want ranked is a deal. Pick Lead conversion instead when the record is a person who does not have a deal yet, and pick At-risk customers when the record is an account you have already sold to. The three differ by which object carries the record, and the object decides what the model can see: a deal carries amount, stage age, and a close date, none of which exist on a person who has never been quoted.

There are several won-business variants behind More starting points, on account and person primaries. They target the same outcome from a different object, they carry no population, and they exist so a score built before the four cards still resolves. Start from the card.

How it’s calculated

The card is a complete target definition. Its outcome is the won stage on your deal object, dated by the deal’s close date, and its population is the one line that makes this a prediction rather than a report.

That line reads Trains on: deals that are still open. On Salesforce it is the closed flag on Opportunity; on HubSpot the equivalent flag on deals. Scoring a deal that already resolved is not a prediction, it is a lookup, and a model whose scoring population is full of resolved deals will look far better than it is because the answer is sitting in the row.

Training still uses your resolved history · that is where the labels come from. The population line governs what gets scored and what the base rate is read against, which is a different job and the one that was silently missing before.

Set it up

1. Pick the Won business card

   Second of the four at the top of Create a Score. The card title is the goal, not our catalog name for it, which is why it reads Won business rather than the internal entry it maps to.

   If it renders greyed out with a sentence where the population line should be, this connection type has no resolved definition for it yet. Nothing is hidden from you and nothing filled itself in.

2. Read the Trains on line

   Trains on: deals that are still open, on the card and again above Success definition. It is executable population conditioning in the shipped filter grammar, not a description of intent.

   If your team parks dead deals in an open stage rather than closing them, this line will include them and you should expect the base rate to sag. That is a CRM hygiene finding worth having before you train, not after.

3. Confirm Connection and Primary entity

   Primary entity arrives set to Deals. It is the control that decides which object gets one row per record, and therefore which fields the model can read.

   Moving it to Accounts turns this into a different question · which accounts produce wins · with a different population and a different sensible cohort. If that is the question you want, go back and pick a card rather than editing this one into it.

4. Check the success criteria against your own stage names

   What defines success? is the deal object and Success criteria is the condition on its stage field. The value the card fills is the standard won stage for your CRM.

   This is the control most worth reading, because stage picklists get customized more than any other field in a CRM. If your org renamed the winning stage, or splits wins across two of them, fix it here. A criterion that matches nothing produces a model with no positives to learn from.

5. Confirm the Success date field

   Success date field is the deal's close date. Every feature is computed from before that moment, so it is what keeps the stage the deal ended in out of the model that predicts the stage the deal will end in.

   Leave it unless your org dates the outcome somewhere else. If you change it, change it to something that is filled in at the moment the deal resolves, not to a field a rep updates later.

6. Leave the readout on More likely to convert

   What does a high score mean here? stays on More likely to convert for this goal. A high win likelihood is an opportunity, and the bands read hot · warm · cold to match.

   Switch it only if you re-point the success criteria at an outcome you would rather avoid, such as the losing stage. Then a high score means attention, and the readout has to say so.

7. Press Create score and read the preflight

   The button reads Checking your data... while the preflight counts your population and checks your date field against this connection. A pass reads back the count, such as 1,204 records in this cohort, with the population sentence under it.

   It asks data questions only. You will never be asked whether you are sure you want to predict wins, because you already said so by picking the card.

If the preflight refuses

No records match this cohort on this goal means no deal in the connection is open. Sometimes that is true · a brand new sandbox, a connection scoped to a closed territory. The exit offered is Use Lead conversion instead, with the reason stated: lead conversion runs on people, which does not need an open-deal flag. That is an answer rather than a door, and it is offered because the product can see that the other question is answerable with the data in front of it.

No success date field means step 5 is empty. The exit is Continue in Advanced, carrying forward the object, the population, and the criteria that already resolved, and naming the field it looked for so you can go and fix the CRM instead of fighting the form.

We could not check your cohort is neither a pass nor a refusal, and the wording is literal. On HubSpot connections a filtered record count is not something the product can compute today, and on an uploaded file there is no resolved import before the first run. Rather than report a number it did not compute, it says so and lets you continue. Treat the population line as unverified until the first run reads back a record count.

What it means for you

The number is win likelihood, and it is a rank. A deal at 78 sits above a deal at 52. It is not a forecast you can add up, and it is not a commit number · a pipeline of forty deals at 70 does not mean twenty-eight wins, because the score ranks deals against each other rather than calibrating to a rate.

Read it next to stage, not instead of it. The signal worth acting on is disagreement: a late-stage deal scoring low, or an early-stage deal scoring high. A score that agrees with stage everywhere is usually a score that learned stage, which is worth checking against the leakage flag before you circulate it.

Expect the base rate here to be far higher than on a lead conversion score. Deals that got created are pre-qualified by everyone who touched them, so a win rate in the tens of percent is normal and is not evidence of anything being wrong.

When Advanced is the right door. Take Start from scratch (custom) when the population needs more than one condition to describe · one region, above a threshold amount, excluding a deal type · or when success is a combination the criteria on the card cannot express in one row. Advanced still asks you which records are included, so a custom score means you defined the population rather than there not being one.

If you only need to change the winning stage value, do that on the card and keep the lineage. The create flow notes it in one line · “You changed what counts as success from the Won business starting point.” · and the saved score carries the equivalent note, which is exactly what you want a future reader to see. Keep my version clears it once the change is confirmed as deliberate.

Check your understanding

You pick Won business, the card reads Trains on: deals that are still open, and the preflight returns 340 records in this cohort. Your model trains on three years of resolved deals and reports a 34% base rate, and the score is applied to those 340.

Read that back. The 340 is the scoring population, and it contains no resolved deal, which is why none of your scored records has the answer already written on it. The 34% comes from the labeled history, not from the 340, so the two numbers are describing different sets on purpose. Had the population line been absent, the same score would have been applied to every deal you have ever had, three quarters of which already resolved, and the top of the ranked list would have been full of deals your team closed last year.