A repeatable list-import pipeline: normalize, domain-match, waterfall the email, then hand it over

The problem

The play

1. 1
   One template table, duplicated per event

   A master event-processing table lives in a shared workspace folder and is duplicated for each new list, with completed runs nested underneath so any past event can be reopened and audited. Input columns are colour-coded so a non-technical operator knows exactly which fields to paste and which are generated.

2. 2
   Normalize before you enrich

   Full name is derived from first and last rather than trusted from the source. Job titles from badge scans and registration exports run through an AI normalization step, because event titles are close to free text and inconsistent titles poison every downstream persona filter.

3. 3
   Make the company domain the match key, not the company nameMake

   The pipeline resolves company name to a domain first, and the domain is what gets checked against the CRM to answer 'does this account already exist, or is this net-new'. This is the dedupe control for the entire operation.

4. 4
   Enrich the company, then decompose the address

   The resolved domain drives a company enrichment, size, type, employee count, industry, full address, and the address is split into street, city, state and postal code as a distinct step. Unglamorous, and it is the difference between a CSV that loads into the CRM cleanly and one that needs manual remapping on every run.

5. 5
   Waterfall the email, then override the waterfall on purpose

   Person email is found by a waterfall: enrichment providers stacked in priority order, first hit wins, then a validation step checks the address is actually in use. The waterfall by default only forwards addresses that pass validation, which silently blanks rows where an address was found but failed verification.

6. 6
   Put the expensive lookups last

   Profile URL (via an AI-assisted lookup step) and phone number run at the end of the table, after the domain and email gates, so per-row cost is only incurred on rows that survived.

7. 7
   Stop writing to the CRM from three places

   The pipeline originally pushed directly from the enrichment layer into both the CRM and the marketing platform. That was retired. The enrichment layer now exports a cleansed CSV which is loaded through the dedupe and routing tool that already owns matching and assignment, and that tool writes onward to both systems.

What it moved

From a LeanScale case studyRead the full case study →