Engineering Atlan’s inbound lead system: Missing Data Never Says “I Don’t Know.” It Says No.
78.5% to 99.9%
Lead routing coverage
Under 30 seconds
to assignment
+57%
Deal creation trough to peak
Atlan had no shortage of inbound leads. What it had was no way to tell which ones mattered, and no working mechanism to put a good one in front of a rep.
Three things were broken, and they turned out to be the same problem wearing different clothes.
The data describing a lead was missing or wrong. The logic judging a lead defaulted to “no”. And the workflow named Lead Routing didn’t route anything at all.
The Problem
Three Failures, One Root Cause
There Was No Enrichment at All
Not poor enrichment. None. When an inbound lead arrived, nobody knew how big the company was, what the prospect did there, or which territory they belonged to.
A BDR picking up a new lead opened a browser and started researching: company size, location, seniority, whether this was even a legitimate buyer.
Every minute of that was time the lead spent waiting. Speed-to-lead is the one inbound metric where every extra minute costs more than the last: a prospect who filled in a form ten minutes ago is a different prospect from one who filled it in yesterday. Atlan was spending that time on manual lookups.
Where data did exist, it disagreed with itself. On one account, one system reported a handful of employees while another reported several thousand: a difference of three orders of magnitude on the single field that decided whether anyone would ever call them.
And No Way to Tell, at a Glance, Who Was Worth Calling
Nothing in the record said qualified or not. There was no field to sort on, no flag to filter by, no way for a BDR opening their queue in the morning to tell a strong lead from a dead one.
So they worked it out by hand. Every lead meant opening a browser: headcount, location, seniority, whether the company was already a customer, a partner, or sitting inside an open opportunity. Hours of qualification research before anyone picked up a phone, repeated per lead, across a queue that refilled daily.
The ICP check that did exist depended on Salesforce fields absent for roughly 40% of contacts, which meant an estimated 10% of genuinely qualified leads were being missed by the automation that was supposed to help.
And this is the constraint that shaped everything we built next: a qualification rule with no data behind it does not return “unknown”, it returns “no”. It rejects silently, and it looks authoritative doing it. Which is why the enrichment layer had to come first, and had to cover the whole database, before any rule sat on top of it.
And the Routing Didn’t Route
The workflow named 2025 Lead Routing – Sales Actions was audited in the first weeks of the engagement. The finding:
“…doesn’t do any owner assignment. It just sends a Slack notification, updates the lead status and some list member additions.”
- Workflow audit
It notified. It tagged. Nobody was ever assigned.
Meanwhile everything reached BDRs regardless of quality, including categories that should never have been in the queue:
“Not routing leads which are clear junk, for example, Gmail leads. We’re still getting Gmails. We are still getting leads which have open opportunities. We’re still getting leads which are clear partner.”
- Senior leadership, Atlan
Nobody could even describe how the assignment was supposed to work. From an internal thread that autumn: “How do we assign BDRs to a specific lead? Is there a dedicated field in HubSpot? Do we pull it from Outreach? Or is it round-robin?”
“The leads have entered the new leads funnel however they are still not assigned to any BDR. This is impacting our speed to lead.”
- Senior leadership, Atlan
The Approach
Benchmark Before You Buy
We ran a controlled accuracy study before picking an enrichment vendor: a stratified sample of accounts across three company-size bands, tested against six commercial data providers plus a custom AI website scraper.
Ground truth was each company’s own About page, chosen deliberately, because that is exactly what a BDR checks when verifying a record by hand. The benchmark measured against the human standard the automation was there to replace.
Accuracy was scored with z-score and standard-deviation anomaly detection. Every provider was costed per thousand leads and ranked on accuracy. The waterfall was designed against a budget from the start.
The ranking overturned the assumption: Datagma, then ZoomInfo, Apollo, HubSpot, Leadmagic, and Clay last. The most established sources were not the most accurate, and no single provider won across every field.
Then one design rule for everything downstream: whatever the system decided, it had to say why. A qualification verdict a rep cannot interrogate is a verdict a rep ignores.
What We Built
Each Layer Depends on the One Before It
01. Enrichment That Shows Its Sources
Clay runs the waterfall. ZoomInfo, Datagma, and Apollo supply the data. Clay handles the orchestration: sequencing providers, handling fallbacks, writing results back to HubSpot.
The benchmark justified that split. Clay’s own native enrichment ranked last of the sources tested, so we used it for orchestration only.
The waterfall is configured per field: each attribute is sourced from whichever provider tested most accurate for it, falling through on a miss. That produced a clear division of labor.
ZoomInfo covers firmographic fit: revenue and employee count. Apollo covers person-level detail: job title, email, and location. Datagma ranked first overall but was rejected for billing state, where its region handling proved unreliable.
Every enriched value carries a receipt. A Clay Enrichment Details field records which provider supplied which attribute, contact by contact:
First name: HubSpot | Last name: HubSpot | Job title: Apollo | Country: Apollo | State: Apollo | City: Apollo
Enrichment originally ran as a nightly batch. The client’s response was blunt: “This doesn’t serve our purpose.” They were right: a lead enriched tomorrow morning is a lead that waited overnight. We rebuilt it on webhooks to fire in real time, as records are created.
02. Qualification That Explains Itself
Seven Known Conditions, all of which must pass: bounce status, account type, email domain, email address, company name, opportunity stage, and source. Then three Workable Conditions, of which at least one must be met: a minimum account fit score, ICP geography green or yellow with enterprise-scale employee count, or AI-assisted research returning qualified.
Every Known Condition treats a null as a pass. With roughly half the database missing key attributes, a formula that failed on unknown would have disqualified most of it for reasons having nothing to do with fit.
Three of the seven conditions exist purely to remove internal noise: records whose email, domain, or company name contained the client’s own name, or the word “test”. Internal and test records had been sitting in the inbound BDR queue, indistinguishable from genuine prospects.
Every verdict returns a reason, drawn from eleven ordered codes: seven explaining why a lead was rejected, three explaining which condition qualified it, one catch-all. A rep who sees “No, Account Type is Competitor/Partner/Customer” can act on it. A rep who just sees “No” cannot.
It applied backwards as well as forwards. We built it as a calculated property, so it evaluated the entire historical database the moment it deployed.
Every existing contact received a verdict and a reason at once. The BDR queue became sortable on day one, with no separate re-processing project required.
And it was measured, then hardened. A refinement pass found roughly 30% of leads were being disqualified incorrectly: edge cases in bounce handling, opportunity-stage dates, and internal-record detection.
The definition was rewritten around what that analysis showed. Soft bounces were made to pass instead of fail, opportunity-stage logic was rebuilt on the correct date field, and the three internal-noise conditions were added.
03. Routing That Assigns
Knowing a lead is worth working is useless if nobody owns it. Assignment was rebuilt on geography, keyed to BDR sales territory, with a deliberate fallback chain for the common case where a contact isn’t correctly linked to a company record: IP state, then IP country.
That only worked because of the layer beneath it. Geography was one of the least reliable fields in the database. The same enrichment waterfall that resolved ICP geography is what made territory-based assignment viable at all.
Underneath sat unglamorous correction work: standardizing state and country codes that had drifted apart between HubSpot and Salesforce, silently breaking territory lookups.
“If we’re able to do any enrichment, we’re able to identify it’s a good company, it’s an ICP check, then we assign it.”
- Senior leadership, Atlan
The loop closed that November, when an entire account segment was found missing from the routing workflow, pulling inbound leads away from reps already working them. Found and resolved the same day.
What Moved
Measured across all inbound leads with recorded web activity.
Four metrics moved, and they moved together, because they were never four separate problems. Leads reached an owner instead of nobody. They reached that owner in seconds instead of after a manual lookup.
And the qualification layer began selecting for the population that converts. Pipeline creation rose through the build.
Inbound Leads Assigned to a BDR
Coverage sat below 85% for a year, then jumped to near-total within a single month of the routing rebuild going live.
And They Reach Them Immediately
Assignment now happens in under 30 seconds of a lead entering the CRM. For leads the system qualifies as workable, first outreach follows in under 10 minutes.
That is hours of qualification research reduced to a ten-minute window. Enrichment resolved the firmographics before a human ever looked at the record. The workable definition turned those fields into a verdict with a stated reason.
Geography-based assignment put the lead in front of a named owner. What was left for the BDR was the only part that ever needed a person: the conversation.
Enrichment Coverage and Qualification Coverage Are the Same Thing
The share of leads with no resolvable geography, plotted against the share the formula could return no verdict on. The two move together at r = 0.87: every lead the waterfall cannot resolve becomes a lead the formula cannot judge.
Deal Creation, Quarter on Quarter
Pipeline climbed through the build period: +57% from the Q2 trough to the Q4 peak, and +41% against the opening quarter.
71.6% of all deals created in the period originated from contacts the system had flagged workable: the qualification layer was selecting for the population that converts.
Proof Points
What the engine does now.
- 78.5% to 99.9% of inbound leads assigned to a BDR
- 21.5% to 0.1% of inbound leads reaching nobody
- Under 30 seconds from CRM entry to assignment
- Under 10 minutes to first outreach on workable leads
- r = 0.87 correlation between unenriched and unjudgeable leads
- 71.6% of all deals from leads flagged workable
- +57% deal creation, trough to peak
- Retrospective: every historical record scored on deployment
- Six data sources benchmarked against ground truth before selection
- Eleven reason codes: every verdict explains itself
- Per-field provider waterfall, costed at design time
- Real-time enrichment via webhook, replacing nightly batch
Email Deliverability and Data Quality
The Problem
Bounce rates on outbound and marketing campaigns were unacceptably high, with inconsistent data quality across HubSpot, Salesforce, and Outreach. GDPR compliance was also at risk without a clear opt-in system.
The Solution
We rebuilt the deliverability and data layer end to end:
- Cut bounce and failed sends by 30%+ across sales and marketing campaigns
- Introduced an opt-in honor system to ensure GDPR compliance
- Built Clay-powered enrichment for work emails, personal emails, and phone numbers
- Cleaned and synced all fields across HubSpot, Salesforce, and Outreach
- Procured and integrated tools for web visitor identification, inbox warmup, live chat orchestration with HubSpot sync, and LinkedIn sync
- Audited SDR workflows and standardized data flow across all three platforms
The Outcome
- Higher inbox placement and engagement across campaigns
- 30%+ reduction in bounce rates
- GDPR-compliant opt-in processes
- One unified RevOps workflow for SDRs and marketing teams