Where AI projects actually break: the cross-system gap PE firms keep funding through
AI projects rarely break because the model is wrong. They break in the gaps between CRM, finance and HR, where no single-system check ever looks.
Read
Data quality8 min read
Inconsistent entry, missing fields, stale contacts and duplicates: why CRM data breaks AI models, and the order in which to fix it before you build.
The CRM was supposed to be the system of record. Years of investment in Salesforce implementation, training, customisation, and process alignment were meant to create a reliable foundation for customer insights. Management dashboards, pipeline reports, and forecasting all depended on CRM data. It was the source of truth.
Then the AI initiative began, and the truth turned out to be messier than anyone expected.
When the data science team began preparing customer data for a churn prediction model, they discovered problems that traditional CRM reporting had tolerated but AI could not. Inconsistent data entry, incomplete records, stale information, and duplicates that had accumulated over years suddenly became critical obstacles.
It is a common pattern for organisations applying AI to CRM data. The same data that works adequately for reporting and basic analytics fails to support machine learning. Understanding why this happens and what to do about it is essential for organisations planning AI initiatives involving customer data.
CRMs are input-intensive systems. Unlike systems that capture data automatically, such as web analytics or transaction processing, CRMs depend on humans entering information. Every contact, account, opportunity, activity, and note requires someone to type something into a field.
This human dependency creates systematic quality issues that accumulate over time:
Different sales reps enter data differently. One rep meticulously logs every customer interaction. Another enters only required fields. One uses formal company names while another uses abbreviations. One records phone conversations while another only logs emails.
Even with data entry guidelines, enforcement is inconsistent. Sales managers focused on hitting quota rarely prioritise data quality. Reps under pressure to close deals view CRM updates as administrative overhead rather than valuable documentation.
Over time, these inconsistencies compound. A sales team of dozens of reps, each entering data differently for years, has accumulated enormous variability that looks like noise to a machine learning algorithm.
Required fields get populated because the system enforces them. Optional fields are populated sporadically based on individual judgment. Fields that were added after initial implementation may be blank for older records.
The pattern of incompleteness often correlates with what you most want to predict. Records of customers who churned may be more incomplete than records of customers who stayed. Reps may have stopped updating records for accounts that seemed to be slipping away. The very signals that would predict churn are missing from the records of churned customers.
Customer information changes over time. People change jobs, companies change addresses, organisational structures evolve. Contact information that was accurate when entered becomes stale.
CRMs rarely have mechanisms to prompt updates. A contact record might show someone in a role they left two years ago. An account might reflect an organisational structure that was reorganised after an acquisition. This stale data is not just incomplete; it is actively wrong.
The staleness problem is particularly acute for accounts with low engagement. Accounts that are regularly active get updated through normal business interaction. Accounts that have gone quiet are never updated, so their records become increasingly detached from reality.
Duplicate detection and merging is an ongoing challenge in any CRM. A new rep might create an account that already exists under a slightly different name. A contact might be entered multiple times with different email addresses. Acquired companies might bring their own CRM data with overlapping records.
Duplicates create multiple problems for AI. They inflate counts, making certain customers appear more active than they are. They fragment history, splitting a customer journey across multiple records. They introduce inconsistency when duplicates have different values for the same field.
Understanding customer engagement requires comprehensive activity tracking. Calls, emails, meetings, support interactions, product usage, marketing responses, all of these touchpoints contribute to understanding customer health and predicting behaviour.
But activity capture is notoriously inconsistent. Email integration might capture some messages but not others. Call logging depends on rep discipline. Meeting notes vary from detailed summaries to single words. Integration with support systems might be incomplete or delayed.
The result is an engagement picture full of gaps. A customer might appear disengaged simply because their interactions were not captured, not because they actually stopped engaging.
Traditional CRM reporting can tolerate substantial data quality issues. Human analysts apply judgment, recognise anomalies, and interpret data in context. A sales manager reviewing pipeline knows which deals are real and which are wishful thinking, regardless of what the CRM says.
AI cannot do this. Machine learning algorithms learn patterns from whatever data they are given. They cannot distinguish meaningful patterns from artefacts of data quality issues. They cannot apply business judgment to interpret ambiguous data. They treat noise as signal.
If industry is encoded as Technology for some accounts, Tech for others, and IT for still others, the model sees three different industries. If company size is recorded as SMB, Small-Medium Business, and Mid-Market for similar companies, the model cannot learn patterns based on company size.
Feature engineering can partially address encoding inconsistency, but only if the variations are known and mappable. Unknown variations become noise that obscures real patterns.
Machine learning models need complete feature vectors. A record missing three of ten features might be excluded from training entirely. If missing values are systematic rather than random, excluding incomplete records creates biased training data.
Imputation, filling in missing values with estimates, can help but introduces its own risks. Imputed values are guesses that may not reflect reality. Training on imputed data means training on a mix of real and estimated values.
Many AI models depend on frequency counts. How often did this customer contact support? How many opportunities has this account had? How much total contract value has accumulated?
Duplicates corrupt these counts. A customer with two duplicate records appears to have half the activity on each record. Deduplication before AI training is essential but often incomplete.
If contact information is stale, engagement features based on that information are wrong. The model might learn that customers with certain email domains churn, when actually those domains are defunct and the customers have moved to new addresses.
Stale data is particularly dangerous because it is not obviously wrong. The values are valid; they are just no longer true. Quality checks that look for format violations will not catch staleness.
If customer engagement is incompletely captured, customers appear less engaged than they actually are. A customer who had multiple productive interactions that were not logged looks like a disengaged customer at risk of churn.
The model learns that low visible engagement predicts churn, which may be true. But it also learns to ignore actual engagement signals that are not consistently captured, reducing model accuracy.
Addressing CRM data quality for AI requires a systematic approach. The goal is not perfection but sufficiency for the intended AI application.
Before cleaning historical data, establish standards for new data entry. Define required fields, acceptable values, and entry procedures. Implement validation rules that enforce standards at entry time. Train users on standards and provide ongoing reinforcement.
Standardisation prevents new problems from accumulating while you address existing ones. Without standardisation, historical cleanup is a Sisyphean task.
Not all historical data needs remediation, only data that will be used for AI training and prediction. Identify the specific fields and records required for your AI use case and focus remediation efforts there.
Prioritise by impact. Fields that are highly predictive deserve more remediation investment than fields with marginal importance. Records from critical customer segments matter more than records from segments outside the AI scope.
Entity resolution is the process of identifying which records refer to the same real-world entity and consolidating them into a unified view. This addresses the duplicate problem and enables cross-system integration.
Effective entity resolution requires matching logic that handles name variations, address changes, and missing identifiers. It requires confidence scoring so uncertain matches can be reviewed. It requires ongoing maintenance as new records are created.
External data sources can fill gaps and validate accuracy. Company databases can verify firmographic data like industry, size, and location. Contact databases can validate and update contact information. Third-party intent data can supplement engagement signals.
Enrichment is not a substitute for fixing internal data quality but can accelerate remediation and improve completeness for fields that are difficult to capture internally.
Data quality is not a one-time fix but an ongoing discipline. Implement monitoring that detects quality degradation before it undermines AI systems.
Monitoring should track completeness rates, matching rates, staleness indicators, and validation failure rates. Alerts should trigger when metrics fall below thresholds. Regular reviews should identify emerging quality issues.
CRM data quality requires continuous attention. New users need training. Standards need enforcement. Duplicates need resolution. Stale records need updating. Without ongoing maintenance, quality will degrade.
Build data quality maintenance into normal operations rather than treating it as a one-time project. Assign ownership, allocate resources, and establish accountability for sustained quality.
CRM data quality issues are not reasons to abandon AI ambitions. They are obstacles that can be addressed with appropriate investment and discipline. CRM data can support AI once the quality issues that matter for the use case are fixed.
The key is realistic assessment before AI development begins. Understand the current state of your CRM data. Understand the specific requirements of your intended AI application. Understand the gap between current state and requirements. Plan and fund remediation as part of the AI initiative.
Organisations that skip this assessment and proceed directly to AI development tend to fail. The data issues that traditional reporting tolerated become insurmountable obstacles for machine learning. The AI initiative fails, and the organisation concludes that AI does not work for their business.
But AI does work when built on an adequate data foundation. The question is whether you build that foundation before the AI initiative or learn the hard way that it was needed.
Insights by email
Short notes on what company data can and can’t carry, for CEOs, CFOs and investors weighing an AI decision. No vendor news, no sales sequence.
Exports from two or more systems, compared record by record. The gaps between them, and a verdict, in a signed memo within 5 working days of complete exports. From a firm with nothing else to sell you.
Starts with a 30-minute call. Commits you to nothing.