How does Odoo calculate the probability of winning a lead?

It uses a naive Bayes model on the won and lost history in your own CRM. Stage and sales team are always used, and you can add state, country, phone quality, email quality, source, language and tags.

Can I turn predictive lead scoring off?

The documentation says it is always active. What you can change is which optional variables it considers and the date from which it counts leads, and you can overwrite any single probability by hand.

Why is my lead's probability not changing?

If the probability was edited by hand it no longer follows the computed value. The AI icon beside the number restores the automatic probability.

Predictive Lead Scoring in Odoo CRM: What It Learns and Misses

Short answer: Odoo’s predictive lead scoring counts how often leads with a given stage, team, country, source and similar values were won or lost in your own database, and turns those counts into a probability for each open lead. It is always on. It gets better with history, and it is only as honest as the won and lost data your team enters.

Applies to

Odoo version: 19. I compared the lead scoring page with the 20.0 documentation and the text is identical.
Edition: Community and Enterprise. The scoring code lives in the open-source crm module.
Apps: CRM. Settings are under CRM ‣ Configuration ‣ Settings.

What is the model actually doing?

The documentation calls it a machine-learning model and names it: naive Bayes. In plain terms, Odoo keeps a table of counts. Each time a lead is won or lost, it adds one to the won or lost tally for each value the lead had, such as its country or its stage.

To score an open lead, it multiplies the chance of winning given each of its values, does the same for losing, and compares the two.

The 19.0 source comments say a small amount is added to every count so that a value never seen before does not cause a division by zero. The same comment is blunt about the limits: with little data, the result is not very realistic.

Which variables does it use?

Stage and Team are always used. You choose the optional ones under CRM ‣ Configuration ‣ Settings ‣ Predictive Lead Scoring ‣ Update Probabilities:

State and Country
Phone Quality and Email Quality, which only record whether a phone number or email address is present
Source
Language
Tags

The same window has Consider leads created as of the:, a date from which history counts. Saving it with Update rebuilds the counts. In the source, these choices are stored as two system parameters, crm.pls_fields and crm.pls_start_date.

Where does a developer need to be careful?

Three details in the source change how I would use it.

The counts are split by team. The source comments say team A does not influence team B. A new team starts with no history of its own, and the code falls back to counts that do not belong to any team. If you want scoring to learn quickly, fewer, larger teams help.

It needs both outcomes. If a team has no won deals, or no lost ones, the code skips the calculation for that team. A team that never records lost deals gets no useful score.

The output is clamped. The probability is kept between 0.01 and 99.99 and cannot be set to 100 by the model. The documentation adds that a lead cannot be manually set to 100, and converting one at 100 raises an error.

Because the frequency table updates whenever a lead is marked won or lost, careless data entry feeds straight back into the scores.

Can I override the score?

Yes. Click the probability on the opportunity and type a value. From then on that lead stops following the computed value, which the 19.0 source tracks with an is_automated_probability flag. The AI icon next to the number returns it to the automatic value.

Overrides are useful for the one deal you know about. They are harmful as a habit, because they hide what the model sees.

Where does the score feed in?

Two places. Forecast reports multiply expected revenue by probability, so every score flows into the forecast. And rule-based assignment can use probability as a filter. The docs’ example is a team domain of Probability >= 20, with leads assigned manually or on a schedule.

When it fits and when it doesn’t

It fits when you have a steady stream of leads, a habit of marking deals won or lost, and a few fields that really separate good leads from poor ones, such as the source.

It does not fit a team with very few deals, or one where won and lost are recorded inconsistently. In that case I would turn off the optional variables that add noise, keep stage and team, and treat the number as a rough pointer only. Do not base a bonus scheme on it.

Worked example: a training provider

A training provider has one team for company bookings and another for individual learners. Company bookings come mainly from referrals and the website form, and individual learners from adverts.

After a few months of recorded wins and losses, Source and Country will carry real information for each team separately. The provider adds Tags only after agreeing the tag list, so that “VIP” and “vip ” do not split into two values. The company team then assigns leads at or above a chosen probability to senior salespeople.

Common mistakes

Expecting a useful score in the first week.
Letting people mark deals lost just to clear the board.
Adding Tags as a variable while tags are inconsistent.
Overwriting probabilities, then trusting the forecast.

The way won and lost are stored is covered in how Odoo CRM pipelines work. If you are choosing where leads come from, see lead generation and lead mining. A non-technical view of the same feature is on sajjalbajaj.in.

Official references

How this article was checked: I read the 19.0 lead scoring page, compared it with 20.0, and read the scoring section of the 19.0 crm.lead source, including its comments. I did not run a live database or measure the accuracy of the scores.

If you want a scoring setup that your team can trust, see my portfolio and get in touch.