What AI features in a CRM need from your data before they work

AI inside a CRM comes in two families with different failure modes. Predictive features such as lead and opportunity scoring need documented volumes of labeled history. Salesforce asks for 1,000 leads and 120 conversions, Microsoft for 40 qualified and 40 disqualified leads, Zoho for 200 matching records. Generative features need retrieval and permissions instead.

Key takeaways

• Einstein Lead Scoring asks for at least 1,000 leads created in the last 200 days, of which at least 120 converted to an account and a contact.
• Dynamics 365 Sales requires at least 40 qualified and 40 disqualified leads created and closed inside the training window, and 40 won and 40 lost opportunities for opportunity scoring.
• Zia Field Prediction needs at least 200 records matching the training criteria and retrains once every fortnight.
• When an org has too little history, Salesforce scores opportunities with a global model built from anonymous data across many customers, and switches once your own model performs better.
• HubSpot's predictive lead scoring is an Enterprise feature and estimates the probability that an open contact closes within 90 days.

What the AI features in a CRM actually are

Two different technologies are sold under one label. The first is classical prediction: lead scoring, opportunity scoring, field prediction, anomaly detection. It learns from labeled outcomes in your own records and produces a number.

The second is generative: call and email summaries, drafted replies, narrative next-best-action, chat over your records. It learns nothing from you at run time and instead retrieves context and writes text.

The two fail in opposite ways. A prediction model fails quietly, by ranking on a signal that no longer describes your funnel, and nobody notices for a quarter. A generative feature fails loudly, in a sentence someone can read, which is why it gets caught faster. That difference should drive which one you switch on first and how you evaluate a language model in production.

The data thresholds vendors publish

The useful part is that the minimums are documented. Salesforce states that Einstein Lead Scoring needs at least 1,000 leads created in the last 200 days, with at least 120 of them converted to an account and contact. The requirement applies to each segment you configure, not to the org as a whole.

Microsoft states that predictive lead scoring in Dynamics 365 Sales requires at least 40 qualified and 40 disqualified leads, created and closed within the training window. That window runs from three months to two years. Opportunity scoring requires 40 won and 40 lost opportunities from the past two years.

Zoho states that Zia Field Prediction only works with at least 200 records matching the training criteria, needs about 24 hours before it predicts, and retrains once every fortnight. HubSpot places predictive lead scoring in its Enterprise tiers and frames the output as the probability that an open contact becomes a customer within 90 days.

The published entry cost of CRM lead scoring sits in a comparable range. Salesforce Einstein asks for 1,000 leads and 120 conversions in 200 days. Microsoft Dynamics 365 Sales asks for 40 qualified and 40 disqualified leads, Zoho Zia for 200 matching records (Salesforce Help, Microsoft Learn, Zoho CRM Help).

What each platform does when you miss the minimum

This is the question that separates a working rollout from a demo. The three published answers are different, and each one has a consequence.

Zoho refuses. Below 200 matching records the prediction page shows a waiting state and the user gets a notification saying the outcome could not be predicted for lack of records. Microsoft grades: the model reports a readiness state derived from an area-under-curve score, marks itself as not ready to publish below the threshold, and still allows manual publication.

Salesforce substitutes. Its documentation states that an org without enough opportunity data gets a global model, built from anonymous data contributed by many Salesforce customers. Einstein moves to your own model once yours produces better results. That is a reasonable engineering choice and a reporting hazard at the same time.

Salesforce documents that Einstein Opportunity Scoring falls back to a global model when an organization has too little history of its own. That model uses anonymous data from many customers, and Einstein adopts the customer's own model once it performs better (Salesforce Help).

A score produced by a global model is real machine learning that does not describe your pipeline. It can still be useful. It cannot be presented to a board as evidence about your funnel, which is the same distinction that governs board-level reporting on marketing measurement.

Summarization and drafting have a different dependency

Generative features do not need labeled outcomes. They need retrieval, permissions and provenance. Salesforce describes its Einstein Trust Layer as grounding prompts at run time according to the user's access, and masking sensitive fields before a prompt reaches an external model. It also states zero data retention agreements with external model providers.

That architecture answers the security question and leaves the quality question open. A call summary is only as good as the calls that were logged, and a next-step suggestion built from activity history is empty when the activity lives in someone's inbox. This is the pattern that showed up across the first wave of production generative deployments: the model was rarely the constraint.

The dirty-data failure modes that survive any model

Five conditions break CRM AI regardless of platform. Each one maps to a specific feature:

• Duplicate accounts and contacts. History splits across records, so both scoring and summarization see half a relationship.
• Lead status used as a workflow flag. If "qualified" means "assigned to a rep", the label the model trains on is not an outcome.
• Closed-lost without a reason code. The negative class exists but carries no information, which is exactly what a classifier needs.
• Activity outside the CRM. Email and calls that are never logged remove the strongest engagement signals from the feature set.
• Free text where a picklist belongs. Twelve spellings of the same industry become twelve categories with no volume.

None of these is an AI problem. They are process problems that AI makes visible and expensive, which is the argument for treating this as an operations project rather than a technology purchase.

How to evaluate a vendor claim

Ask four questions, and expect all four to be answerable from documentation rather than from a call.

First, what is the published minimum, in records and in time window? Every platform above states one. Second, what does the feature do when the minimum is not met: refuse, degrade, or substitute another population? Third, what data does it read, and does it enforce record-level permissions at the moment the prompt is built? Fourth, what evaluation metric is exposed to the administrator, and can you see it change over time?

An accuracy number without the population it was computed on is not a claim you can verify. A readiness state you can inspect, like the one Dynamics exposes, is worth more than a percentage in a slide.

What to measure after switching it on

Hold something back. Leave a share of leads unscored or unrouted for a fixed period and compare conversion between the two groups. Without a holdout, adoption of the feature and improvement in the funnel are indistinguishable.

Then check calibration monthly: group scored records into deciles and compare predicted rank against what actually closed. A model that ranks well in the top decile and badly everywhere else is still useful, but only for routing the top decile.

Finally, treat scoring on people as a regulated activity where it drives decisions. Under Regulation (EU) 2016/679, a person has the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. For EU-facing operations this sits alongside the compliance calendar of the EU AI Act.

Regulation (EU) 2016/679 was published in the Official Journal on 4 May 2016. It protects individuals against decisions based solely on automated processing, including profiling, that produce legal effects or similarly significantly affect them (EUR-Lex).

FAQ