Every revenue intelligence tool — every scoring model, every forecasting layer, every pipeline health dashboard — is downstream of one thing: whether your CRM activity data is any good. Before you build on top of it, you need to know what you're actually working with.
This sounds obvious. It rarely gets done with any rigor. Most RevOps teams have a general sense that their CRM data is "messy" or that reps don't always log calls consistently, and they proceed to build dashboards and scoring models on top of that vague discomfort. When the model's output looks wrong, they tune the model. The problem is usually the data, not the model.
What "CRM Data Quality" Actually Means for a Scoring Model
When we say CRM data quality, we're talking about three distinct problems that get conflated:
- Completeness: Are activity fields actually populated? A deal where the rep made 12 calls but logged two looks like a low-activity deal to any model that reads the CRM. It will score incorrectly. Completeness is the most common problem — in a typical B2B SaaS CRM with moderate hygiene practices, 30–50% of call and email activity goes unlogged manually, with the exact rate depending heavily on whether auto-capture tools are in place.
- Accuracy: Are the activity records that exist actually correct? This includes stage dates that don't reflect real-world progression (reps moving deals backward or forward in stage for admin reasons), close dates that get pushed without a corresponding stage change, and contact records that don't reflect actual decision-makers vs. administrative contacts.
- Consistency: Does the same rep log activity the same way over time, and do different reps in the same team log activity comparably? If one rep logs every meeting as a "call" and another creates separate meeting records, your model will see systematically different activity profiles for the two reps even if their actual selling behavior is identical.
The Silent Bias: What Bad Data Teaches Your Model
Here's the part that doesn't get enough attention. A scoring model trained on historical closed-won data learns patterns from that data. If the historical data has systematic gaps — say, deals closed by a specific rep who was diligent about CRM logging vs. deals closed by a rep who wasn't — the model learns that low-activity deals rarely close. That's not a pattern in the real world. It's a pattern in your logging behavior.
This creates a bias that's genuinely hard to detect because it produces plausible-sounding outputs. The model scores deals with good logging higher (correctly, in relative terms, because the data quality is better, not because the deal is better) and deals with poor logging lower. Your RevOps team looks at the scores and thinks they seem roughly right. They are roughly right — but for the wrong reason.
A mid-size infrastructure software vendor discovered this pattern when they onboarded a new scoring tool and found that deals from their West Coast team consistently scored 15–20 points lower than East Coast deals at equivalent stages. The gap disappeared almost entirely once they discovered that the West Coast team was using a third-party email tool that didn't auto-sync to Salesforce. Their East Coast team had been on the same tool but had a rep-level policy of manual sync. Same deal quality. Very different model input.
A Practical CRM Audit Before You Build
Before implementing any scoring model, run a data completeness audit on at least 24 months of closed-won and closed-lost deals. You're looking for:
- Activity record density: For closed-won deals, what is the median number of logged activities per deal? What's the standard deviation? If the standard deviation is very high (e.g., median 12 activities but SD of 18), that's a logging consistency problem, not a deal complexity problem.
- Stage timestamp completeness: What percentage of your historical closed-won deals have timestamps for every stage transition? Missing stage timestamps mean you can't calculate days-in-stage, which is critical for any velocity-based scoring.
- Contact record quality: What percentage of historical closed-won deals have multiple contacts with different job titles? Deals closed with only one contact record are either genuinely single-threaded (bad) or were closed with multiple stakeholders who weren't tracked (data quality problem). You need to know which.
- Close date accuracy: Compare the stage-moved-to-"Closed Won" timestamp against the contract date or invoice date if you have them. A gap of more than 30 days suggests that deals are being closed in the CRM at administrative convenience rather than on actual close date — which corrupts any time-based analysis.
The Reps Who Don't Log Are the Biggest Problem
There's an uncomfortable truth in CRM data quality work: the reps with the worst logging habits are often not the worst performers. High performers with efficient processes sometimes log the least because they're spending time selling, not updating fields. This creates a counterintuitive data quality problem where your best historical closed-won deals have the worst data completeness.
This is not to say that logging discipline is unimportant — it's critical for any downstream analytics. But it means you need to be careful about how you interpret activity density in your historical win data. A closed-won cohort that averages eight logged activities per deal might look like a low-engagement cohort, when in reality it represents a high-performing team that just didn't log much. If you train a model on that, you'll build a model that underweights activity — which will misfire on reps who do log.
The fix for this isn't more mandatory logging fields. It's auto-capture: email and calendar sync that logs activity without asking reps to do anything. Gong, Outreach, and Salesloft all have versions of this. The RevOps work is making sure those systems are configured to write activity back to the CRM in a format the scoring model can consume.
Field-Level Gaps Are Not Created Equal
Not all missing data hurts equally. If your model uses email response latency as a signal and 40% of your email activity is missing, that signal is unreliable. But if your model uses meeting attendance and you have near-complete meeting records (because meetings go through calendar, which syncs reliably), meeting-based signals are still usable even with the email gap.
When auditing, map each field used by your intended model to its completeness rate. Deprioritize signals with completeness below 60% in your training data, and flag them as unreliable for current-deal scoring until you fix the source. This is more practical than trying to impute missing values — imputation can work statistically but it introduces its own bias when the missingness is correlated with rep behavior rather than random.
Minimum Viable Data Quality for a Cohort Model
For a behavioral cohort model to produce meaningful scores, a realistic minimum threshold based on what actually works in practice:
- At least 80 closed-won deals in the training window (ideally 150+, distributed across deal sizes)
- Activity completeness (calls + emails combined) of at least 65% across the training set
- Stage timestamp completeness of at least 80%
- At least two activity types represented reliably (e.g., email + meetings if calls are poorly logged)
Below these thresholds, scores will be generated but their predictive validity is low. You're essentially scoring based on noise. The honest answer in that case is to fix the data problem before implementing the model — not to proceed and then attribute the model's poor performance to the model.
Data quality work is unglamorous. It's also the highest-return investment you can make before implementing any revenue intelligence layer, because a model with clean input data and a modest algorithm will consistently outperform a sophisticated model trained on garbage. That's not a flaw in the model — it's the nature of supervised learning on behavioral data.