CRM data quality, and why your new accounts are not new

What is CRM data quality, in practical terms?

CRM data quality is whether one company occupies exactly one record, whether that record says what is true today, and whether a person can act on it without checking something else first. Most CRM quality problems are failures of the first, and they create the second and third.

This page is about a specific and common version of the problem: a CRM that holds tens or hundreds of thousands of companies, a team that needs new accounts every week, and a situation where most apparently new companies turn out to be already in the system while the existing records are too poor to hand to anyone.

Those feel like two problems. They are one, and the fix for both starts in the same place.

Why are your new companies already in the CRM?

Because you are matching on name. Company names vary in punctuation, legal suffix, trading name and spelling, so the same business arrives repeatedly looking new. Every near match that slips through becomes another record, and the duplicate rate compounds with every import.

A GTM engineer describing exactly this situation on a French dataset of more than 100,000 companies got a reply that named the mechanism precisely: name matching is why new companies keep turning out to be in the CRM already, and why the bad records feel unusable. One cause, two symptoms.

Consider how many ways one company can be written. With and without a legal suffix. With an ampersand or the word and. With an accent or without. As a trading name rather than a registered one. After a rebrand. After an acquisition, under the parent. A fuzzy match catches some of these and introduces false positives of its own, which is its own kind of damage.

The answer is not better fuzzy matching. It is matching on something that does not vary.

How do you build a genuinely greenfield list?

Subtract what you already hold. Filter the register by industry code and size band to get everything that could be a customer, then remove every registration number already in your CRM. What remains is genuinely new, and it is the only list worth paying to enrich.

The sequence, as described by a practitioner working on French data and generalised.

One. Backfill registration numbers onto your existing records, so you know what you hold in a form you can compare.

Two. Pull the register filtered to your industry codes and size bands. This is your addressable market as the government defines it, which is a more complete starting point than any vendor list.

Three. Subtract. Everything in the register that is not in your CRM is genuinely new.

Four. Re-run it monthly. The difference between runs gives you new company formations and companies crossing into your size band, which is a prospecting signal most teams buy and few generate themselves.

Five. Enrich and buy contacts on that delta only.

The last step is where the savings are. Most teams enrich the whole list because they cannot tell which part of it is new, which means paying repeatedly for companies they already hold.

Should you clean first or source first?

Clean first, almost always. Practitioners in this situation are close to unanimous: adding records to a system full of duplicates makes the problem worse and hides it at the same time. A week of cleaning usually produces more assignable accounts than a month of sourcing.

“If the CRM's full of junk data, no amount of new sourcing fixes the real problem. I'd spend a week cleaning what's already there before chasing fresh leads, otherwise you're just burning 500 slots a week on accounts that look new but are probably duplicates with misspelled names.”

A second reply in the same thread made the economic version of the argument: you are trying to solve a problem by throwing more money at it rather than fixing the root issue. Their suggestion was to ask what the data already in the CRM can tell you about which existing companies are worth targeting, which is a different and cheaper question than where to find more.

It is worth being concrete about what that means. In a CRM of 100,000 companies, it is unlikely all of them are customers or have been worked properly. Some were touched once by someone who has left. Some were disqualified for a reason that no longer applies. Some are excellent fits that nobody has ever called. Finding those is a query, not a purchase.

How do you deduplicate what you already hold?

Backfill the stable key, group by it, then merge deliberately with rules about which record survives. Do it in a staging copy, keep an audit of every merge, and accept that a residue will need human judgement. Automated merging without review is how a duplicate problem becomes a data loss problem.

A sequence that works on a large messy base.

Normalise before matching. Lowercase, strip legal suffixes, remove punctuation and accents, normalise domains to the registrable part. This alone surfaces a surprising share of duplicates.

Match against the register. Resolve each normalised name and domain to an official registration number. Where it resolves confidently, store it. Where it does not, flag it rather than guessing.

Group and rank. Within each group, decide which record survives by explicit rules: most recent activity, most complete, oldest created, whichever fits your operation. Write the rule down, because the exceptions will be argued about.

Preserve history. Merge activity and notes rather than discarding them. The reason a record is valuable is usually the history attached to it, not the fields.

Keep the residue. Some records will not resolve: sole traders, very new companies, foreign entities, anything misspelled beyond recognition. Flag them as unresolved rather than forcing a match. A known unknown is manageable, a wrong match is not.

Then prevent recurrence. None of this holds unless new records require the key on creation. A one off cleanup without a prevention rule means doing this again in eighteen months.

How do you stop duplicates coming back?

Resolve the key at the point of creation, not afterwards. Every route that creates a company record, forms, imports, integrations and manual entry, should attempt resolution and either attach an existing record or create one with a key. Without this, a cleanup decays from the day it finishes.

The routes that create records in a typical B2B company, and what each needs.

Inbound forms. Resolve on submission from the email domain. A form that creates a fresh company record for every submission will rebuild your duplicate problem faster than anything else.

List imports. The largest single source of duplicates. Run the resolution step on the file before import rather than after, and report how many rows matched existing records. That number is usually higher than whoever supplied the list expects.

Integrations. Any tool writing into the CRM needs the same rule. A sales engagement platform or a marketing tool creating records with its own matching logic will quietly undo your work.

Manual creation. Search before create, with the search matching on normalised values rather than exact ones. Most CRMs make this configurable and most configurations leave it on exact match.

Then measure it. A monthly count of newly created duplicate groups tells you whether prevention is working, and it is a far better data quality metric than total record count. If that number is near zero, the pipeline is doing its job. If it is climbing, one of the four routes above has no resolution step.

What if your market has no open register?

Fall back to the domain as the key, and accept a lower ceiling. Normalised domain resolves a large share of B2B companies, fails on multi domain groups and on companies that share one, and is still far better than matching on name. Where a paid register exists and the market matters, buying it is usually cheap relative to the duplicate cost.

Several large European markets have restricted or paid registers, and the United States has no single free national source for the state level registrations where most companies sit. So this situation is common rather than exceptional.

What to do instead, in order of preference.

Use a paid register for that market only. You rarely need global coverage. If eighty percent of your pipeline is in two countries, buy those two and use domain matching elsewhere.

Normalise domains properly. Strip protocol, www and tracking, reduce to the registrable domain, and keep a list of known exceptions for groups that genuinely share one. This is an afternoon of work and it resolves most of what name matching misses.

Use a global identifier where entities have one. Larger companies and anything in financial markets frequently carry one, and lookup is free. Coverage is a minority of companies and heavily skewed to the large ones, which may be exactly your target market.

Accept an unresolved bucket. Sole traders, very small companies and recent formations will not resolve anywhere. Flag them, do not force a match, and review them as a group rather than letting them pollute the main base.

The point is not perfect resolution. It is replacing name matching with anything more stable, because almost anything is.

What should you refresh, and how often?

Refresh company level fields from live sources on a schedule, and person level fields only when you are about to use them. Company fields change slowly and can be refreshed in bulk cheaply. Person fields decay fast and refreshing them in bulk is how enrichment budgets disappear.

A workable cadence for most B2B companies.

Monthly, from the register. Status, size band, industry code, registered address. These come free where the register is open and they catch companies that have closed, changed size band or been acquired.

Monthly, from the company's own website. What they sell, their technology stack, whether they publish pricing, whether they are hiring. All free to read, all current because they maintain it, and all useful for scoring.

Before outreach, per person. Email validity and the mail provider. Checking that a domain can receive mail at all costs nothing and protects your sending reputation, which is the one asset in outbound you cannot repurchase.

On demand only, for contacts. Direct dials and personal emails, bought for the accounts you are actually working this quarter rather than across the whole base.

The principle underneath: refresh in proportion to how fast a field decays and how soon you will use it. Most enrichment overspend comes from refreshing fast decaying fields across records nobody will touch for a year.

Can you automate all of this?

Most of it, and you should, because a manual cleanup decays from the day it finishes. The parts worth automating are the key resolution, the register refresh, the greenfield delta and the duplicate detection. The part to keep human is the merge decision on ambiguous records.

What a working setup looks like in practice.

A resolution service. Given a name and a domain, return a registration number and a confidence level. Called on record creation and run in batch over the existing base.

A scheduled register sync. Monthly pull of your industry and size filters, diffed against last month, producing new formations and band crossings as a feed rather than a project.

A duplicate queue. Candidate groups surfaced for review rather than merged silently, with the high confidence ones merged automatically by an explicit rule.

A refresh job. Company level fields updated on a schedule from register and website, with a timestamp per field so you can tell what is stale.

None of this is exotic engineering. It is a handful of scheduled jobs and a resolution step, and it is the kind of work that pays back continuously rather than once. It is also the kind of work that sits in a backlog forever, because it is nobody's quarterly objective.

How do you measure CRM data quality without inventing a score?

Measure four things a person can act on: the duplicate rate, the share of records that resolve to a stable key, the share a rep can work without checking another system, and the count of new duplicate groups created each month. Composite quality scores out of a hundred are satisfying and drive no decisions.

Duplicate rate. Groups of records resolving to the same entity, as a share of total records. Measure it once properly and you will have the number that justifies the project.

Resolution rate. What share of your base carries a confident stable key. This is the ceiling on everything else, because records that do not resolve cannot be deduplicated or refreshed automatically.

Actionability. The share of accounts where a rep has what they need without opening another tab. Harder to measure, closest to what you actually want, and best sampled by asking five reps to work ten accounts and counting.

New duplicate groups per month. The prevention metric. Falling means the resolution step at creation is working. Climbing means one of your inbound routes has no check.

What we would not track: total records, which rewards exactly the behaviour that causes the problem; completeness percentage across all fields, which counts fields nobody uses; and any vendor supplied quality grade, which is calibrated to make their product look necessary.

Review these quarterly rather than monthly. Data quality work moves slowly and a monthly cadence produces fiddling rather than decisions.

What should you have ready before starting?

An export of your company records, agreement on who decides the merge rules, and an honest answer about which markets actually matter. Most of the scoping difficulty is organisational rather than technical, and the technical part cannot start until those three exist.

The export. Company records with whatever identifiers exist, creation dates, owner and last activity. The last two matter more than people expect, because they decide which record survives a merge.

The decision maker. One person who can settle entity versus group, which record wins, and what happens to unresolved records. These are business decisions wearing technical clothes, and a project without that person stalls in week two.

The markets that matter. Register availability varies enormously by country, so knowing that most of your pipeline sits in two markets changes the approach completely. Teams frequently scope for global coverage they do not need and then stall on the hardest country.

What you do not need: a target quality score, a tooling preference, or a cleaned sample. We would rather see the data as it actually is, because the mess is the requirement.