Data Quality for Revenue Teams: The Standard

Why cleanups always fail

The standard response to bad CRM data is a cleanup project: dedupe, normalise, fill the gaps, declare victory. Twelve months later the data is as bad as it was, and the same project gets funded again.

It fails because data decays continuously and the cleanup addressed the stock rather than the flow. People change jobs, companies get acquired, titles change, and new records enter through five different paths with no validation. Roughly a quarter to a third of B2B contact data goes stale every year regardless of what you did last January.

The six dimensions

A single data quality score is useless because it cannot tell you what to fix. Measure six things separately.

Note the qualifier on completeness. Measuring completeness across every field in the CRM produces a low score and no useful signal, because most fields do not matter. Measure it only on the fields a routing rule, a report, or a human decision actually depends on.

Prevention beats cleanup

Fixing a bad record after it enters costs roughly ten times what preventing it costs, and prevention is mostly configuration rather than effort.

1. 01
   Validate at every entry point

   Forms, imports, API writes, and manual creation. Email format, domain validity, phone format, and picklist conformance. Most systems validate the web form and leave the other three paths wide open.

2. 02
   Match before create

   Deduplication rules that run at creation rather than as a nightly cleanup. Preventing a duplicate is trivial; merging one after it has activity, tasks, and an opportunity attached is not.

3. 03
   Enrich rather than ask

   Company size, industry, and technographics should be appended automatically. Asking a buyer to type them costs conversion and produces worse data than you could have bought.

4. 04
   Constrain free text

   Picklists wherever a fixed vocabulary exists. Free-text industry fields produce forty variants of the same value within a year, and no report can group them.

5. 05
   Require only what a decision needs

   Every required field a rep cannot confidently answer manufactures fake data. A required field filled with nonsense is worse than an empty one, because it looks populated.

The recurring jobs

The reconciliation job is the one that earns its keep fastest. Comparing record counts between systems daily catches silent sync failures within a day rather than within a quarter, which is the difference between a fixable incident and a lost quarter of decisions.

Setting a refresh rate that matches decay

Fields decay at very different rates, so a single refresh schedule either wastes money on stable fields or leaves volatile ones stale.

Cache every enriched value with its provider, confidence, and timestamp so refresh can be selective. Re-buying data you already hold is the most common silent cost leak in a revenue stack — the mechanics are in waterfall enrichment.

Who owns it

Data quality without a named owner does not happen, and the name has to be a person rather than a team. The practical split that works:

• RevOps owns the standard — which fields matter, what the thresholds are, and what the recurring jobs do.
• A named individual owns each recurring job, including responding when its alert fires.
• Each function owns its own completeness score for the fields its process depends on, reported monthly and visible to everyone.
• Nobody owns quality in the abstract, because a responsibility everyone shares is one nobody executes.

Publishing completeness by team monthly does more for data quality than most technical interventions, for the unglamorous reason that people fix what is visibly attributed to them. The wider design principles are in building scalable revenue systems.