Every CRM has data problems and most organisations have made peace with theirs. Duplicate accounts, close dates that have been pushed four times, contacts who left eighteen months ago, fields that were mandatory in 2021 and are now filled with a full stop.
This was tolerable because people compensate. A rep glancing at a record knows which parts to believe. That compensation is invisible, unrecorded, and entirely absent when an agent reads the same record.
Judgement was doing more work than anyone noticed
When a salesperson opens an opportunity, they perform a silent assessment. This close date is aspirational. This contact has not replied since spring. This account is the same company as that one under a different spelling. The stage says negotiation and the last note says they went quiet.
None of that is written down. It lives in the head of whoever knows the account, and it is applied automatically every time the record is read.
An agent has only what is in the fields. It will treat a close date from March as a genuine forecast input, count two spellings of one company as two opportunities, and describe an account as active because nobody changed the status. The output will be confident and internally consistent and wrong in ways that are hard to see, because it looks exactly like a correct answer.
The four problems that matter most
Not all data quality issues cause equal trouble here, and cleaning everything is not realistic. Four categories account for most of the damage.
Duplicates distort every count. Any figure derived from record counts, pipeline value or account coverage is wrong by an amount nobody can estimate, and an agent reporting those figures presents them as fact.
Stale dates drive false urgency and false forecasts. A close date in the past on an open deal is a contradiction a person resolves instantly and an agent frequently does not.
Dead contacts cause outbound errors that reach customers. An agent drafting a follow up to somebody who left the company two years ago is the kind of mistake that gets noticed externally rather than internally.
Abandoned fields are the quiet one. A field nobody has maintained since a process changed still contains values, and an agent has no way to know that the data stopped meaning anything in 2023.
Of those four, duplicates are the one we are asked about least and the one doing the most damage. The others corrupt a record; duplicates corrupt every total built on top of them.
Read More - Ninety-Five Percent of Executives Say Roles Are Changing. Your Tools Assume They Are Not
Fix what feeds decisions, not everything
A full data cleanse is a project most organisations start and few finish. The productive version is much narrower.
List the fields the agent will actually read. Usually far fewer than the record contains: account name, stage, value, close date, owner, last activity. Clean those, and accept that the rest can stay untidy for now.
Then deduplicate accounts, which is the highest value single action because it corrupts aggregate numbers rather than individual records. Most CRMs have tooling for this and most organisations have never run it.
Then apply a staleness rule. Anything with no activity for a defined period gets flagged or closed rather than sitting open and being counted. This is unpopular because it shrinks the reported pipeline, and shrinking a pipeline that was never real is the point.
Underneath all of it is the adoption problem that produced the mess, which we covered in why CRM adoption fails. Cleaning without addressing that produces a tidy system that degrades again within a year.
Make the agent say what it does not know
The design decision that reduces most of this risk is to have the agent express uncertainty rather than smoothing over it.
An agent that reports "pipeline value 2.4 million" is stating a fact. One that reports "2.4 million, of which 600 thousand sits on deals with no activity in 90 days" is telling you something useful and honest. The second version requires no better data, only a willingness to surface what the data actually looks like.
The same applies to individual records. Flagging that a contact has not responded in six months, or that a close date has moved three times, costs nothing and turns a confident summary into a usable one.
Where the underlying record is too poor to work with, the agent should decline rather than produce something. An output labelled insufficient data is far more valuable than a plausible summary assembled from a stale record, and it also tells you exactly where the cleanup is needed.
Measure the mess before you start
Run four counts before any cleanup so you know what you are dealing with and can tell whether the work helped.
How many open opportunities have a close date in the past. How many accounts appear more than once under variant names. How many contacts on open deals have had no activity in six months. How many required fields contain values that are obviously placeholders.
Most organisations running this for the first time find numbers that make the current forecast difficult to defend, which is uncomfortable and better known than not. It also gives you a defensible reason to spend a week on cleanup, which is otherwise a hard sell.
Activity data carries a similar gap, where the system records what was sent rather than what arrived, covered in why your CRM counts the wrong number.
If your CRM is custom or heavily configured, our CRM development team treats these constraints as part of the schema rather than as a periodic cleanup exercise, because validation at entry is what stops the mess returning.
We run these four counts before proposing any cleanup, because the numbers make the argument better than we can. A forecast nobody can defend is a stronger case for a week of work than any description of good practice.
Frequently Asked Questions
Do we need perfect data before using an agent?
No, and waiting for perfect data means never starting. You need the specific fields the agent reads to be reliable, and you need the agent to surface uncertainty rather than hide it. That is a much smaller job than a full cleanse.
What is the single highest value fix?
Deduplicating accounts. Duplicates corrupt every aggregate number rather than one record, so the damage compounds across every report and forecast. It is also usually the most automatable of the four.
Our pipeline will shrink if we clean it. How do we handle that?
Present it as accuracy rather than loss, and do it before anyone commits to a number based on the old figure. A pipeline containing deals that closed themselves through inactivity was never real, and discovering that at quarter end is considerably worse than discovering it now.
Should we let the agent clean the data itself?
For clearly mechanical work such as formatting and obvious duplicates, with review. Not for judgement calls like whether a deal is genuinely dead, because that requires knowledge the record does not contain. An agent that closes real opportunities is a worse problem than the one you started with.
How do we stop it degrading again?
Validation at entry rather than cleanup afterwards. Required fields that are genuinely required, formats enforced, duplicate detection at creation. Cleanup without prevention buys you about a year, and then you run the same project again.
What about historical records we cannot verify?
Mark them rather than deleting or guessing. A record flagged as unverified is honest and usable; a record silently treated as current is neither. Agents can then exclude flagged records from anything that feeds a decision.
How long should a realistic cleanup take?
For the fields that matter, a week or two for most mid sized pipelines, mostly spent on deduplication and staleness rules. Multi month cleanups usually indicate the scope expanded to everything, which is the version that does not finish.
Talk to our team if an agent is about to start reading a pipeline nobody has cleaned in years.