Why every CRM cleanup project regresses within six months

I’ve seen this pattern at five companies now. RevOps lands a budget for a CRM cleanup project. A consultancy or contractor comes in, runs a six-week sprint, and ships an audit that closes 3,000 duplicates, normalises 60% of the free-text fields, and produces a 40-page report with a quarter’s worth of recommendations. The data team celebrates. Reporting improves measurably. Forecasts get cleaner for a couple of pipeline reviews. The team moves on to the next project.

Six months later the duplicates are back, the free-text fields have drifted, and the deck used to explain why pipeline numbers don’t tie is the same one used six months earlier.

Why projects regress

The audit fixes the existing data. It doesn’t fix the system that produced the bad data in the first place.

Imports keep happening with mismatched formats. Web forms collect free-text in fields that should be picklists. AEs working a deal off-platform during a sprint never sync the record back, and the older the deal gets, the less likely anyone is to clean it up. Marketing operations ships a new campaign with its own field conventions because nobody told them the conventions had been re-standardised three months ago. Each of those is a fresh source of drift, and none of them got addressed in the project scope.

The honest framing is that cleanup is maintenance, not a project. Projects have an end date and the work stops happening. Maintenance is a continuous load that someone owns forever, and pretending otherwise is what produces the next cleanup project.

What “continuous” actually looks like

Hygiene holds between cleanups when three pieces are in place. They’re usually missing.

A rules layer that runs on write. It validates the format, checks against the picklist, fuzzy-matches against existing accounts, and either accepts the record or routes the exception to a queue. Without it, new drift arrives faster than old drift gets resolved, and the queue is bottomless from day one.

An owned exception queue, with a named person and a recurring slot. Not “as part of their role” abstractly — actually on someone’s calendar, every Tuesday at 10am. The companies that hold their data quality between cleanups all have this. The ones that regress treat the queue as best-effort, which means it gets the time that’s left over after everything else, which means it gets no time.

Data quality reported as a first-class metric — duplicate rate, field completeness, stale-record count — on a dashboard the RevOps lead reviews on a normal cadence. If those numbers go invisible between projects, you’re already scoping the next cleanup by the time anyone looks again.

Our CRM data cleanup playbook is built around making those three pieces sustainable without standing up a new headcount line.

The version of this work that doesn’t regress is the one that prevents drift at the point of entry. The cleanup version always regresses.