Lead and Intent Data Quality Assurance Checklist

The ten-test lead and intent-data QA gate

Copy this checklist into each delivery run. Replace every blank acceptance value with a client-approved, contract-scoped rule. Do not borrow thresholds from a different data source, use case, or client.

1. Provenance test: Can the team identify the source category, received time, relevant use constraint, transformation, and current evidence for the field?
2. Scope test: Does the record match approved topics, markets, account criteria, geography, and client use? Reject rather than stretch the scope.
3. Schema test: Are required fields present, typed, normalized, and within allowed values? Are nulls distinct from zero, false, or unknown?
4. Identity test: Does the resolved entity have sufficient evidence for the intended action? Record conflicts, confidence, review, and rejection.
5. Freshness test: Is each signal and attribute inside its approved age rule? Preserve observed and processed times separately.
6. Uniqueness test: Are duplicates defined at the right event, account, contact, and delivery levels? Preserve legitimate repeated signals.
7. Eligibility and suppression test: Do exclusions, existing customers, active opportunities, opt-outs, client rules, and sensitive segments work before activation?
8. Cross-field reasonableness test: Do domain, company, role, geography, topic, source, and destination agree? Flag conflict instead of forcing a match.
9. Delivery integrity test: Does the destination receive the intended fields, row count, encoding, permissions, and client separation without silent truncation?
10. Evidence and exception test: Can a reviewer reproduce the checks, find rejected items, see corrective action, and understand residual limitations?

Release state should be one of four values: pass, pass with accepted exception, hold for correction, or reject. Give each exception an ID, severity, affected scope, owner, containment action, client-notification decision, correction evidence, and closure approval. “Looks okay” is not a release state.

How should an agency design QA to reach client value quickly and repeatably?

Define fitness for one decision before designing checks. A record used to prioritize an account needs different evidence from one sent into a person-level outreach workflow. Start with the smallest useful delivery, run the full gate, show the client accepted and rejected examples, and record feedback. Repeatability comes from fixed definitions and controlled exceptions, not from pretending sources never change.

Build QA upstream. Validate a source sample before integration, validate schema at intake, resolve identity before qualification, apply suppression before activation, and reconcile the destination after delivery. This shortens correction loops and makes time-to-value measurable. The agency intent-data vendor guide can be used to test whether an underlying provider exposes the evidence and controls the QA plan needs.

What steps, owners, SLAs, quality checks, and handoffs should QA include?

Assign a source owner, data steward, identity reviewer, activation owner, security or privacy escalation owner, client approver, and release owner. The release owner should be able to stop delivery. The sequence is intake, quarantine, source and schema validation, identity review, scope and suppression, sample inspection, automated rule checks, exception triage, correction or rejection, destination test, release approval, client handoff, and post-delivery reconciliation.

Set service levels for acknowledgement, initial triage, containment, correction attempt, client decision, and closure. A dependency clock should stop only under written rules. The handoff contains release state, scope, counts by disposition, test results, open exceptions, known limitations, delivery evidence, and the next scheduled review. Never hide rejected records by reporting only the delivered count.

Which tools, templates, portals, or integrations best support QA?

The basic toolkit includes a data dictionary, rule registry, source register, sample worksheet, validation environment, identity review queue, exception tracker, secure file or API delivery, field-level change log, and client-facing scorecard. At higher volume, add automated schema contracts, anomaly detection, lineage, role-based workflow, and destination reconciliation. A portal is useful when it shows current status and limitations rather than only polished totals.

Evaluate software on reproducibility, versioned rules, raw-to-output lineage, access control, client isolation, error handling, export, deletion, and the ability to sample rejected as well as accepted records. Avoid ranking tools by the number of checks advertised. A black box that marks a record valid without exposing the rule cannot support a defensible client exception conversation.

How do manual, automated, and white-label QA approaches compare?

Manual review handles nuance and ambiguous identity well but can drift between reviewers and does not scale cheaply. Automated validation is consistent for schema, allowed values, duplication, and known rules, but it can repeatedly pass the wrong rule. White-label QA can speed delivery and give clients a branded scorecard, but the agency must understand the underlying method, exceptions, permissions, and correction path. The strongest operating model is usually hybrid.

Use automation for deterministic checks and queue risk-based samples and conflicts for people. Compare options by setup work, recurring labor, error coverage, explainability, client visibility, correction speed, security boundary, and total cost. A manual spot-check with no sampling plan is not equivalent to documented human review. Likewise, an automated green status is not proof of real-world accuracy.

What delivery cost and setup fee should an agency model?

Setup cost includes defining acceptance rules, mapping fields, establishing truth or reference sets where possible, creating suppression tests, configuring validation, integrating the destination, training reviewers, and agreeing on exception communication. Recurring cost includes source and platform charges, compute, sample review, identity conflicts, support, client questions, reprocessing, destination changes, and documentation maintenance.

Calculate a fee from the actual scope. Use price floor = wholesale and usage cost + direct QA labor + tooling allocation + expected exception and support cost + risk reserve. Price high-ambiguity identity or sensitive activations separately from a clean account-level report. Monitor contribution margin using actual hours and corrections. There is no universal setup fee, cost, or gross-margin benchmark that fits every signal source and acceptance standard.

Which time-to-value, quality, adoption, and outcome metrics should be used?

Track time to approved schema, first releasable sample, first delivery, exception containment, correction, and client acceptance. Quality KPIs include provenance coverage, required-field completeness, rule-valid rate, duplicate rate, freshness distribution, identity conflict rate, suppression failure, accepted-exception share, destination reconciliation difference, and reopened issue rate. Report both numerator and denominator.

Use “accuracy” only when there is an appropriate truth set and method. Otherwise name what was tested, such as domain agreement or client-confirmed role. Adoption metrics include reviewed deliveries, disposition completeness, activation acceptance, and client feedback resolution. Outcome evidence can show how accepted records progressed, but QA does not cause pipeline or revenue. Use the client’s own history for benchmarks and label sample size, selection method, and uncertainty.

How should QA vary by client maturity, stack, and service package?

A low-maturity client may need a controlled spreadsheet, a small risk-based sample, manual identity review, and delivery by a named owner. A middle-maturity client can use automated schema validation, CRM deduplication, exception tickets, and destination reconciliation. An advanced client may add warehouse lineage, versioned data contracts, statistical sampling, automated monitoring, and separate client acceptance environments.

Vary QA by use case as well as maturity. Account-priority reports can tolerate different fields and uncertainty from direct outreach or audience activation. A strategic account list may justify deeper manual review. A recurring broad feed needs more automation. Do not weaken the privacy or security boundary because a client is immature. Reduce the data and action scope instead.

Which signal sources, identity checks, activation workflows, and outcome evidence matter most?

For signals, inspect provenance, entity level, observation and processing times, topic definition, change history, and permitted use. For identity, test the inputs relevant to the action, preserve method and conflict, and require review when evidence is ambiguous. Domain-to-company resolution, contact matching, and household or device inference have different implications. Do not report them as interchangeable certainty.

For activation, verify qualification, suppression, destination, permission, owner, and payload. Use a dry run or isolated test when the integration supports it. Reconcile sent, accepted, rejected, and changed records. Outcome evidence should preserve client disposition and downstream events without retroactively turning a failed record into a pass. Quality reporting shows how the data performed against defined tests, not whether every prospect eventually bought.

What scope, data, security, integration, and expectation risks affect QA?

Risks include undefined acceptance, source drift, stale fields, false merges, duplicate suppression, cross-client leakage, excessive personal data, unsecured exports, integration truncation, reviewer inconsistency, biased samples, silent rule changes, and a client treating a QA score as certainty. Maintain a risk register and map each risk to prevention, detection, containment, correction, and client communication.

The FTC’s Start with Security guidance discusses minimizing retained information, sensible access control, secure handling, provider oversight, and ongoing procedures. The NIST Privacy Framework is a voluntary tool for managing privacy risk, while the NIST Cybersecurity Framework helps organizations manage cybersecurity risk. These references do not certify the agency, establish a legal conclusion, or prove data accuracy.

What must QA include for a recurring white-label intent-data service?

Include a maintained data dictionary, source and field inventory, acceptance rules, sampling plan, automated test results, identity-review queue, suppression evidence, exception register, destination reconciliation, client scorecard, change log, release approval, and correction allowance. The report should show what was tested, what passed, what failed, what was excluded, and what remains uncertain.

Add a renewal decision: continue, repair, reduce scope, expand, or stop. Tie it to observed quality, client adoption, delivery cost, open risk, and useful outcome evidence. The agency intent-data reporting guide helps place QA evidence inside a client review. The agency intent-data compliance program provides a related governance structure without turning QA into a compliance guarantee.

A sampling worksheet that avoids false confidence

Define the population, risk strata, selection method, sample unit, reviewer, test, acceptance rule, and escalation before looking at results. Include accepted, rejected, high-risk, newly changed, and edge-case records. A purely convenient sample can miss systematic errors. For a critical release, ask a qualified analyst whether the sample supports the decision. Do not present a sample percentage as the population’s accuracy unless the design and uncertainty justify that inference.

When a sample fails, decide whether the failure is isolated, systemic, or unknown. Quarantine affected scope, expand investigation, correct the rule or source, rerun the test, and preserve evidence. Do not simply replace the failed row with another row until the sample passes.

How BrandWell fits quality-controlled delivery

BrandWell’s agency-reseller Intent Data product is separate from the legacy BrandWell SEO writer. Agencies use it to sell branded intent-data services. LeadFuze provides underlying data infrastructure where contracted and available. Moxby is a separate browser-first product.

The current starting option is a $70 seven-day paid reseller pilot with agency-branded topic reports and the complete sales playbook used to seek client commitments before a full plan. The pilot can be subjected to the same acceptance and exception discipline as a larger service. It does not guarantee commitments, cost recovery, profit, pipeline, revenue, sales, any particular data volume, search ranking, or AI citation.

Owner-provided agency plan pricing is $2,500-$5,000 per month, depending on topic count, term, and available contract-scoped topic exclusivity. Current written terms control. The agency sets its own client-facing price under its agreement and should model QA cost explicitly.

Agent-ready instruction for Claude, ChatGPT, or Moxby

Use an assistant only with approved, minimized records and documented tools. Keep it in a review role until the agency has separately approved any live-system access. Require human release authority.

Act as a QA review assistant for a recurring lead and intent-data delivery.
Inputs: approved data dictionary, source register, acceptance rules, sample plan,
suppression rules, identity-review policy, delivery manifest, and test results.
Return: rule-by-rule results, failed record IDs, severity, suspected scope,
missing evidence, correction options, retest plan, and a release recommendation.
Separate deterministic validation from judgment. Never infer a missing identity,
source, permission, truth value, legal status, or client approval. Do not invent
benchmarks, accuracy rates, pricing, outcomes, or guarantees. Do not modify source
data, suppressions, permissions, or destinations. Route ambiguity, security,
privacy, legal, and high-impact identity decisions to named human owners.

The NIST AI Risk Management Framework is a voluntary reference for considering trustworthiness in AI use and evaluation. It does not make agent output a QA decision.

Release fewer records when the evidence requires it

Maintain truth sets carefully. A client-confirmed company domain can test one identity field, but it does not validate a person’s current role, an intent event, or the permitted activation. Record who established the reference, when it was applicable, what field it supports, and how conflicts are resolved. Refresh or retire reference data when the underlying fact can change.

Blind review can reduce confirmation pressure for selected tests. Give the reviewer the fields needed for the rule without showing whether the record came from a favored source or was expected to pass. Compare reviewers on the same bounded sample when judgment is material. Disagreement is an exception to investigate, not a reason to average two unsupported answers.

Periodically seed safe, synthetic test records designed to fail a known rule, provided the agency and client systems allow it and the records cannot trigger real outreach. Confirm that the record is quarantined and removed. Keep synthetic tests clearly separated from client data and never let them appear in performance reporting.

A mature QA program makes it easy to hold, reject, and explain records. The goal is not a perfect-looking delivery. It is a fit-for-purpose release whose source, rules, exceptions, and limits can be understood by the agency and client. That discipline protects trust and provides a sounder basis for renewal than an unsupported claim of perfect data.