An AI feature in a CRM does one thing: it reads the records as they are and produces something from them. A summary, a score, a next step, a forecast, a draft email. It does not know which fields were filled in carefully and which were filled in to close the screen. It does not know that half the deals in the pipeline closed months ago and nobody moved them. It reads what is there, and it is confident.
So the question before turning on any AI feature is not whether the model is good. It is what shape the data is in. We wrote about the general version of this in why your AI is not underperforming, your business context is. This post is the practical half: six things to measure in a CRM, with a threshold for each, and what the number tells you to fix.
A lead score built on a CRM where the industry field is empty on sixty percent of leads will score on the forty percent and generalise to the rest. A deal summary built on notes that were last written three months ago will summarise a deal that no longer exists. A next-best-action built on activity history where half the calls were never logged will recommend calling people who were called yesterday. None of these is the model failing. Each is the model doing exactly what it was asked with what it was given.
The companies whose AI rollouts disappoint almost always have a data problem that predates the rollout by years and that nobody measured, because until the AI feature arrived nothing read every record. People read the records they needed. The model reads all of them.
Every one of these can be measured from a report or a query in an afternoon. Do all six before you switch anything on.
For each field an AI feature will use, what fraction of records has it filled? Not the whole record; the specific fields. A lead scoring feature reads industry, size, source, title and activity. Measure those five. Below eighty percent on any of them, the feature will be scoring from a sample and pretending otherwise. The fix is rarely a data cleanup; it is finding out why the field is empty, which is usually that nobody needs it to do their job, and either making it required at the point where it is known or taking it out of the model.
For open deals, open leads and active accounts, when was each last touched by a person? Count the ones untouched in ninety days. Above twenty percent of open deals, the pipeline is fiction, and any forecast or summary built on it inherits the fiction. The fix is a process: a rule that closes or flags anything untouched past a threshold, and a manager who looks at the flagged list weekly.
How many contacts, accounts and leads exist twice? Measure by email, by domain, by phone, and by a loose name match. Above five percent, every count the model produces is wrong, every score is split across two records and every summary misses half the history. Zoho and most CRMs have merge tools; the fix is running them, then finding the entry path that created the duplicates, which is usually an import or a web form with no match rule.
Pick five picklist and text fields the feature will read and count the distinct values. An industry field with four hundred distinct values, or a stage field that has been renamed three times so that old deals carry old names, is a field the model cannot group on. The threshold is whether a person could group the values by hand in an hour; if not, the model will not either. The fix is a controlled list, a one-time mapping of the old values, and a rule that stops free text in that field. We have written about the practices that keep a CRM clean and used, and consistency is the one that pays most for AI.
Of the interactions that happened last month, calls, emails, meetings, how many are in the CRM? Sample twenty deals and ask the owners. Below seventy percent, the activity history the model reads is a minority report, and any feature that reasons about engagement will be reasoning about the people who log things. The fix is integration, not discipline: email and calendar sync, telephony logging, so that the record is created by the event and not by the memory of it.
Who owns the records, and can the feature see them? A model that runs under a user who cannot see half the pipeline will summarise half the pipeline. A model that can see everything, including fields the company considers restricted, is a governance problem before it is a data one. Measure what the feature's user can reach, and check it against what it should. The audit log is where you find out what it actually read.
Put the six on one page. Most CRMs we assess fail two or three of them, and the ones they fail are not random. Completeness and consistency fail together, because both come from fields that nobody needs to do their job. Staleness and activity coverage fail together, because both come from a process where the CRM is updated after the work rather than by it. Duplicates and ownership fail together, because both come from imports and integrations nobody owns.
That pattern is the point. The fix for a data quality problem is almost never a data cleanup, which restores the numbers for a quarter until the process that produced them runs again. The fix is the process: required fields at the point where the fact is known, records created by events rather than by memory, one owner for every entry path. A cleanup is worth doing once, on the day the process changes, so that the model starts from a clean floor.
Start with the feature that reads the fewest fields and the freshest records, which is usually a summary or a draft, because it fails visibly and cheaply. Move to scoring and next-step features when the completeness and consistency numbers are above threshold, because they fail quietly. Leave forecasting and autonomous actions until staleness and activity coverage are fixed, because they fail expensively. A company that turns them on in the other order gets a forecast it cannot trust in month one and a decision not to trust AI in month two.
We run the six measurements as part of a readiness assessment, a few days of work that ends with a written score, the process fixes behind each failing number and the order to turn features on. If the data is not ready, the assessment says so and says what to fix first, and that is a better outcome than a rollout that gets blamed on the model. Where the fixes involve building anything, they come with a guaranteed estimate. The migration checklist covers the special case where the data is about to move, which is the one moment when a cleanup and a process change can happen together.
An AI feature reads the CRM as it is. Measure completeness, staleness, duplicates, consistency, activity coverage and permission shape before turning anything on. Fix the process that produced each failing number, clean up once on the day the process changes, and turn features on in the order that fails cheaply first. The model is not the variable. The data is.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Your Dashboard Is Only as Good as the Data Behind It (video)
Customer Master Data: Deciding Which System Owns the Customer Before Anything Syncs. (article)
Nobody Is Governing the Agents: What Yours Can Reach, and Who Decided (article)
There is no single score; use thresholds per measure. Completeness above eighty percent on the fields a feature will read. Fewer than twenty percent of open deals untouched in ninety days. Duplicates below five percent. Consistent picklist values with no runaway variants. Activity logged on most active records. Permissions that match the org chart. Each measure points to a specific fix, which is more useful than one combined number.
An afternoon for the six measurements if the CRM supports reports and queries, which most do. Completeness and staleness are report filters; duplicates need a match on email, domain, phone and name; consistency is a count of distinct values per field. The analysis is quick. The fixes are process changes and take longer, which is why the measurement should happen before any AI feature is bought.
Fields that nobody needs to do their job and so nobody fills in. Entry points, such as web forms and imports, that create records without matching existing ones. Stages and picklists renamed without migrating old values. Deals that are never closed because closing them is extra work. And no owner for any of it. Each cause is a process gap, and the fix is usually a decision rather than a cleanup.
Measure first, then fix the process gaps behind the worst numbers, then clean. A cleanup without the process fix produces a clean snapshot that decays immediately, and a feature tested against that snapshot disappoints within months. Turn features on in order of how little data they depend on, and watch the measures as each one goes live so a decline is caught early.
Find out why the field is empty. Usually nobody needs it to do their job, so it is skipped. Either make it required at the point in the process where the value is known, such as a stage change, or remove it from the model and the reports. Requiring every field at record creation produces junk values rather than complete data, and the reports get worse rather than better.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
