What the LeadScale Engine™ can do

A website form can submit a record directly into the Engine for the programme’s processing. Lead submissions go through the four quality checks before delivery into the systems that will use them.

Each check also needs a decision on what to do with its result. A failed lead is corrected where it can be fixed, or rejected with a reason. Other record and exception handling follows the programme’s rules.

Needs approval

For Everest Home Improvements, the Engine checked phone numbers as people entered them on an enquiry form. It checked the format, then compared the number with a database of assigned UK numbers. A failed check prompted the person to correct the entry.

Everest chose to let people submit even if they ignored the prompt. Visitors had an opportunity to correct a mistake, but correction was not compulsory, so some incorrect numbers could still come through.

End

Records can also enter the Engine from a form built in another tool. A HubSpot form can be configured to send submissions across. A custom-built form can call the API. A form that fills a spreadsheet can provide records for upload.

The form tool and its setup determine the entry route. Once a record reaches the Engine, the programme’s processing takes over.

The Engine can also receive existing records by file, API or configured integration, and retrieve data from a client’s CRM or marketing automation platform. That data can be used in processing—for example, to keep existing customers out of a programme. The section on using existing system data explains the associated technical work.

This capability concerns checking lead and contact records before delivery. The checks can cover names, email addresses, telephone numbers and postal addresses, using LeadScale’s own rules and third-party lookups.

Validation checks whether a value has the right pattern. Verification checks it against a third-party service to establish whether it is correct. An email address can have the expected structure and still contain incorrect information, so the two checks answer different questions.

The record can also be filtered against requirements specific to the programme, such as information it must contain. Every lead goes through a review by one of our team before delivery.

A record that fails a check required for delivery is not sent into the destination system.

Our lead validation page explains the four checks and how the processing is configured.

The Engine can identify duplicate records and repeated submissions, then apply the programme’s rules. Those rules can include how often the same person may appear.

The position of the duplicate check matters. If it runs before a paid telephone check, the Engine can identify another copy without paying for the same lookup again. The processing order therefore affects both how a record is handled and whether a paid check needs to run.

Enrichment adds information to a record during processing. Contact information can include an email address, telephone number, LinkedIn profile or other profile information. For business records, the available additions also include company profiles and firmographic information about the organisation.

The fields are chosen for the programme and the type of record. Company attributes are relevant to business contacts; consumer programmes need information appropriate to the people they serve.

The programme’s required checks come before enrichment: adding a field does not establish that an existing contact detail is correct. Once the record passes those checks, the agreed fields can be added before delivery.

The data enrichment services page explains the work involved in adding information to records and delivering them for use.

Scoring is a separate processing step. A record can be scored against the criteria agreed for the programme, so a later step can act on the result.

Needs approval

Other processing can include normalisation, to put values into a consistent form, and classification, to place a record into a category.

End

A flow combines steps that receive and send data, steps that process it, and conditions that determine what happens next. LeadScale’s technical team designs that flow around the requirements agreed with the client.

For many programmes, delivery puts the record into one system and the job stops there. Orchestration can go further: the record goes to one system first, then what comes back determines whether it should go somewhere else.

A CRM, dialler and email platform can therefore take part in the same flow. The conditions decide which system receives the record next, rather than sending every record through the same route.

The Engine configuration section of our technical data services page explains how the technical team turns those requirements into processing and routing rules.

Records can be delivered into a CRM or marketing automation platform, an email platform or a dialler, as well as through API and file-transfer routes. A flow can deliver to one destination or several. Marketo, Eloqua, HubSpot and Pardot are among the most common integrations.

When a record is created through a LeadScale programme, the Engine keeps its source, timestamp, lineage and consent audit information with it as it moves through processing and delivery.

The client and LeadScale agree what the programme is trying to optimise for. Where you share outcome data, the Engine and connected systems can be configured around those outcomes. Depending on the programme, results can return from the client’s systems, and agreed outcomes can be passed into connected systems and used in later programme inputs. This feedback requires the relevant connections to be set up for it.