CRM Data Quality: Measure It Before You Fix It
Home›Blog›Data quality
Your CRM holds thousands of records, and no one can say how many are accurate. This article shows how to measure CRM data quality across five dimensions, object by object, and then how to maintain it without a major clean-up every year.
12,480 contacts. How many are accurate?
We count records. We never measure what they are worth.
Measure your data
Key takeaways
- You can only fix well what you have measured. Completeness, accuracy, freshness, consistency with the ERP and uniqueness can each be checked with a simple rule, object by object.
- One score per object, not for the whole database. Calculated only on the fields that drive a decision, it tells you where to act; an overall score for “the database” tells you nothing.
- Quality holds through documentation and routine. A data dictionary and regular checks do more, over time, than a one-off major clean-up.
- A field nobody owns degrades, whatever the tool. Every useful field has a named owner, an entry rule and a system of record.
The scene is a familiar one in many committee meetings. The sales director presents the quarterly forecast, finance challenges the figure, and someone ends up saying that “the CRM is wrong”. No one can say how, and the conclusion follows on its own: the database needs cleaning. A team gets to work, the reports become credible again, and then the same doubt comes back.
The problem is not a lack of effort: things were fixed without measuring which dimension was failing, on which object, and why. This article offers a three-step method: break quality down into checkable dimensions, measure it object by object, then assign each field to someone who owns it over time.
What “CRM data quality” means
CRM data quality is a record’s ability to serve the decision expected of it: sending a campaign to the right contact, forecasting revenue, invoicing the right company. A database is not “clean” in general: it is reliable for a specific use, or it is not.
Five dimensions, five questions to ask a record
To move beyond “the CRM is wrong”, you need to ask every record five distinct questions. Is it filled in? Is what is filled in correct? Is it still true today? Is it the same as in the ERP? Does it exist only once? Each corresponds to a dimension, with its own causes and remedies.
Completeness and accuracy: filled in does not mean correct
Completeness is easy to measure: a field is either empty or it is not. People often stop there, wrongly. A “Job title” field filled in with “Director” on a record whose contact is actually a buyer is complete, and wrong.
Accuracy requires an external reference: the company register for the registration number, the company’s website for the address, the contact themselves for their job title. It is checked by sampling: a few records drawn at random and compared with reality tell you more than any fill rate.
Freshness: true yesterday, wrong today
Contacts change jobs, companies move, deals get bogged down without anyone closing them. A record entered correctly two years ago can be wrong today without anyone having made a mistake. Freshness is checked by date: date of last activity, date of last verification, date of the next planned action. An open deal whose close date has passed directly skews the forecast.
Consistency between the CRM and the ERP: which tool is the system of record for which field
As soon as the CRM exchanges data with the ERP, the same information exists twice: the billing address, the company registration number, the payment terms. If each team corrects on its own side, the two versions diverge and the sync spreads the error. The rule is simple to state: for each shared field, a single tool is the system of record, and the other receives it. This split is decided in writing, before data starts flowing between the ERP and the CRM.
Uniqueness: one record, only once
The last dimension is the most visible: the same customer recorded two, three or four times, under similar spellings. It is measured with matching rules (same registration number, same email domain, same normalized name); fixing it is covered in our article on duplicates between the CRM and the ERP.
Measure before you fix
Measuring CRM data quality does not require a specialized tool. It requires choosing what you measure, on which object, and looking for where the error comes from.
Choose the fields that matter
Measuring every property in a CRM drowns the signal. Start from the decisions: which fields are used to segment a campaign, build the forecast, issue an invoice, assign an account to a sales rep? They, and they alone, go into the measurement. The others raise the question of whether they are useful at all.
One score per object
Then calculate a separate score for each object: contacts, companies, deals. For each one, take the selected fields and, for each dimension, the rule that says whether a record passes the check: the field is filled in, it follows the expected format, it has been verified within the set period, it is identical to the value in the ERP. An object’s score is the share of records that pass each check, read dimension by dimension.
An overall score for “the database” mixes unrelated realities: very complete contacts can hide stalled deals. The expected level is set by use, not by a standard: a wrong billing address blocks an invoice, a missing second phone number blocks nothing.
Read the score: which dimension, which object, which source
A low score is only useful if you know where the error comes from. Three sources come up most often:
- Data entry. A free-text field where a closed list would do, a required field the tool does not enforce, an instruction no one has written down.
- Imports. A trade-show file loaded with no format check and no matching against existing records.
- Synchronization. Two tools overwriting each other because neither is the system of record for the field in question.
Each source calls for a different remedy: that is why measurement comes before correction. To assess your own data, the diagnostic at the top of this article gives an initial profile by dimension for the object that carries the most weight in your decisions.
Mirakl’s case illustrates the third source. Synchronization problems between HubSpot and Salesforce caused data inconsistencies, and no clear rule governed the use of properties and workflows in HubSpot. The work focused on two areas in particular: fixing the synchronization settings between the two tools, and defining usage rules for properties and workflows so that the database stays reliable over time. The Mirakl case study is detailed on our website.
Cleaning without measuring fixes the symptom and leaves the cause in place.
Who owns each field
Data degrades when everyone can change it and no one is accountable for it. That is why so many databases “get dirty again” after a clean-up.
The CRM data dictionary
The data dictionary is a simple document: one line per useful field, and for each line a definition, an owner, an entry rule, the system of record and the associated check. It settles questions that seem obvious until the day three teams answer them differently: what counts as an “active customer”, who is allowed to change a legal company name.
This dictionary does not need to be exhaustive: start with the fields selected for measurement, the ones that will be checked afterwards.
Governance in practice
CRM data governance comes down to three written decisions: who creates a field, who modifies it, who deletes it. Without them, each team adds its own properties as needs arise, with similar names and different definitions. One rule is often enough: every new field goes through the CRM owner, who checks that it does not already exist, adds it to the dictionary and assigns it an owner.
The role of sales reps: enter less, but enter it right
“It’s the sales reps’ job” is a common answer, and an incomplete one. Sales reps enter data, but they choose neither the fields, nor the rules, nor the value lists. Asking them to fill in dozens of fields per record produces default values and entries made at the end of the month. Reducing data entry to the useful fields, and explaining what each one is for, does more than a reminder to toe the line. The subject is also about adoption, covered in our change management guide.
Keep data reliable over time
“We already cleaned it, and it came back.” The objection describes what happens when nothing changes upstream. A database that stays reliable over time rests on two mechanisms: blocking the error at entry, and spotting it early when it gets through anyway.
Block the error at entry
- Required fields enforced by the tool. Written into an instruction but not configured, a field remains optional.
- Closed lists. Industry, country, stage, loss reason: a list avoids spelling variants of the same answer.
- Checked formats. Registration number, phone, email and postcode are checked at entry, and at import.
- Controlled imports. An incoming file goes through a template, a format check and matching against existing records before it is loaded.
Flows between tools follow the same rules: each connection must state what it does with a rejected value (see our technical checklist for connecting the CRM to the rest of the IT system).
Check routines
The check that maintains quality is not a project, it is a habit: three rhythms, each with a named owner and a short list.
- Every week. Records created during the week without a required field, reviewed by the CRM owner. The error is recent, and its author remembers it.
- Every month. Records with no activity and stalled deals, reviewed by the sales manager. For example, the list of open deals with no activity for 90 days, to close or follow up; the period is a rule to set internally, not a standard.
- Every quarter. Reconciliation of the fields shared between the CRM and the ERP, and review of the dictionary: fields to add or archive, owners to confirm.
As for the teams’ time, these routines cost little because they cover short, recent lists; it is the big clean-up, on accumulated errors, that is expensive. At OKLIMA, creating a product catalog made deal management easier with standardized product data, and a verification system built into the sales pipelines ensures rigorous deal tracking: the check is part of the process (see the OKLIMA case study).
A short list reviewed every week is better than a big clean-up every year.
When to bring in an outside perspective
On a simple scope, all of this can be done in-house. An outside perspective becomes useful in three situations: several tools each hold their own version of the same customer and no one has the mandate to decide which is the system of record; an ERP project is about to fix data migration and synchronization rules for years, and the dictionary needs to exist beforehand, as we show when discussing the role of an ERP integrator; or the database has already been cleaned without the quality holding, a sign that the cause lies in the system, not in data entry.
Where to start
Not with a clean-up. Start with a short assessment: choose the object that carries the most weight in your decisions, list the fields that drive those decisions, measure each one across the five dimensions, and name an owner for every field that does not have one. This work turns “the CRM is wrong” into a precise list of causes, each with its remedy and its owner.
That is turnK’s job: making the data that flows between your tools reliable, so that the figures presented in committee are the ones everyone believes.
the most common questions
By calculating a score per object (contacts, companies, deals) on only the fields that drive a decision, dimension by dimension: completeness, accuracy, freshness, consistency with the ERP and uniqueness. Each dimension is checked with a simple rule, and the result is read by looking for the source of the error: data entry, import or synchronization.
Five criteria are enough for a CRM: completeness (the field is filled in), accuracy (the value is correct), freshness (it is still true today), consistency (it is identical in the ERP) and uniqueness (the record exists only once). A field can be complete and wrong: that is why you should not stop at the fill rate.
Every useful field has a named owner, recorded in the data dictionary: often the sales manager for deals, finance for billing data, the CRM owner for rules and checks. Sales reps enter the data, but they choose neither the fields nor the rules: responsibility cannot rest on them alone.
On three rhythms, each with its own owner: every week, records created incomplete; every month, records with no activity and stalled deals; every quarter, reconciliation between the CRM and the ERP and review of the dictionary. Short lists reviewed often cost less than a one-off big clean-up.
