A CRM gets dirty through its write path: every route by which a record can be created or changed. Forms, imports, enrichment vendors, sales reps typing, integrations syncing, and whatever automation somebody built two years ago and left running. Clean the database without changing that path and you have bought yourself about a quarter.
This is why hygiene projects have a characteristic shape. A big effort, a visible improvement, a slow decay, and a second project eighteen months later run by someone who does not know the first one happened.
Count your write paths before you clean anything
Most teams cannot say how many there are. The exercise takes an afternoon and it changes what you do next.
List every way a contact or account record can appear or change. A typical mid-size B2B setup has more than people expect:
- Website forms, often several, each with its own field mapping
- Manual entry by reps, which is where standardisation dies first
- CSV imports from events, webinars and lists
- Enrichment vendors writing back on a schedule
- Product signups syncing from the application database
- Integrations from support, billing, and marketing automation
- Automations built in-house, including ones whose author has left
Each of those is a place where a country can be written as "US", "USA", "United States" or blank. Cleaning normalises the four into one. It does nothing about the fact that tomorrow all four arrive again.
The three defects, and which one actually costs money
| Defect | What it looks like | Real cost |
|---|---|---|
| Duplicates | Three records for one account | Embarrassing, visible, and the one everybody fixes first |
| Inconsistency | Four spellings of one country | Quietly breaks every segment and every report built on that field |
| Staleness | A contact who left in 2024 | The expensive one. Decisions get made on it and nobody knows |
Duplicates get the attention because they are easy to see in a list view. Staleness gets none, because a stale record looks exactly like a good one. A territory model built on job titles that are two years out of date will produce a confident, wrong answer every quarter until somebody checks.
Fix the path, then clean once
The order matters, and it is the reverse of how these projects usually run.
- Pick the fields that actually drive decisions. Usually fewer than ten: the ones routing, scoring, segmentation and reporting depend on. Everything else can be messy without costing anything.
- Write down the allowed values for each. Not a convention in somebody's head. A written list, in a place the next person will find.
- Constrain every write path to those values. Picklists rather than free text, validation on the form, a normalisation step on every import and integration. This is the engineering work, and it is the half that lasts.
- Only then clean the history, once, against the same definitions the path now enforces.
- Instrument the decay. A weekly count of records failing the rules. If that number trends up, a write path is unconstrained and you will know which one.
Step five is the one that turns this from a project into a system. Without it, the only way you learn the CRM is dirty again is when a report looks wrong, and by then the decisions made on it have already been made.
When not to bother
Hygiene work is not free, and the honest version of this advice includes the cases where it does not pay.
If your CRM has under a few thousand records and one person touches it, this is over-engineering. The constraint is not data quality, it is that you have not got enough pipeline yet. Clean it by hand in an afternoon and revisit at ten times the size.
If the fields you would constrain are not driving any decision, leave them dirty. A tidy field that nothing reads is a project that cost money and returned nothing. The test is whether a wrong value in that field would change what somebody does.
If nobody will own the rules, do not start. This is the same standing obligation that sits under every other piece of the machinery: a constrained write path drifts the moment a new integration is added by someone who has not read the definitions. Cleaning without an owner buys a quarter. So does cleaning with an owner who leaves.
That last point is why this sits with the rest of the plumbing rather than apart from it. The question that decides a hygiene programme is the question that decides every automated workflow around it: not whether it can be built, but whether anybody will still be maintaining the definitions in March.
Questions people ask
How often should we run a CRM data audit?
Weekly, automatically, counting records that fail the rules. An annual manual audit tells you the size of a problem that has already cost you a year of decisions.
Should we buy a hygiene tool or build the rules ourselves?
Tools deduplicate and normalise well, and that is the cleaning half. Neither a tool nor a script decides which fields matter or what the allowed values are, and that decision is what makes the cleaning stick.
What is the difference between CRM hygiene and enrichment?
Enrichment adds data from outside. Hygiene governs what is allowed in and what gets corrected. Enriching into an unconstrained write path adds volume to the problem, at a per-record price.
Which fields are worth constraining?
The ones a wrong value would change a decision on: country, segment, owner, lifecycle stage, and whatever your routing reads. If you cannot name the decision a field feeds, it does not need governing.
How do we stop reps entering free text?
Remove the option. Picklists on the fields that matter, and accept free text everywhere else. Rules that depend on discipline fail quietly and blame the wrong people.
Or skip the search
Want the person who owns it after it ships?
If the work is a standing obligation rather than a bounded project, tell me which system you want built first. You get example profiles and a call with your pick before anything starts.
Placement runs through AYTalent. Engineers are employed and trained on the bench before they start with you.