Draft · LeadScale Website 0.5.3 · P-11 · /platform/capabilities/lead-validation/ · not for publication

25 yearsFounded in the UK in 2001Programmes run on the LeadScale Engine™

Lead validation

Lead validation is the part of the LeadScale Engine™ that checks lead and contact records before they are delivered into the systems that use them. Every lead receives four quality checks. Their criteria and the technical sequence are set for the programme.

On the LeadScale Engine, a record is checked before it is delivered into your systems. Format validation checks whether a value has the right pattern. Verification checks selected values against a third-party service to establish whether they are correct and true. Every lead receives the four quality checks described below, using the programme's criteria.

Validation and verification are different checks

A record can look valid without the information on it being true.

An email address, for example, can have the right structure and still be wrong. Format validation checks whether the value follows the pattern expected for that field. Most capture forms already do some version of this.

Verification goes further. It checks a value against a third-party service to establish whether it is correct and true.

The distinction matters because the two checks answer different questions. Validation asks whether the data looks structurally usable. Verification asks whether the value itself can be confirmed.

Neither is the same as lead qualification. Qualification is about whether a person or organisation meets the commercial criteria for an opportunity. Lead validation is concerned with the record and the checks applied to it before delivery.

If technically valid leads are still being rejected by sales, our page on getting sales to accept your leads explains how to establish the acceptance requirements.

What happens between capture and delivery

Records can enter the Engine in several ways: by file transfer or upload, through an API, or through a configured integration. A website form can also submit records directly into the processing flow.

From there, the available processing can include seven stages:

  1. Ingest the record. The Engine receives the data from the agreed source.
  2. Validate and verify it. The checks run against the criteria configured for the relevant fields.
  3. Check for duplicates and repeat responses. Duplicate and frequency rules can be applied before further processing continues.
  4. Apply the programme filters. The record is tested against the additional criteria set for the programme.
  5. Use human verification. Every lead is reviewed by one of our team as the final quality check.
  6. Score, append or enrich the record. Where the programme requires it, additional processing can happen before delivery.
  7. Deliver the record. Records that meet the required checks are sent to the agreed destination.

This is not a fixed seven-step journey that every record receives. The programme determines which processing is needed and how it should be ordered.

The four lead-quality checks sit within this technical flow. Ingest, scoring or enrichment, and delivery remain separate operations where the programme includes them.

The order itself is part of the design.

A simple example is duplicate handling. If the Engine establishes that several records are copies of the same underlying record, there is no reason to run the same external verification lookup repeatedly. The duplicate check can therefore happen before that lookup.

The same principle applies across the flow: each stage produces an outcome, and that outcome determines what should happen next.

The Engine can deliver records to systems including HubSpot, Eloqua, Salesforce, Dynamics and Marketo, as well as through file transfer or API routes. The integrations catalogue covers the connection options. Our technical data services page explains the work involved in fitting the Engine into an existing workflow.

When a record is created through a LeadScale programme, information about its source also travels with it, including its timestamp, lineage and consent audit trail.

Why the checks happen before delivery

Checking early means obvious data problems do not have to travel through the rest of the marketing and sales stack before somebody finds them.

Some are simple typing mistakes. Others are deliberate nuisance submissions. Both can create work further downstream if the record is accepted without checking.

There is another consequence on programmes using paid media. Advertising systems learn from the conversion signals they receive. A form submission can therefore look like a positive outcome to the advertising system even when the information submitted is unusable.

The purpose of the validation stage is to establish what should be accepted before the record is delivered onwards.

The four checks every lead goes through

Every lead goes through the same four quality checks:

  • Data hygiene:

    fake names, profanity, malformed and incomplete records removed.

  • Contact verification:

    email, phone and domain checked against several sources.

  • Spec and duplication:

    job title, function, target accounts, suppression and company caps.

  • Human verification:

    On business contacts, a person checks the role and company are real and current.

Before processing begins, LeadScale agrees the criteria with the client and puts them into the programme flow. The specification sets what the receiving team needs the records to contain.

The available processing includes LeadScale's own checks and third-party lookups. Checks can cover names and email addresses, telephone numbers and postal addresses.

The fourth check is always a review by one of our team.

This is why the order matters as much as the list of checks. The flow can remove duplicates before an external lookup, apply a programme filter before further processing, or stop processing when a record has already failed a required condition.

A record that fails the checks required for its programme is screened out before delivery and is not sent into the destination system.

Questions technical reviewers ask

What is the difference between lead validation and lead verification?

Format validation checks the pattern or format of a value. Verification checks the value against a third-party service to establish whether it is correct and true.

Are the same checks used on every lead?

Yes. Every lead goes through the same four quality checks, finishing with a review by one of our team. The criteria they test against come from the programme. The technical steps that carry them out, including the order they run in, are configured for the programme before processing starts, so a duplicate check can still run before a paid lookup.

Does lead validation happen in real time?

Checking can happen at capture on form-based routes, while other records can enter through file, API or integration routes. The programme's required checks run before the record is delivered into the systems that will use it.

What happens to a record that fails?

A record that fails the checks required for the programme is not delivered into the destination system. On a Services programme, we don't charge for any lead that fails. Where a record can be fixed, such as when someone has changed job title, we correct it.

Does a person review every lead?

Yes. Every lead is reviewed by one of our team before delivery. On business contacts, a person checks the role and company are real and current.

Which systems can validated records be delivered to?

Records can be delivered by file transfer, API or configured integration. HubSpot, Eloqua, Salesforce, Dynamics and Marketo are among the systems LeadScale works with.

Is lead validation the same as lead qualification?

No. Validation concerns the record and the checks applied to its data. Qualification concerns whether the lead meets the commercial criteria used to decide whether it should be pursued.

Talk through the criteria for your records

If you want to understand how your records could be checked before they reach your CRM or marketing platform, bring the fields you collect, the criteria you already use and the systems the records need to reach.