The short answer: stop trying to make the whole database correct. Make the fields that decisions read correct, keep them correct continuously rather than quarterly, and fix them where the work already happens instead of in a spreadsheet somebody exports on a Friday. Everything else in a CRM can be wrong for a year without costing anyone anything, and pretending otherwise is why cleanup projects get abandoned in week three.
Why the cleanup project always loses
A data cleanup is a one-time act against a continuous process. The moment it finishes, reps carry on working the way they worked before, and the data starts decaying again from the same causes: a close date pushed in someone's head and not in the record, a champion who changed jobs, an amount agreed on a call and never updated, a contact whose email bounces.
So the project has to be repeated, and the second run is harder than the first because nobody believes in it any more. The honest reading is that the cleanup was never the fix. It was a way of paying down interest on a debt that keeps being issued.
The decay is not a discipline problem. A rep who does not update a close date is not being lazy; they are correctly judging that the update costs them two minutes and buys them nothing. We wrote about that trade in the CRM update problem. Any data quality plan that depends on people finding the discipline they did not have last quarter is a plan that has already failed once.
The only test worth applying to a field
Before you fix anything, ask one question about the field: does a person or a system make a decision by reading it?
If the answer is no, its being wrong costs nothing. Industry codes filled in years ago by an importer, a lead source nobody segments on, a job title that says "Manager" when it says "Senior Manager" on a business card: these are untidy, not expensive. Fixing them feels productive and buys nothing.
If the answer is yes, being wrong is expensive in a way that is usually invisible until the end of the quarter. Four fields carry almost all of that weight on a B2B deal.
| Field | The decision it feeds | What being wrong costs |
|---|---|---|
| Close date | The forecast, and what a manager chases this week | A number the leadership team commits to that was never real |
| Amount | Coverage, quota attainment, commission | Pipeline that looks sufficient and is not |
| Stage | Whether the deal gets attention at all | A deal in Proposal that has not been touched in five weeks, invisible because the stage says it is fine |
| Who is actually engaged | Risk, and who to call when it stalls | Chasing a contact who left the company two months ago |
That is the fix list. Not two hundred fields. Four, plus whatever a particular team genuinely reads. Anything that does not feed a decision goes on a list called "later" and stays there.
Fix it where the work is, not in an export
The second reason cleanups fail is location. A spreadsheet of suspect records is a document, and documents get read by one person once. A correction has to be offered where the person is already working, at the moment they are already thinking about that deal, with the evidence next to it, and it has to take one click.
That is the shape we build to. Something reads the record continuously, notices that the close date is three weeks past and the deal is still open, or that the amount in the record and the amount in the last proposal do not match, and puts a specific proposed correction in the queue with the reason it thinks so. A person approves it or does not.
Two properties of that arrangement matter more than the detection itself. The correction carries its evidence, so a person can disagree with it on the facts rather than on instinct. And nothing changes the record on its own, which is what makes the queue safe to leave running: the worst case is a suggestion somebody declines, not a database quietly rewritten overnight.
Duplicates are a different problem, and they are worse
Duplicate accounts and contacts are usually filed under data quality, and they behave nothing like a wrong field. A wrong close date makes one number wrong. A duplicated account splits a customer's history in half, so the engagement looks thinner than it is, the open pipeline against that customer looks smaller than it is, and two reps can work the same company without either seeing the other.
They are also the one class of problem where the automatic fix is genuinely dangerous. A merge is hard to undo, and a confident merge of two companies that share a name and nothing else destroys real history. So duplicates get found automatically and merged by a person, deliberately, with both records on screen. The asymmetry is the point: finding is cheap and reversible, merging is neither.
Measure the fix, or it is a feeling
A data quality effort with no number attached is indistinguishable from tidying. Two measurements are enough, and both should be readable without anybody preparing them.
- How stale is the deciding data? The share of open deals whose close date is in the past, or whose stage has not changed in longer than that stage usually takes. If that share is falling, the effort is working.
- How often is the suggestion right? Of the corrections offered, how many did a person accept? A low acceptance rate is not a reason to stop; it is a reason to fix the detection, and it is the only honest way to find out whether the system is helping or generating homework.
The second one is the one people skip, and it is the one that keeps the whole thing accountable. A system that proposes corrections and never checks whether they were accepted is asking a team to trust it on the strength of its own confidence.
The version of this that actually holds
The durable answer to CRM data quality is not a better cleanup. It is that the record stops depending on somebody remembering to update it, because the system reads what happened (the calls, the email threads, the meetings) and proposes the update itself. That is the argument behind a CRM that updates itself, and it is the difference between data quality as a project and data quality as a property.
It also changes what the forecast is worth. A forecast built on fields that decay quietly between reviews is a forecast that is wrong for reasons nobody can see; the same numbers built on a record that maintains itself can at least be argued with. We went through how that goes wrong in why sales forecasts are wrong by Thursday.
What this does not do
None of this invents information that was never captured. If a conversation happened on a phone nobody logged and in an inbox nobody connected, no amount of monitoring will know about it, and the record will be missing exactly what it was always missing. Detection also has a false positive rate: a deal legitimately paused by a customer's budget freeze looks a great deal like a deal a rep has abandoned, and telling those apart is a judgment a person makes, which is precisely why the correction is proposed rather than applied. Treat the queue as a shortlist of things worth two minutes of attention, not as a verdict.
Questions people ask about this
Where do we start if the data is already bad?
With the open deals only, and with the four fields above. Historical closed deals can stay as they are; nobody is making a decision on them this week, and the effort of correcting them is enormous. Fix what the current quarter reads, then let the continuous process keep it fixed, and revisit history only if a specific analysis needs it.
Should we make fields required to force the data in?
Required fields produce filled fields, not true ones. A rep who has to pick a value to save the record will pick one, and now the data is wrong and confident instead of missing and honest. Missing data at least announces itself. Use required fields for the two or three things that genuinely cannot be inferred, and infer the rest.
Can this run against the CRM we already have?
That is the intended shape: read the existing system, propose corrections, and let a person decide, rather than asking a team to move everything first. What we would not claim is that this is free of work. Connecting a CRM and agreeing which fields matter is a real afternoon, and anyone who tells you otherwise is selling the demo rather than the deployment.
How often should the check run?
Continuously, and the results should be read daily by whoever owns the number. The point of moving from a quarterly project to a running process is that the correction arrives while the deal is still live and the answer is still in somebody's head. A stale-data report that lands after the quarter closes is history, not hygiene.