Every RevOps team has run the project. Someone exports the account table, finds that a third of the industry values are blank, that the same company exists four times under four spellings, and that half the contacts in one territory left their jobs a year ago. A cleanup sprint follows: dedupe, standardize picklists, buy an enrichment refresh, add validation rules. Six months later the same report shows the same problems, and the next budget cycle funds the same project again.
The usual diagnosis is discipline. Reps do not enter data, admins do not enforce rules, and nobody owns hygiene. That diagnosis is half right. The other half is structural: most CRM data quality issues come from asking the CRM to be the system of record for research. A CRM is good at recording what your team did. It is bad at holding what is true about the outside world, because the outside world changes every week and a field only changes when someone edits it.
This article sorts the common issues by where they come from, explains why cleanup projects keep losing to them, and argues for a different split: keep research traceable to its source outside the CRM, and sync only the conclusion a rep needs to act on.
The issues everyone lists, and what the lists leave out
Read the top guides on this topic and the inventory is consistent: duplicates, incomplete records, inconsistent formatting, outdated fields, and decay. The fixes are consistent too: governance, validation rules, deduplication tools, scheduled enrichment, and a named owner for data quality. None of that is wrong, and a CRM without it is worse than one with it.
The scale of the problem is not in dispute either. Validity surveyed 602 CRM users and administrators for its State of CRM Data Management in 2025 report. 76% said less than half of their organization's CRM data is accurate and complete. Workers spent an average of 13 hours a week hunting for basic information in the CRM, and 37% said staff regularly fabricate data to tell leaders what they want to hear.
What the standard lists leave out is a distinction between two kinds of data that live side by side in the same record:
- Activity data is generated by your own team: calls logged, emails sent, meetings booked, stage changes, closed dates. It is true the moment it is written and it stays true. Its quality problems are entry problems.
- World data describes the account from outside: industry, headcount, tech stack, who holds which title, what the company announced last quarter, whether it is hiring in the function you sell to. It is true on the day someone looked, and it starts going stale the next morning. Its quality problems are time problems.
Cleanup projects treat both kinds the same way, as fields to fill and validate. That works for activity data. It cannot work for world data, and world data is exactly what a rep needs to decide who to call.
Why world data decays inside a CRM
A field in a CRM holds one value. When it was written, by whom, and from what source are usually not stored next to it, and when they are, the history is short. Salesforce, for example, lets an admin track the history of at most 20 fields per object, and change data is retained for up to 18 months in the interface and 24 months through the API unless you buy the Field Audit Trail add-on. Every other field simply shows its current value with no record of where it came from.
Now apply that to people. The Bureau of Labor Statistics reported in its January 2026 employee tenure release that the median wage and salary worker had been with their current employer for 4.1 years. A median in the fours means a large share of any contact table has been at the company for much less, and those are the people most likely to move again. A contact record entered two years ago carries a title, a reporting line, and a set of priorities that may all belong to someone else now. The field does not know that. It still says VP of Sales.
Company facts behave the same way. A headcount band entered at import, a tech stack pulled from an enrichment vendor, a note that says "expanding into EMEA": each was a fair reading on its date, and none of them carries the date. A rep scanning the account six months later cannot tell a fresh fact from a stale one, so they either trust all of it or none of it.
This is the mechanism behind the Validity numbers. When people cannot tell which fields are current, they hunt, which is the 13 hours a week. When they are asked to fill fields they cannot verify, some of them guess, which is the 37%. Neither is a discipline failure. Both are a rational response to a system that asks for facts without keeping their provenance.
Why cleanup projects keep failing
A cleanup project is a snapshot. It makes world data accurate on one date and then starts the clock again. Three patterns make the decay faster than most teams plan for.
Enrichment overwrites without a trail
A scheduled enrichment job replaces field values with whatever the vendor holds today. That fixes some records and silently breaks others, for example when a rep had corrected a title by hand after a call. Because the old value and its source are gone, nobody can audit which version was right. The CRM looks cleaner and is less trustworthy. The CRM data enrichment guide covers when a refresh helps; the point here is that a refresh without provenance swaps one unknown for another.
Free-text fields become the research store
Reps who do real account research need somewhere to put it. The CRM offers a description field and a notes object, so the research goes there as prose: "new CFO from Stripe, talked about consolidating vendors on a podcast." That is the most valuable sentence in the record and the least maintainable. It has no link, no date, and no way to expire. A year later it reads as current.
The fields that matter are the ones nobody can validate
Validation rules work on structure: a picklist value, a phone format, a required field. They cannot check whether "Priority: High" still has a reason behind it. The fields that drive what a rep does next (priority tier, next step, why this account) are the ones with the weakest link to evidence, so they are the ones that drift furthest from the truth between cleanups.
The cost lands on selling time. Salesforce's research on 7,775 sales professionals found that reps spend just 28% of their time selling, with deal management and data entry among the tasks eating the rest. Some of that non-selling time is reps doing the research the CRM could not hold, then doing it again because the last round was not findable.
A different split: keep research at the source, sync the conclusion
The fix is to stop asking the CRM to hold something it was not built to keep current. Research belongs next to its sources, where every claim carries a link and a date. The CRM gets the conclusion: a short, dated verdict a rep can act on, with a pointer back to the evidence.
| Question | CRM as research store | Research at the source, conclusion synced |
|---|---|---|
| What lives in the account record | Dozens of world-data fields plus free-text notes | A few fields: verdict, reason, date checked, link to the evidence |
| Where the evidence lives | Nowhere, or in a note without a link | With the research, each claim tied to the page it came from |
| How a rep knows it is stale | They cannot, unless they recheck everything | The date is on the conclusion, and anything past your window gets rechecked |
| What a refresh does | Overwrites fields and loses the old value | Produces a new dated conclusion; the old one stays auditable |
| What a cleanup project fixes | Everything, for a few months | Activity data only, since world data is not stored as fields |
In practice the synced conclusion is small. Four fields cover most teams:
- Verdict: call now, not yet, or skip.
- Reason: one sentence naming what changed at the account.
- Checked on: the date the research was done.
- Evidence link: where a rep or manager can see the sources behind the reason.
Those four fields are easy to validate (the date and the link are either there or not), easy to report on, and easy to expire. A dashboard that shows how many accounts in a territory have a verdict younger than 60 days tells you more about pipeline readiness than a completeness score across forty firmographic fields.
This is also where prospect list management gets simpler. A list stops being a table of attributes to keep accurate and becomes a set of names, each with a dated reason or without one.
The reason test: a quality check that measures what reps use
Completeness scores measure whether fields are filled. What a rep needs to know is whether there is a reason to call. You can measure that directly with a three-part test. A name is worth calling when you can say:
- What changed at the account: a new leader, a funding round, a hiring push in the team you sell to, a product launch, a public complaint about the problem you solve.
- Where you saw it: a link a manager could open.
- When it happened: a date recent enough to matter this quarter.
No reason, no call. The trigger events in sales guide covers what counts as a change worth acting on. Here is how to use the test as a data quality audit, by hand, this week:
- Pull 25 accounts at random from one rep's active book.
- Try to pass the reason test from the CRM alone. Count how many records contain a change, a source, and a date. For most teams the number is close to zero, and it is the honest measure of how much of the CRM supports a prioritization decision.
- Research the failures for ten minutes each: the company newsroom, recent job posts in your buyer's function, the leadership team's recent posts. Count how many pass after research.
- Write the passes back as conclusions, using the four fields above, and keep the links outside the notes field.
- Time it, then multiply minutes per account by the size of the book.
The first count is your real data quality number for prospecting. The gap between the first and second counts is how many reasons exist that nobody wrote down. The time is what it costs to close that gap by hand, every quarter, because the reasons expire.
Where software fits
Most tools in the stack answer a different question. A data vendor answers who exists and how to reach them. A sequencer answers how many touches went out. The CRM answers what happened after someone decided to act. None of them answers why this account, now, with a source you can check, and that is the question the audit above exposes.
That last question is the one PitchSmart is built for. It researches every lead on your list against what you sell and returns a plan for each one: who to contact, what to pitch, why now, and what to say, with a source attached to every claim. The plan can also say not yet, or skip, which is what the verdict field needs. Because every claim carries its source, the research stays checkable outside the CRM, and the conclusion is what a rep acts on. You can start a trial and run it on the same 25 accounts you audited by hand, then compare the two counts.
Whatever you use, hold it to the reason test. If the output cannot say what changed, where it was seen, and when, it is adding fields to the CRM and not reasons to the pipeline. For how this fits into the wider operating model, revenue operations best practices covers the decisions RevOps defends each year, and buying signals in sales covers which changes deserve a call.
What to change this quarter
- Split the record. Label which account and contact fields are activity data and which are world data. Stop adding world-data fields.
- Add the four conclusion fields (verdict, reason, checked on, evidence link) and report on their age, not on overall completeness.
- Stop enrichment from overwriting hand-corrected values without keeping the old value and its source.
- Retire the notes field as a research store. Research goes where its links live; the CRM gets the one-line reason.
- Run the reason test audit on one rep's book before funding the next cleanup project, and bring the three numbers to that conversation.
Your CRM does not have a data problem so much as a job description problem. Let it hold what your team did. Keep what is true about the world next to its sources, and give reps the dated reason. The list was never the problem. The missing reason was.
