CRM Data Cleanup Services: What a 40,000-Row Job Needs

Why your last cleanup did not hold

Most cleanups fail because they are a one-off import fix. The duplicates, free-text fields and conflicting owners return through the same forms, integrations and manual entry that created them in the first place.

If you are comparing CRM data cleanup services, start by asking what stops the mess recurring. Bad data is expensive in general: IBM's estimate, reported by Thomas Redman in Harvard Business Review in 2016, put the annual cost to the US economy at $3.1 trillion.

The mess comes back through the same doors

A typical 40,000-row CRM has at least four intake paths: web forms, a marketing automation sync, sales imports from event lists and reps typing records by hand. Each one applies a different convention for company names, phone formats and country values.

A one-time dedupe fixes the rows that exist today. It does nothing about the next event list. Consider a trade-show upload of 1,200 contacts: if 300 already exist under slightly different company names, a single import recreates a quarter of that list as duplicates, and every one of them arrives with a fresh owner assignment and a new lead source value.

Routing reads the dirty fields

Lead routing usually keys on country, company size, industry or an account owner field. Those are the fields that are messiest.

When "United States", "USA" and "US" all exist, a territory rule written for one of them quietly drops the others into a default queue. Cleaning the data without checking which routing rules read which fields is how a tidy database produces stranded leads.

Deduplication rules that survive contact

A dedupe rule survives only if it is written down, tested against a sample you reviewed by hand, and tiered by confidence. Exact matches merge automatically. Fuzzy matches go to a human queue.

Anything that merges silently on a guess will eventually merge two different customers.

Match keys, in order of trust

Start with keys that are unlikely to collide: email address for contacts, normalised domain for companies. Then add weaker keys: phone in E.164 format, a lowercased company name with suffixes like "Ltd" and "Inc" stripped, and postal code.

Score matches rather than treating them as yes or no. An email match merges. A name-plus-city match goes to review.

Survivorship: which record wins

When two records merge, you must decide which value survives per field. Common rules: most recently updated wins for phone and title, oldest wins for created date, and any value touched by a human beats one set by an import.

Salesforce's duplicate management lets you alert or block on matching rules, and Lightning merges up to three records at once. For 40,000 rows that is too slow, so bulk merges run through the API with survivorship logic written in code.

HubSpot's deduplication works on email for contacts and domain for companies by default. Anything fuzzier is your job, and it is worth confirming the current behaviour in your own portal before you plan around it.

Write the survivorship table as a spreadsheet before any code. One row per field, one column for the winning rule, one for the tiebreaker. A reviewer who is not an engineer should be able to read it and say "no, the newer phone number is wrong here" before a single record is changed.

Test the rules on a sandbox copy

Pull a 2,000-row sample, run the rules, and read the merges yourself. Look for false positives: two people sharing a family email, two branches of one bank sharing a domain, a consultant at a client's address.

Fix the rules, rerun, and only then touch production. Take a full export first, because merges in most CRMs are hard or impossible to reverse.

Enrichment: what to buy and what to infer

Buy facts you cannot derive: company size, industry codes, verified emails, funding. Infer what your own data already implies: country from phone prefix, region from postal code, domain from email. Buying everything wastes money, and inferring everything bakes in guesses.

Buy firmographics, infer geography

Third-party providers are strongest on firmographics: employee count, revenue band, industry classification. Your own records are strongest on relationships: who talked to whom and when.

Inferring is cheap and auditable. A "+91" prefix tells you India. A work email domain tells you the company. Write each inference as a rule so you can explain it later. Know the limits too: a "+1" prefix covers both the US and Canada, so it cannot settle a territory rule on its own, and a free-mail domain such as gmail.com tells you nothing about the employer.

Treat every enriched value as a claim with a source

Store the provider, the date and a confidence flag next to each enriched field. Without that, you cannot tell a rep-typed value from a vendor-supplied one, and survivorship rules cannot protect human edits.

Decay matters too. Plan to re-verify emails and job titles on a schedule, because people change jobs constantly.

Order of operations is dedupe first, enrich second, a fuzzy dedupe pass third. Enriching duplicates means paying twice and merging conflicting values later. Good CRM data enrichment on a clean base costs less and produces fewer disputes.

Routing and ownership after a merge

A merge picks a surviving record, and the survivor carries its owner, territory and queue with it. If the wrong record survives, a lead moves between reps or lands in a default queue. Define ownership rules before the first merge.

Freeze routing during the merge window

Pause assignment rules, round-robin queues and automated sequences while bulk merges run. A merge that fires an "owner changed" workflow can send hundreds of notification emails and restart nurture sequences for contacts who were mid-conversation.

Salesforce API loads can set a header to bypass duplicate rules, and many teams turn off flows for the integration user. Decide this explicitly and switch everything back on afterwards.

Ownership rules for the merge

Use an explicit order: an open opportunity's owner wins, then the owner of the most recent activity, then the account owner, then a named fallback queue.

Run a before-and-after report by owner. Counts per rep should change only where you expected. If a rep who owned 900 records now owns 40, find out why before anyone notices on Monday.

Rebuild the routing tests

Keep a short set of test leads covering each territory and size band. Submit them through the form after the cleanup and confirm each lands with the right owner. This takes an afternoon and catches the failures that matter. Teams that need this wired into wider ops automation often pair it with AI workflow automation for assignment and follow-up.

Keeping it clean: the ongoing job

Cleanliness is maintained by preventing bad rows at entry and sweeping weekly or monthly for what slips through. Validation on forms, a controlled picklist for country and industry, and a scheduled dedupe job do most of the work.

Stop it at the door

Make country, industry and lead source picklists rather than free text. Normalise phone numbers and lowercase emails on write. Require a company domain on any record created by an import.

These are small configuration changes. They remove the largest source of drift, which is humans typing slightly different versions of the same value.

Sweep on a schedule

Run a scheduled job that flags new duplicate candidates, records missing required fields and enriched values older than your decay window. Send the output to a named owner, not a shared inbox.

Track three numbers over time: duplicate rate, percent of records with a valid owner, and percent of leads that reach a human within your response target. If the trend turns down, the intake paths have changed.

Data engineering work like this is mostly pipeline plumbing: scheduled jobs, validation and reporting that outlive the project that built them. Where the CRM is one of several systems that disagree, our solutions cover how those pieces fit together.

Effort and timeline for 10k / 50k / 200k records

Effort grows more slowly than record count because rules are written once, but it grows faster with the number of intake systems and routing rules. The ranges below are planning assumptions, not commitments. Scope is set after a discovery call that profiles your data.

Viithiisys has been building software since 2007 and has shipped 500+ projects for clients across six countries, including Paytm, Snapdeal, Shiprocket and Vikram Solar. That volume of integration work is the reason we scope per engagement instead of publishing a rate card.

Costs depend on how many systems feed the CRM, so the first step is a fixed-scope discovery, not a quote from a spreadsheet. If routing is where your current process breaks, the broken workflow assessment maps which rules read which fields before anyone merges a record. For wider system questions, you can also contact the team.

For salesforce data cleanup at the 200,000-record end, plan on loading through the Bulk API rather than the UI, and budget the freeze window as a business decision, not a technical one.