The Contact Dataset Quality Standard: Release, Remediate, or Quarantine

An operations owner about to release a contact list to reps or recruiters, or import a batch into the CRM, needs a fixed bar for how accurate and complete the data has to be first. This guide gives you that bar: numeric cutoffs per metric, a verification procedure you run before release, and a grading rule that produces a defensible release, remediate, or quarantine verdict. It is written so two people grading the same list reach the same call.

Plenty of guides cover whether data was gathered lawfully, how fast each field decays, and whether a single record is safe to send. None sets a gradeable quality bar for a whole dataset. This one turns the scattered thresholds practitioners cite (bounce, duplicate, fill, accuracy-by-sample) into one checklist with cutoffs and a documented test procedure.

What "accurate enough to work" means for a dataset

A dataset is accurate enough to release when every critical field clears its cutoff in every segment, verified by test rather than assertion, and timestamped. That is the whole standard. The rest of this guide makes it operational.

The trap is grading the dataset as one blended number. A 1.8% overall bounce can conceal a purchased segment bouncing at 6%. A 90% fill rate can average a complete inbound cohort against an API feed that is half empty. The standard is applied per segment, and the verdict names the failing segment, not the average.

Three verdicts, defined so they are not judgement calls:

• Release. Every metric passes in every segment. The list ships, with a verification timestamp attached.
• Remediate. One or more metrics sit in the warning band. The list is fixable in place: dedupe, re-enrich the empty fields, drop the bad source. Fix, re-test, re-grade.
• Quarantine. One or more metrics fail hard. The segment is held out of the release entirely until it is rebuilt or discarded. You do not ship a quarantined segment "for now."

The reason this matters in money: Gartner puts the average annual cost of poor data quality at $12.9 million, and a single 50,000-contact database at 10% duplication carries roughly 5,000 duplicates, which at about $96 per duplicate is $480,000 in cleanup. The bar exists to keep that cost out of the CRM, not to slow the release.

The gate thresholds: pass, warning, fail

Grade each metric against a fixed band. Pass releases, warning triggers remediation, fail sends the segment to quarantine. These cutoffs are drawn from the cited industry lines; the warning and fail bands bracket each pass line against its cited failure line.

A note on the bounce line, because it is the one people over-read: below 2% overall is the industry standard, below 1% is good, below 0.5% is excellent. For cold outbound specifically, hard bounce below 3% is acceptable and best-in-class is under 1%. Above 5% is where mailbox providers start applying reputation penalties, which is why 5% is the quarantine line and not merely a warning.

The duplicate line deserves the same caution. Under 2 to 3% on priority objects is the target. But enterprise CRM environments commonly run 10% to 30% duplication, and 76% of CRM entries are less than half complete, so treat a fresh batch that lands inside the pass band as the exception to verify, not the default to trust.

Match rate versus accuracy: two numbers, never one

Match rate and accuracy measure different things and must be graded separately. Match rate is whether a provider returned any data for your input. Accuracy is whether that data is correct. A tool can show 90% coverage and 60% accuracy, meaning one in three of the records it filled is wrong.

The usable-contact math settles which to prioritise. An 85% match rate at 95% accuracy gives you 808 usable contacts per thousand. A 95% match rate at 70% accuracy gives you 665. The higher-coverage list is the worse list. This is why the standard requires an accuracy test on a sample and does not accept a vendor's coverage figure as evidence of quality.

Context on the range you are grading against: single-source providers typically find 40% to 60% of contacts, and waterfall enrichment can push coverage past 80%. But 97%+ accuracy is what high-quality B2B data looks like, while many providers deliver around 50% accuracy on average. Coverage improved; accuracy did not. Grade both.

The higher-coverage list is often the worse list, because coverage is not correctness.

Required fields by workflow

The critical field set is not universal; it follows the workflow the list feeds. Define it before you profile anything, because fill rate and accuracy are only meaningful against a named set of required fields.

For inbound routing specifically, each strategy depends on a different field: territory routing needs geography, account routing needs domain matching, score routing needs firmographic completeness, and signal routing needs enrichment data. A list that is complete for outbound can be unroutable for inbound, and vice versa. Write the required set for the actual destination.

Recruiter-outreach required fields are not established as a public standard, so construct your own and document it: at minimum a verified current employer and title, since a recruiter reaching out about the wrong role burns the contact. Treat that as a local policy decision and record the cutoff you chose.

Run the acceptance tests

Grade a dataset by running three tests and a profiling pass, in this order, then applying the cutoffs. The order matters: profile first so you know your segments, test accuracy and bounce, dedupe, then decide.

The known-good sample test is the accuracy check: take records you have already verified, enrich them through the same pipeline, and compare. Spot-check at least 50. As an attribute-sampling reference, 90% confidence with zero expected exceptions needs 48 records at a 5% tolerable exception rate, or 23 at 10%, so 50 covers the stricter case.

The campaign bounce test is the deliverability check: send to a seed sample and measure hard bounce against the sub-2% gate. The cross-reference test is the wrong-person check: manually verify titles and companies against public profiles, because an email can stay active after the person has left.

One ordering caveat from the sources: for a CRM import, a mock migration into a sandbox is the deciding test; for a send, the sample tests come first. Order by whether the destination is an import or a campaign.

Building the known-good truth set and pulling 50 verified records to test against is the slow part, and where a search tool that returns current people-and-company data removes friction. I built Refolk to answer plain-English queries across the public GitHub graph, public LinkedIn and Crunchbase records, and my own index, so you can assemble a verification set of real, current contacts instead of trusting the batch you are trying to grade.

Segment the score, because blended numbers lie

Segment every metric by source above all else, because entry channel predicts duplicate load more than headcount does. Records created via API or web-form integrations carry an 80% duplicate rate, against 19% for manual imports. The mechanism is simple: unattended writes skip the search-before-create step. A blended duplicate number averages a clean manual import against a duplicate-heavy API feed and tells you nothing actionable.

Segment by seniority and sector too, because decay is not linear. Leadership and sales roles churn nearly twice as fast as engineering, so the exact people you most want to reach are the ones whose data goes stale first. A blended cadence systematically under-refreshes your highest-value tier.

The documented method is profiling by source over time: you learn the normal duplicate rate from each source system, and when that rate moves you know something broke upstream. Save the per-source baselines so the next batch is graded against history, not from scratch.

Where the standard fails: false positives and blind spots

Most bad releases come from a metric that passed for the wrong reason. These are the failure modes to check before you sign the verdict, and how to catch each one.

• A blended pass hides a failing source. A 1.8% overall bounce can conceal a purchased segment at 6%. Recompute bounce per source and flag any source whose rate has moved off its historical baseline.
• High match rate mistaken for accuracy. A tool with 95% coverage can be 70% correct, so one in three records is wrong. Run the known-good sample test; never accept coverage as a stand-in for accuracy.
• Aggressive fuzzy dedupe merges two real people. Setting match thresholds too low mashes separate identities together, which is the more damaging error, especially when engagement or consent history is attached. Route low-confidence matches to human review.
• Dedupe only at the form, not the API. Enabling duplicate prevention only on CRM forms while ignoring API and workflow entry points is the number one reason duplicate rates rebound after a cleanup.
• One-time verification treated as durable. A list clean at import is stale by the next quarter. Job titles, phones, and emails degrade independently, and a record can go stale without ever hard-bouncing. Timestamp the verification.
• Email passes but the person is gone. A mailbox often outlives the role, so a wrong-person record can bounce zero. Cross-reference title and company against a public profile; do not rely on bounce alone.
• Catch-all domains inflate "valid." Catch-all domains accept every message even for addresses with no real mailbox, so verification shows valid while the send fails. Flag catch-all domains separately and treat their "valid" as unconfirmed.

The through-line: every one of these is a metric that looked like a pass. The standard survives only if you test the reason behind each number, not just the number.

Decay: the verdict has a shelf life

A dataset that passes today is already decaying at handoff, so the verdict must carry a timestamp and a refresh cadence, not just a grade. Contact data decays at about 2.1% monthly, compounding to roughly 22.5% a year. Three to six months after purchase, about 2,250 of every 10,000 contacts have changed something material.

Decay is field-specific, which means the cadence is field-specific too. A single refresh cycle that treats all fields the same over-spends on stable firmographics and under-refreshes volatile phones and titles.

Ninety days is the minimum baseline refresh cadence for CRM hygiene, but decay continues daily between cycles. The practical rule: set the refresh clock at release, tie it to the fastest-decaying field in the required set, and re-grade before the clock runs out rather than after a campaign underperforms.

Who owns this standard, and the verdict record

The standard needs a single accountable owner, and in most organisations that is RevOps, sometimes shared with a data governance function. In Refolk's index of professional profiles, the US Revenue Operations Manager pool is 1,066 people and the US Data Quality Analyst or Data Governance Manager pool is 1,781. The governance pool is 1.67 times the RevOps pool, which tells you the review capacity usually exists; the missing piece is a shared cutoff, not a shared headcount.

Record the verdict so it is auditable. The record is what makes two graders converge and what defends the release if a campaign later underperforms.

Dataset: <name / batch id>
Destination: <outbound send | inbound routing | CRM import | recruiter outreach>
Required fields: <the named set with per-field cutoff>
Verified on: <date>
Refresh due: <date = fastest-decaying required field cadence>

Per-segment grades:
  Source A: bounce __% | dup __% | fill __% | title acc __% -> RELEASE / REMEDIATE / QUARANTINE
  Source B: bounce __% | dup __% | fill __% | title acc __% -> RELEASE / REMEDIATE / QUARANTINE

Sample tests:
  Known-good sample (n>=50): accuracy __% per field
  Campaign bounce seed: hard bounce __%
  Cross-reference: title accuracy __%

Verdict: <RELEASE / REMEDIATE / QUARANTINE>
Failing segment(s): <named, or "none">
Owner signature: <name / date>

Before you sign it, run the final check.

Keeping the standard current

Re-grade on the clock the verdict set, not when a campaign disappoints. The refresh-due date is the trigger, and it is anchored to the fastest-decaying field in your required set, which is usually the job title at roughly 65.8% annual change or the phone at 25 to 35%. When that date arrives, re-run the profiling pass and the sample tests on the segments still in use.

Keep the per-source baselines and watch them drift. The most useful early warning is not a failed send but a source whose normal duplicate or bounce rate has quietly moved. When it does, something upstream broke, and you want to catch it before the next batch inherits it. A standard that is graded once is a snapshot; a standard that is re-graded against its own history is a control.