Enterprise AI Workflow

Company Enrichment Pipeline

How a production AI pipeline enriched 173,517 company records in 70 hours — replacing 352 hours of monthly manual effort with a system built for reliability, not novelty.

The team needed verified company data for B2B lead generation. The manual process — searching, copying, and pasting from multiple sources into spreadsheets — could not scale. What started as a Google Sheets prototype became a production Python pipeline with concurrent processing, confidence scoring, deterministic validation, and human-in-the-loop review.

173,517

companies processed

77,487

verified leads

99.996%

processing success

$216.50

total API cost

352 hrs/mo

manual effort saved

Processing success measures whether the pipeline completed a record without error. It is not classification accuracy — the system does not claim every enriched field is correct. Confidence scoring and human review handle that separately.

01Business Problem

Manual effort that could not scale.

Foundit's B2B sales team needed enriched company data — industry, size, location, key contacts, tech stack — to build targeted lead lists. The existing process was manual: an analyst searched for each company across multiple sources, copied relevant fields into a spreadsheet, and moved to the next. At 173,517 companies in the pipeline, this meant roughly 352 hours of manual effort per month. The team had tried outsourcing, but quality was inconsistent and turnaround was slow.

The constraint was not access to data. It was the cost of extracting, validating, and structuring it at scale without losing accuracy.

02Start Where Users Work

The cheapest system to build is the one people are already using.

The first prototype was a Google Sheets add-on. The analyst's workflow already lived in spreadsheets — that is where they copied search results, cross-referenced fields, and built lead lists. Building the AI layer inside that environment meant the system met users where they already were, rather than asking them to learn a new tool.

The cheapest system to build is the one people are already using. Meet the workflow where it is, then improve it from inside.

03What Broke at Scale

A spreadsheet was the right place to start, not the right place to scale.

The Sheets prototype worked for a few hundred companies. At 173,517 records, it broke in three ways: rate limits from search APIs throttled throughput, the UI froze when processing more than a few hundred rows concurrently, and there was no way to recover from partial failures without restarting. A spreadsheet was the right place to start, but not the right place to scale.

01

Manual

Analyst searches, copies, pastes per company

02

Google Sheets

AI add-on automates search and extraction

03

Python Pipeline

Concurrent processing, retry logic, confidence scoring

04

Human Review

Low-confidence and ambiguous records routed to analysts

04Retrieval and Cost Decision

Three options. One survived the cost-to-reliability test.

The pipeline needed real-time web data for each company. Three options were evaluated against cost, reliability, and output quality.

Google Search Grounding

$0.35 / 1K requests

Rejected for scale

Pros

Direct grounding in search results, structured output support

Cons

Rate limits, inconsistent data formatting, higher per-request cost at scale

Perplexity API

$5 / 1K requests

Rejected for cost

Pros

High-quality synthesized answers, built-in citations

Cons

14x more expensive than Serper, slower latency, overkill for structured field extraction

Serper + Gemini

$0.25 + $0.10 / 1K requests

Selected

Pros

Serper for fast, cheap search result retrieval; Gemini for structured field extraction from snippets; best cost-to-reliability ratio

Cons

Two-step architecture adds complexity, requires careful prompt engineering

Serper handled high-volume search retrieval at $0.25 per 1,000 requests. Gemini 2.0 Flash extracted structured fields from the returned snippets at $0.10 per 1,000 requests. The combined cost of $0.35 per 1,000 was the same as Search Grounding alone, but the two-step architecture gave better control over retrieval quality, retry logic, and cost isolation.

05From POC to Reliable System

Four layers: retrieval, extraction, validation, routing.

The production pipeline was built in Python with concurrent processing, retry logic, and confidence scoring. The architecture had four layers: retrieval, extraction, validation, and routing.

01 · Retrieval

Serper API fetches search results for each company name + field combination. Concurrent requests with rate limiting and exponential backoff.

02 · Extraction

Gemini 2.0 Flash extracts structured fields from search snippets using few-shot prompts. Returns JSON with field value and confidence score.

03 · Validation

Deterministic checks: URL format validation, email regex, phone number format, industry taxonomy matching, duplicate detection across records.

04 · Routing

Records are routed by confidence: verified leads go to the output file, low-confidence records go to human review, errors go to a retry queue.

The pipeline processed 173,517 records in 70 hours of runtime — an average of 2,479 records per hour, with 99.996% processing success (only 7 records failed unrecoverably).

06Human-in-the-Loop Design

Five confidence states. Humans handle only the ambiguous cases.

The system does not trust the model blindly. Every extracted field carries a confidence score, and records are routed into one of five states. Humans handle only the ambiguous cases — the system handles everything else automatically.

Verified77,487 records

High-confidence extraction that passed all deterministic validation checks. Routed directly to the verified leads output.

Low confidenceRouted to review

Model confidence below threshold. Routed to human review for manual verification before entering the lead pipeline.

AmbiguousRouted to review

Multiple conflicting values extracted, or validation checks failed. Human reviewer resolves the conflict.

DuplicateAuto-skipped

Company already exists in the output dataset. Detected by name normalization and domain matching. Skipped automatically.

Error7 records

API failure, timeout, or unrecoverable parsing error. Routed to retry queue. Only 7 records failed after all retries.

Models for probabilistic judgment. Code for validation. Humans for ambiguous cases.

07Outcomes

70 hours of runtime. 352 hours of manual effort replaced.

The pipeline ran end-to-end in 70 hours and replaced 352 hours of monthly manual effort. Total API cost was $216.50 across 173,517 records.

Volume

173,517

companies processed

77,487

verified leads

Quality

99.996%

processing success

7

unrecoverable errors

Runtime

70 hrs

end-to-end

2,479/hr

throughput

Cost

$216.50

total API cost

$0.001

per record

Hours saved

352 hrs/mo

manual effort saved

352 hrs/mo

manual effort replaced

Cost breakdown

ComponentCostNote
Serper search API$173.52694,068 requests @ $0.25/1K
Gemini 2.0 Flash (enrichment)$20.12field extraction from snippets
Gemini 2.0 Flash (industry mapping)$18.87taxonomy classification
VM compute$4.0070 hours runtime
Total$216.51$0.00125 per record
08Security and Data Boundaries

Company data, not user PII. Boundaries still enforced.

The pipeline handled company data — not user PII — but data boundaries were still enforced.

No PII in prompts

Company names and public business attributes were sent to external APIs. No employee, candidate, or user personal data was included in any API call.

API key isolation

Serper and Gemini API keys were stored as environment variables on the VM, never hardcoded in source or committed to version control.

Output access control

The enriched lead dataset was written to a restricted directory. Only the sales operations team had read access to the final output.

No data retention by vendors

Both Serper and Gemini were used in non-training mode. No company data was retained by the API providers after request completion.

09What I Took Forward

Three lessons that now shape every AI-enabled workflow I build.

01

Start where users work

The Sheets prototype was not a throwaway. It was the fastest way to learn what the system needed to do. Production code came after the workflow was understood, not before.

02

Separate probabilistic from deterministic

Models are good at probabilistic judgment. Code is good at validation. Confusing the two — trusting a model to validate, or using code to judge ambiguity — produces unreliable systems.

03

Design for confidence, not accuracy

The system never claims 100% accuracy. It claims 99.996% processing success and routes everything uncertain to humans. That is a more honest and more useful framing for production AI.

Models for probabilistic judgment. Code for validation. Humans for ambiguous cases.

Back to AI Lab

All AI systems and experiments