Skip to content
createwithlogic

A working method

Clean up a contact database
without wrecking it

Most CRM cleanups fail the same way: someone runs a merge tool on live data, hopes for the best, and six months later the database is dirty again plus missing things. There is a better order of operations. It is the one I used to consolidate a database to 863,484 contacts with zero duplicates, verified by 8 of 8 QA checks before go-live. This page walks through it.

Why dirty data quietly costs money

Duplicate and inconsistent contact data is not a cosmetic problem. Sales embarrasses itself: two records for the same person means two reps reach out, or one rep reaches out with none of the context logged on the other record. Segments lie: if you cannot trust the answer to "how many VPs of Marketing do we have in Texas," every campaign built on that segment inherits the error. Deliverability suffers: mailing stale and duplicated addresses drives bounces, and bounces damage sender reputation for your whole domain, including the emails that matter.

Then comes the slow failure mode: the team stops trusting the CRM, exports to spreadsheets, and the spreadsheets become the real database. Now you have two dirty databases and no single source of truth. Cleanup is cheaper than that spiral, but only if it is done in an order that holds.

The order of operations that works

1. Normalize first. Bring every source into one canonical schema before comparing anything: lowercase and trim emails, standardize field names, collapse free-text labels like industries and titles into one consistent set. Deduplication before normalization misses matches, because "Jane.Doe@Acme.com" with a trailing space and "jane.doe@acme.com" read as two different people to an exact-match pass.

2. Deduplicate on email, with a fuzzy-name fallback. Exact email matches merge automatically; that pass is safe and does most of the work. Then a second pass fuzzy-matches on name plus company to catch duplicates with different or missing emails, with a conservative threshold and validation on the borderline cases. Merges are additive: fill the empty fields of the surviving record, never blindly overwrite populated ones.

3. Enrich deliberately, after dedup. Enriching before deduplication means paying the effort per duplicate instead of per person. And start with data you already own: source exports, secondary tools, old lists usually contain a large share of what the CRM is missing, at zero acquisition cost. External data vendors come last, if at all.

4. QA before go-live, against checks written in advance. Decide what "clean" means before the pipeline runs: row counts that reconcile across sources, duplicate count verified at zero by query, no populated field overwritten, spot-checked samples that match their originals. Then hold the release until every check passes. A cleanup you cannot verify is a rumor.

The case study behind those numbers

A US B2B sales-intelligence company had its contact data spread across large export files in incompatible formats, with no way to search or segment without manual spreadsheet surgery. I ran exactly the sequence above. Final state: 863,484 contacts, zero duplicates, 1.2M+ previously empty fields enriched from the client's own source exports, 145k net-new contacts merged in, and 8 of 8 QA checks passed before the team switched over.

Then the part that made the clean data usable day to day: a custom GPT interface over the database, backed by Supabase RPC functions, so anyone on the team can search and count contacts in plain English instead of filing a request with a data person. It is live and used by the client's team. The full case study is here.

863,484
contacts
0
duplicates
1.2M+
fields enriched
8/8
QA checks passed

The same discipline works at smaller scale and under stricter constraints: for a European venture-capital firm I built a GDPR-compliant merge engine that consolidates five contact lists with fuzzy dedup, company derivation, and validation sampling, running inside the client's own EU platform so the data never leaves it.

Common questions, answered straight

Should I deduplicate on email address or on name?

Email first, always. It is the closest thing contact data has to a natural key, and an exact match on a normalized email is safe to merge automatically. Names are the fallback pass: fuzzy matching on name plus company catches duplicates that have different or missing emails. Keep the fuzzy threshold conservative. A missed duplicate is a minor annoyance you can catch next run; a false merge quietly destroys two records and you may never notice.

Will I lose data during a cleanup like this?

Not if the pipeline is additive. I keep the original exports untouched, merge into a new normalized structure, and fill empty fields rather than overwrite populated ones. QA runs before go-live, not after: in the engagement described on this page, the team switched over only after 8 of 8 predefined checks passed, including a query-level verification that duplicates were actually at zero.

Do I need to buy third-party enrichment data?

Usually not at first. Most companies already hold more data than their CRM shows: old exports, a second tool, lists from a past campaign. In the case on this page, 1.2M+ empty fields were filled from the client’s own source exports, and 145k net-new contacts were merged in from the same material. Buy external data only after you have consolidated what you own; otherwise you pay to re-learn things already sitting in your files.

Can my CRM’s built-in merge tool handle this?

For a few thousand contacts with obvious duplicates, probably yes, and you should use it. At hundreds of thousands of rows it breaks down: built-in tools tend to want record-by-record confirmation, rarely do fuzzy matching well, and give you no way to test before touching live data. A scripted pipeline is repeatable and verifiable: run it against a copy, check the counts, then run it for real. That is the only way I would take a database of 863,484 contacts to zero duplicates and be able to prove the zero.

Sitting on a database you no longer trust?

Free systems teardown: I look at your data and automation setup, name your 3 biggest leaks, and estimate what each one costs you monthly. If your data is clean enough and the real problem is elsewhere, the teardown will say that instead. In your inbox within 72 hours.

Get your free systems teardown