Why this exists
Enrichment jobs fail expensively: wrong column mapping, provider schema drift, or a filter that matches 10x the rows you expected. The fix is a discipline, not a tool: pilot on zero-cost rows, inspect, then batch.
The procedure
- Freeze the input. Snapshot the CSV/table you are enriching. Name it with date + purpose (
2026-07-02-tam-emails.csv). Never enrich a moving target. - Pilot on one row. Run the full waterfall on a single row. Check: does every column land where expected? Are fallbacks firing in the right order?
- Estimate spend. Multiply observed credit burn by row count. Write the number down before you run the batch. If it surprises you, stop.
- Batch in tranches. 250-1,000 rows per tranche. Validate coverage after each: fill rate per column, validation pass rate, provider mix.
- Log the run. Input file, tranche ranges, spend, coverage. Future-you needs to know what was enriched, when, and from where.
The checks that catch 90% of failures
- Fill rate suddenly jumps or crashes between tranches → provider drift, stop and re-pilot.
- Validation pass rate below 90% on emails → do not load into your sequencer, fix first.
- Any column with mixed formats (dates, phones) → normalize before CRM write-back, not after.
Make it permanent
This playbook is exactly what we automate in client engagements: the pilot, spend estimate, tranche validation, and run log all become code that runs without a human remembering to be disciplined.