CRM Data Cleaning: The Complete Process

What is CRM data cleaning?

CRM data cleaning is the work of correcting, standardising, consolidating and retiring the records already in your CRM so the system can be trusted for outreach, routing, forecasting and reporting. It operates on data you own. That distinguishes it from enrichment, which brings in data you do not have from outside sources, and it is why the two are usually run as one project but never as one step.

Five operations make up the whole job, and almost every cleanup is some combination of them.

Normalisation puts values into one agreed format. "VP Sales", "Vice President of Sales", "V.P., Sales" and "VP, Sales and Marketing" become one canonical title with one seniority band. "(415) 555-0142" becomes +14155550142 in E.164. "United States", "US" and "USA" roll up. Nothing is deleted, nothing is added, but everything downstream starts working.

Deduplication finds the records that describe the same real-world person or company and merges them into one, preserving the activity history that hangs off each of them.

Validation checks that a value is still true of the world rather than merely well formed. A syntactically perfect address on a live domain still bounces if the person left in March. Only a check against the receiving mail server tells you that.

Enrichment fills the blanks that survive, which is a different operation entirely and belongs at the end.

Retirement moves records that cannot be saved out of the active workflow: hard bounces, contacts at companies that no longer exist, test records, form spam. Retirement usually means archiving with a reason code rather than deleting, because a deleted record comes straight back in the next import and you will have paid to clean it twice.

What makes CRM cleaning specifically hard, as opposed to cleaning a spreadsheet, is that CRM records are load-bearing. Every contact has emails, calls, meetings, form submissions, deal associations, list memberships, workflow enrolments and attribution attached to it. You are not tidying values, you are performing surgery on an object other systems have opinions about.

What is the correct order of operations for cleaning a CRM?

Normalise, deduplicate, validate, enrich, then retire. Running those five steps in that sequence is the single highest-leverage decision in a CRM cleanup, and it is the one most teams get wrong because the tempting order is the reverse: enrich everything first so the records look complete, then sort the mess out.

Here is why the sequence holds.

Normalisation comes first because matching depends on it. Duplicate detection compares field values. If one record says "Acme Corp" and its twin says "Acme Corporation, Inc.", a matching rule that compares company name exactly will not pair them, and a fuzzy rule loose enough to pair them will also pair "Acme Corp" with "Acme Corp Holdings", which is a different company. Standardise the fields the matcher reads before you ask the matcher to do anything, and both the false negatives and the false positives drop at the same time.

Deduplication comes before validation because validation is priced per record. Every email you verify on a duplicate is a check you paid for twice and will now have to reconcile, because the two copies can return different results if one address is stale.

Validation comes before enrichment because it tells you what actually needs enriching. A record with an address that still verifies clean does not need a new email. Enriching it anyway spends credits to overwrite a working value with a value that is, at best, identical.

Enrichment comes last because it is the only step that adds volume. Every earlier step reduces the record count or improves the input quality of the matching keys. Enrichment is charged against whatever survives, so it should meet the smallest, cleanest, most correctly keyed set you can hand it.

Retirement comes last of all, once you can see which records the waterfall could not resolve and which addresses came back undeliverable. A record that no provider can find and whose address hard-bounces is not a record you should keep enrolling in workflows.

The one exception worth naming: if your duplicate rate is very low and your CRM has fewer than a few thousand records, you can collapse normalisation and deduplication into a single pass using your CRM's own tooling and lose nothing. The order matters most at scale, and matters most when enrichment is in the plan.

Why does enriching before deduplicating make the problem worse?

Because enrichment is applied per record, not per person, so a contact that exists twice gets enriched twice, and the two copies can come back different. That is the failure that turns a data-quality project into a data-quality incident.

Work through it. Suppose Priya Raman appears in your CRM twice: once as a lead captured from a webinar in 2024, with an old personal-looking address and no phone, and once as a contact created by a rep in 2026 with her current title. You enrich both. The waterfall matches the 2024 record on the stale inputs and returns what it can find for that identity. It matches the 2026 record on better inputs and returns her current work email and a direct dial. You now hold two records with conflicting emails, conflicting titles and two different phone numbers, and you have paid for both.

The damage compounds in three directions.

You paid twice. At the Cleanlist rate card an email and a direct dial on the same contact is 11 credits. Every duplicated contact you enrich in full is 11 credits spent on a record you are about to delete. Across a database with a 15% duplicate rate on 20,000 contacts, that is 3,000 records, and enriching all of them fully is 33,000 credits you did not need to spend.

The merge gets harder, not easier. Most CRMs resolve a field conflict during a merge by keeping the value from the record you nominate as the master, or by keeping the most recently modified value. You just modified both of them, seconds apart, with an automated process. The "most recent" tiebreaker is now meaningless, and the correct email might sit on the record you are about to discard.

The bad copy escapes before you catch it. Enrichment usually triggers something: a list membership, a lead score recalculation, a routing rule, a sequence enrolment. Two enriched copies of one person means two enrolments, which means that person receives the same cold email twice from two reps. That is a deliverability problem and a credibility problem in one.

The fix costs nothing except sequencing. Run the dedupe pass first, merge, and only then point enrichment at the survivors.

How do you find duplicate records in a CRM?

By matching on a hierarchy of keys, strongest first, and treating anything below the top tier as a candidate for review rather than an automatic merge. B2B duplicates are rarely identical rows, which is why an exact-match pass alone typically finds only a fraction of them.

For contacts and leads, the practical key hierarchy runs like this. Email address is the strongest single key and can usually merge automatically when it matches exactly, after normalising case and stripping Gmail dot and plus-alias variants that make one mailbox look like five. LinkedIn profile URL is nearly as strong and survives job changes, which email does not. Full name plus company domain is a good third, strong enough to auto-merge when both sides also agree on something else. Full name plus company name is weaker, because company name is the field most likely to be entered inconsistently. Phone number is a poor key in B2B, because shared switchboard numbers pair strangers who happen to work at the same office.

For accounts and companies, the website domain is by a distance the strongest key, and normalising it first (dropping www, protocol and trailing slash, and resolving obvious redirects) does most of the work. Company name alone is a bad key: legal suffixes, abbreviations, trading names and acquisitions all break it. Registered company number is excellent where you have it and almost nobody does.

Three patterns produce most B2B duplicates and are worth hunting specifically. The lead-and-contact split, where the same human exists as an unconverted Lead and as a Contact, is the single most common in Salesforce and the one native duplicate rules handle least well because the two live on different objects. The integration echo, where a form tool, a webinar platform and an enrichment job each create their own copy of one person over a few days, shows up as clusters with near-identical create dates. The domain drift case, where a company is present under both its old and new domain after a rebrand or acquisition, splits the account and everything under it.

Native tooling covers a lot of this. Salesforce Duplicate Management lets you define matching rules (the comparison logic) separately from duplicate rules (what happens when the comparison hits), so you can block creation on strong matches and merely warn on weak ones. HubSpot surfaces likely duplicate contacts and companies for review and merge in its data quality tooling. Pipedrive offers merge on individual records. All three are fine at finding the obvious cases and none of them will find a duplicate whose fields you never normalised.

How do you decide which record survives a merge?

Pick the survivor by association weight, not by age or by completeness, then take the best individual field values from every copy rather than from the survivor alone. Getting this backwards is how teams lose deal history while cleaning.

The survivor should almost always be the record with the most irreplaceable associations attached: deals, tickets, meetings, call logs, attribution. Field values are cheap to recover, because you can re-enrich a field for one credit. A five-year email thread and the closed-won deal attached to it cannot be recovered at all once the merge drops them. In most CRMs the merge preserves activities from all merged records, but associations, custom object links and integration references behave less predictably, so the safe default is to keep whichever record other systems already point at.

Field-level resolution then runs on its own rules, and it is worth writing them down before you start rather than deciding case by case at 200 records an hour.

Most recent wins is the right default for volatile fields: job title, phone, company, seniority.

Most verified wins should override recency for email. A three-year-old address that verifies deliverable today beats a two-week-old address that comes back undeliverable, and recency alone would pick the wrong one.

Non-empty wins applies to everything else. Never let a merge overwrite a populated field with a blank one, which is a genuinely common default in bulk merge tools.

Never auto-resolve the fields that carry legal or consent meaning. Opt-out status, communication preferences, lawful basis and do-not-call flags must resolve to the most restrictive value across every merged copy, always, with no exceptions and no "most recent" logic. If one copy of a person opted out, that person opted out.

Two practical guardrails. Export the full record set before any bulk merge, because merges are generally irreversible and the export is your only rollback. And run the first few hundred merges by hand, in review mode, before you let anything run automatically. The first hundred will teach you which of your matching rules is too loose, and finding that out at a hundred records is cheap.

What does normalisation actually change, and which fields matter most?

Normalisation maps many written forms of one value onto a single canonical form, and in a B2B CRM six fields carry almost all of the benefit: job title, company name, company domain, phone, country or region, and industry.

Job title is the field that breaks the most downstream logic, because routing rules, ICP filters and sequence branching all read it. The canonical form should carry two values, not one: a cleaned title and a separate seniority band, so a rule targeting VP-and-above matches regardless of whether the title was typed as "VP", "Vice President", "Head of" or "Director of" in a market where that means something different. A department field alongside it saves you from writing string matches on the title forever.

Company name should lose its legal suffix and its punctuation for matching purposes while keeping the display form for humans. Store both. Matching on the stripped form and displaying the full one gives you accurate dedupe without ugly records.

Company domain is the field to invest in most, because it is the join key between your CRM, your enrichment layer, your billing system and your analytics. Normalise it to a bare registrable domain: no protocol, no www, no path, lowercased.

Phone should be E.164 without exception, and the free Cleanlist phone validator will normalise a number and check it against its country's numbering plan if you want to see what a field looks like after the pass before committing to it.

Country and region should use ISO codes internally with a display label on top, because free-text country is where territory assignment silently loses records.

Industry should map to a fixed picklist, ideally one anchored to SIC or NAICS, because free-text industry fragments every segment you will ever build.

The part worth knowing about enrichment here: fields arriving from Cleanlist are normalised on the way in. Waterfall results from 25+ providers are reconciled into one canonical shape before they reach you, so titles come back with a canonical form and a seniority band, and company data comes back with industry, headcount, HQ location, domain and founded year in consistent formats. That does not normalise the fields you already have, which is your job and your CRM's, but it does mean the new data does not add a fresh set of formats to the pile.

How do you validate emails and phone numbers during a cleanup?

Validate in two passes, because the two kinds of check cost radically different amounts and the cheap one removes most of the volume before you pay for the expensive one. Pass one is hygiene, which reads the address and costs nothing. Pass two is verification, which asks the receiving mail server and is priced per address.

The hygiene pass catches everything visible in the string itself: exact and alias duplicates, syntax that cannot be valid, role-based shared inboxes such as info@ and sales@, free consumer domains that are rarely the work contact in B2B, near-miss typo domains like gmial.com, and known disposable inboxes. The free Cleanlist email list cleaner does exactly this, entirely in your browser with nothing uploaded, and returns both the cleaned list and a second file of every removal with its reason, so the decision on role addresses and consumer domains stays yours rather than being made silently. On a real CRM export this pass routinely removes a meaningful percentage before a single paid check runs.

The verification pass is the only thing that predicts a bounce. It runs syntax, then DNS and MX lookup, then a live SMTP handshake with the receiving server without ever sending mail, and it returns a status rather than a yes or no. That distinction matters more than anything else in this section. A catch-all domain accepts every address at the handshake and discards the invalid ones later, so it cannot be scored as valid or invalid honestly, and any tool that reports it as clean is guessing on your behalf. Cleanlist flags catch-all, role and disposable results separately rather than counting them as clean, which means you get a smaller number of confidently valid addresses and a visible pile of risky ones, which is the correct output even though it looks worse.

Phones validate differently and less definitively. Format normalisation to E.164 and a check against the country's numbering plan will catch impossible numbers instantly and free. Line type (mobile, landline, VoIP) tells you whether a number is worth a rep's time. Nothing short of dialling proves a number reaches the person, which is why phone data decays faster in practice than its verification status suggests.

In Cleanlist, validation is priced at 0.5 credits per record and a lookup that finds nothing is never billed. On the Starter plan, $79 for 1,500 credits, that works out at roughly 2.6 cents per address checked; on Scale, $599 for 15,000 credits, roughly 2 cents.

Why does CRM data decay, and how fast?

B2B contact data decays at roughly 22% to 30% a year, which means a database you cleaned perfectly in January is somewhere between 11% and 15% wrong by July even if nobody touched it. Decay is not a data-entry problem and it cannot be fixed by better forms, because the world changes underneath records that were correct when they were written.

Four mechanisms produce nearly all of it.

Job changes are the largest. When someone moves company, their work email dies, their direct dial usually dies, their title changes and their employer changes. One event invalidates four fields on the record and, crucially, also invalidates the account association: your champion at the old company is no longer your champion, and your best lead at their new company is a record you do not have.

Company changes invalidate accounts wholesale. Rebrands change the domain, acquisitions merge two accounts that your CRM still holds separately, and closures leave a full set of contacts pointing at nothing. Headcount and revenue drift continuously without any discrete event at all, which quietly rots ICP scoring.

Mailbox changes kill addresses without any job change: a domain migration, a mail platform move, a company deciding that first.last@ is now flast@. The person is still there and their address is not.

Entropy inside your own system is the fourth and the only one you fully control. Every manual entry, every list import, every integration that creates rather than updates, and every rep who types a company name slightly differently adds a small amount of inconsistency that compounds.

The operational conclusion is that a cleanup is not a project with an end date. Decay of 22% to 30% a year is a running cost, so the plan has to include a recurring pass, and the recurring pass is much cheaper than the first one because it only touches what changed. The signals that tell you it is due before the calendar does: bounce rate creeping above 2%, phone connect rate falling, reply rates declining on unchanged messaging, and a rising share of records with a last-activity date over a year old.

What is the step-by-step process for a first CRM cleanup?

Run it in seven steps, and profile before you touch anything, because the profile determines which of the later steps is worth doing at all.

Step 1. Profile and take a backup. Export the full contact, lead and account set to CSV before anything else. Then measure five numbers: the duplicate rate, the fill rate on each field you care about, the share of records with no activity in twelve months, the share with no email, and the current bounce rate. Those five are your baseline and the only way you will ever prove the project worked.

Step 2. Agree the rules in writing. Which field values are canonical. What counts as a duplicate for auto-merge versus review. Which fields are safe to overwrite and which are never overwritten. Who owns the picklists afterwards. Thirty minutes here removes weeks of relitigating decisions record by record.

Step 3. Normalise. Titles, company names, domains, phones, countries, industries. Run it on the export, not in production, so you can look at the result before committing.

Step 4. Deduplicate and merge. Strong keys auto-merge, weak keys go to a review queue, and the survivor is chosen by association weight. Do a few hundred by hand first to calibrate the rules.

Step 5. Validate. Hygiene pass free and locally, then verification on what survives. Split the output three ways: valid, undeliverable, and risky (catch-all, role, disposable). Treat those as three different populations from here on, because they are.

Step 6. Enrich the survivors. Now, and only now. Point the waterfall at the records that are unique, normalised and known to be missing something. In Cleanlist that is a verified work email at 1 credit, a direct dial at 10, both on the same contact at 11, a company record at 1, and nothing at all for a row that comes back empty. Set the write-back to fill empty properties only, which is the Cleanlist default on the HubSpot sync, so a fresh enrichment cannot quietly overwrite a value a rep confirmed by phone last week.

Step 7. Retire and re-measure. Archive the undeliverable and the unresolvable with a reason code rather than deleting them, so the next import does not recreate them. Then re-run the five numbers from step 1 and write down the difference.

One sizing note worth planning around: a list in Cleanlist holds up to 2,500 leads on paid plans (100 on Free), so a 40,000-record CRM is a batched job of sixteen lists rather than one upload. CSV export is available on every plan and CSV upload opens on Starter at $79 a month. Teams that would rather not move files at all can drive the same flow through two-way sync with HubSpot, Salesforce or Pipedrive, which opens on Pro at $229 a month, or through the REST API, which is also Pro and above and charges 0.2 credits per lead pushed to a CRM.

What should you delete, what should you archive, and what should you keep?

Delete almost nothing, archive most of what fails, and keep anything that carries history or consent meaning. Deletion feels like the point of a cleanup and it is the step most likely to cause harm you cannot undo.

Delete outright only three categories: obvious test records created during implementation, form-fill spam with no plausible human behind it, and records you are legally required to erase following a valid deletion request. That last one is not optional and should be handled through your CRM's erasure flow so it propagates to integrations rather than by bulk delete.

Archive, meaning move out of active workflows while retaining the record, everything that failed a check for a reason that might change. Hard-bounced addresses where the person may simply have moved. Contacts at companies that closed. Records with no activity in two years. Records the waterfall could not resolve. Each one keeps a status field and a reason code, because the reason is what stops the record being recreated by the next import and re-enriched at full price.

Keep and never touch: anything with a deal, a support ticket, a signed contract, or a consent or opt-out flag. Opt-out records in particular must survive every cleanup, forever. Deleting a suppressed contact does not free you from the suppression, it just removes the evidence that you knew, and the next list import will happily add them back and mail them.

The distinction that makes all of this workable is between the record and its activity. Archiving should hide the record from lists, workflows, reports and rep views without touching what is attached to it. Most CRMs do this natively with a lifecycle stage, a status picklist or an inactive flag. If your CRM bills per record, archiving to a warehouse table and deleting from the CRM is legitimate, but export the associations first, because the moment they are gone you cannot reconstruct who spoke to whom.

How do you stop the CRM getting dirty again?

Move the controls to the point of entry, because everything downstream of entry is remediation and remediation is priced per record forever. A cleanup with no entry controls will need repeating at full cost in twelve months.

Block duplicates at creation. Configure duplicate rules to warn or block on strong matches for manual entry, and to update rather than create on integration writes. Most form tools, webinar platforms and event integrations default to create-if-not-found using an exact email match, which is precisely the weak matching that produced your duplicates in the first place. Point them at a stronger key where you can.

Remove free text where a picklist will do. Every free-text field is a future normalisation project. Industry, country, seniority, lead source and lifecycle stage should all be constrained, and required fields should be genuinely required rather than defaulted to a value nobody means.

Validate on entry, not in batch. Checking an address at the moment a form is submitted or a rep saves a record costs the same as checking it six months later and prevents everything that would have happened in between.

Enrich on creation. A record created complete never needs a bulk enrichment pass. This is the highest-value automation in the whole area, because it converts a recurring project into a per-record cost you barely notice. In Cleanlist this is a REST API call on the create event (Pro and above; the v2 API is poll-based with no webhooks, so an asynchronous enrichment returns a workflow ID you poll until it is terminal, and a scheduled job needs a second scheduled step to collect the result).

Set a cadence and put it in a calendar. Weekly, review the duplicate queue and clear it while it is small. Monthly, revalidate the addresses you are actively mailing and check the bounce rate against the 2% line. Quarterly, re-enrich the active segment to catch job changes, and audit fill rates against the baseline you recorded. Annually, run the full pass including the archive sweep.

Give it an owner. Data quality with no named owner reverts within two quarters regardless of how good the initial cleanup was. It does not need to be a full-time role, it needs to be somebody's explicit responsibility with the cadence above on their calendar.

What does CRM data cleaning cost?

The cost splits into three very different buckets, and confusing them is why quotes for the same project vary by two orders of magnitude. Normalisation and deduplication cost time, not money. Validation and enrichment cost money per record. Managed services cost money per project.

Deduplication and normalisation are usually free at the tooling level, because Salesforce, HubSpot and Pipedrive all ship duplicate management and property tooling at no extra charge, though the deeper capabilities sit on higher CRM tiers. What they cost is hours. Budget realistically: for a database of tens of thousands of records, expect several days of an operations person's time on the first pass, most of it in the review queue rather than the automated part. Dedicated deduplication tools priced in the low hundreds per month exist and are worth it when the review queue is genuinely large.

Validation is priced per address across the market at roughly a tenth of a cent to a cent. In Cleanlist it is 0.5 credits per record, which is about 2.6 cents on Starter ($79 for 1,500 credits) and about 2 cents on Scale ($599 for 15,000 credits). Revalidating a 40,000-address database is 20,000 credits, which sits inside a single Scale month at the 20,000-credit tier.

Enrichment is the largest line and the most variable, because it depends entirely on how many fields are actually missing after the earlier steps. In Cleanlist a verified work email is 1 credit, a direct dial is 10, both on the same contact is 11, a company enrichment is 1, and a lookup that finds nothing is never billed. At the Starter rate of roughly 5.3 cents a credit that is about 5 cents for an email and about 58 cents for a full contact; at the Scale rate of roughly 4 cents a credit, about 4 cents and about 44 cents. Annual billing takes 25% off. Search costs 0 credits on every plan, so building the segment you are going to enrich never costs anything.

The order changes the bill more than the vendor does. Take 20,000 contacts with a 15% duplicate rate and 8% undeliverable addresses. Enrich everything first, in full, and you pay for 20,000 records. Normalise, merge and validate first and you are enriching roughly 15,600, and only the subset actually missing a field. On the same rate card, sequencing correctly is the difference between a five-figure credit spend and a four-figure one.

Managed cleanup services quote per project or per record and typically start in the low thousands. They are worth considering when the review queue needs domain judgement your team does not have time for, and worth avoiding when the real problem is that nothing prevents the mess from returning.

Which tools do which part of the job, and where is Cleanlist not the answer?

No single tool does all five operations well, and the honest map has four categories in it. Buying the wrong category is the most common way a CRM cleanup stalls.

Your CRM does deduplication and merging. Salesforce Duplicate Management separates matching rules from duplicate rules, so you can block on strong matches and warn on weak ones, and it handles the merge with activity preservation. HubSpot surfaces likely duplicate contacts and companies for review and merge. Pipedrive merges individual records. This is native, included and the right place for the job, because merging is an operation on your objects and your associations, which no external tool sees completely.

Dedicated data-ops tools do bulk normalisation and large-scale merge queues. When the review queue runs to thousands of pairs, or when you need repeatable templated cleaning across objects on a schedule, a purpose-built tool earns its subscription. This is a real category and it is not one Cleanlist competes in.

Verification and enrichment tools do validation and refill. This is where Cleanlist sits. Waterfall enrichment across 25+ providers, built to a 98% verified work email and 85% direct dial specification on its 500-lead benchmark, with every address checked for syntax, then DNS and MX, then a live SMTP handshake before it reaches a CRM property, and with catch-all, role and disposable flagged rather than passed through as clean. Results from every provider are reconciled and normalised into one shape on the way in, so you are not adding a new set of formats to the ones you just cleaned. Write-back defaults to filling empty properties only, with overwrite, append or skip selectable per field.

Free single-purpose tools do the cheap first pass. The Cleanlist email list cleaner runs a full hygiene pass in the browser with nothing uploaded, the email verifier checks addresses one at a time, the phone validator normalises to E.164 against a country's numbering plan, and the MX lookup tells you which mail provider a domain is on. None of them need an account and none of them cost a credit.

Where Cleanlist is not the answer, stated plainly. It does not deduplicate or merge your CRM records: it has no view of your associations and it will not decide which of two contacts survives. It does not rewrite the values already sitting in your fields, so normalising your existing picklists is your CRM's job. It has no intent data, no technographic feed, no revenue-range filter and no job-change alerting, so a cleanup whose real goal is "tell me who moved jobs last quarter" is not one Cleanlist will finish for you. And if your database is small and your problem is genuinely just duplicates, native CRM tooling alone will solve it and you do not need an enrichment vendor at all.

How do you measure whether the cleanup actually worked?

Measure the five numbers you recorded before you started, plus three outcome metrics that lag them by a few weeks. Without a baseline a cleanup is unfalsifiable, which is why so many of them are declared a success and then quietly repeated a year later.

The data metrics, measured immediately after and then monthly.

Duplicate rate: duplicate records over total records. Below 5% is a reasonable working target and below 2% is achievable with entry controls.

Field fill rate, measured per field rather than as an average, because an average hides the fact that email is at 95% and direct dial is at 20%. Track the fields your routing and scoring actually read.

Email validity rate: the share of active addresses returning a confidently valid status, with the catch-all and role populations reported separately rather than folded in.

Freshness: the share of records verified or enriched within the last 90 days. This is the metric that tells you whether the recurring cadence is real or aspirational.

Record activity: the share with an activity in the last twelve months, which tells you how much of your database is genuinely working versus stored.

The outcome metrics, which are the ones that justify the project to anyone outside the operations team.

Bounce rate is the fastest and cleanest signal, and it should move within one send cycle. Under 2% is the line worth holding, because sustained bouncing damages sender reputation across every campaign from that domain rather than just the one that caused it.

Connect rate on dialled numbers moves next, and reflects both validation and the direct dials recovered during enrichment.

Reply rate moves last and is noisiest, because it is affected by everything, but a cleanup that improves targeting accuracy should show up here within a quarter.

One caution on interpreting the numbers. A good cleanup usually makes your database look worse on paper: fewer records, a lower apparent contact count, and a valid-email percentage that drops because catch-all addresses stopped being counted as clean. That is the measurement getting more honest, not the data getting worse, and it is worth saying out loud to whoever sees the dashboard before they see it.