← All client work/Sales · Real-time

DeliveredSales · Real-time

Real-time lead engine case studyVerified sales leads from 130+ sources, checked before they ever reach the CRM.

A company's best sales moment is a specific, time-sensitive event — and catching it was manual and slow.

ClientLegendrings · Kyle Ferbey

ProjectChampionship-Intelligence / Real-Time Lead Engine

My roleSenior developer, end to end

StatusDelivered

Discuss a similar build

Dashboard with cards for conferences, clinched seasons, synced coaches and pending jobs, a stopped GPU instance panel and a list of recent pipeline runs.

The real product, shown with demo data.

130+Sources monitored

5Automated stages, discovery to CRM

GuardedA clinch is declared only when every validation check passes

TwiceEach clinch is re-checked with the same rules before anything is written to the CRM

In short

A company's best sales moment is a team mathematically securing a title. I built a five-stage automated pipeline across 130+ sources with a guarded detection algorithm, contact enrichment and CRM sync — so sales gets a checked lead soon after it happens.

01 · The situation

The best sales moment is easy to miss.

A company's best sales moment is a specific, time-sensitive event (a team mathematically securing a title). Catching that moment across 130+ differently-built sources was manual, error-prone, and slow — and a false signal destroys trust with the sales team.

02 · The challenge

Zero tolerance for false signals.

Extract live data from 130+ inconsistent sites; compute a mathematically correct “clinch” without false alarms; then enrich a verified contact and push a clean lead into the CRM with no duplicates or mismatches.

03 · What I built

A five-stage lead engine.

Source discovery, data extraction, the detection algorithm, contact enrichment, and CRM sync — with a dashboard to run, monitor, and review every stage.

Run results page with totals for URLs processed, teams extracted and clinches, and one conference expanded to show its standings and magic-number calculation. — A run's results. Each clinch shows the standings and the arithmetic that proves it.

Conference seasons table showing sport, season, a clinched status badge, the winning team and its coach. — Every conference season, its status, the winner and the coach linked to it.

Coach data table with contact details, team, a quality badge of complete or minimal and a CRM sync status. — Enriched coach leads, each graded for contact quality before it can reach the CRM.

CRM sync page with counts ready, synced and failed, a dry-run checkbox and a recent sync log showing success, failed and skipped-duplicate rows. — CRM sync status, with a dry-run option and a log of what was synced, skipped as a duplicate or failed.

Screens from the real product, captured with demo data. No client or customer data is shown.

04 · How it works

Five automated stages, verified at every step

01Source discovery130+ differently-built sources
02AIExtractionRules first, local LLM for edge cases
03Detection“Magic number” + validation guards
04EnrichmentValidated contact details
05CRM syncRe-verify, dedup, audit log

The engine watches 130+ sources, detects the exact moment that matters, finds the right contact and creates a clean CRM record — re-checking the event before anything is synced.

05 · The hard engineering

Correct first, then fast.

A signal only counts after it passes every guardHow false positives are filtered out

Candidate“Magic number” reached

✓Minimum games played

✓Season-completion threshold

✓Real-data checks

✓Event re-verified before CRM sync

ResultVerified lead → CRMDeduplicated · audit-logged

Hybrid extraction

Rule-based parsing is accepted when it is confident; only the remaining pages go to a local LLM, run through Ollama on a GPU instance that is started for the run and stopped after it.

Guarded detection

A “magic number” calculation wrapped in guards built to keep false clinch signals out: minimum games played, at least half the season complete, a clear win gap and a verified schedule length.

Validated enrichment

Queued, retrying workflow that checks format, sanity, duplicates and correct matches.

Safe CRM sync

Re-verifies the event, then creates records with dedup and audit logging.

GPU cloud orchestration

Scraping and local-LLM inference ran on GPU cloud instances, orchestrated programmatically, with monitoring and notifications.

06 · Key decisions

The calls that shaped the build

Why so many guards on the detection?

A false signal destroys trust with the sales team — it was the costliest possible failure. Guards like minimum games played and season-completion thresholds filter it out.

Why rules first, local LLM as fallback?

Rule-based parsing is fast and free, and its result is accepted when it is confident. Only the pages it cannot read confidently go to the local model.

Why re-verify before CRM sync?

By the time a lead reaches the CRM, the event has been checked twice with the same rules, and a lead that was already delivered is skipped rather than created again.

07 · The outcome