GTM Engineering Data: Building the Account Layer

Your list of prospects / leads is the most important part of your GTM because it defines who you're spending time and money on. With a bad list of leads, a signal becomes meaningless because those people would never buy from you anyway, regardless of any signalled reasons implying that they should. An opening line is only as good as the address beneath it, so the sharpest email you have ever written still bounces if the person left the role in March. Whatever you build on top, the outbound and the ads and the signals, inherits the quality of the data underneath it, which is why this layer comes first and why it is the least glamorous thing in the stack.

The first article in this series made the case that GTM engineering exists because researching a company stopped costing anything. The data layer is where that plays out. When one accurate contact took an SDR twelve minutes, lists stayed small out of necessity; now that the same contact costs a penny, a list can be large and precise at once, and the real work shifts from finding data to deciding what to keep.

Start with the selection, not the list

Founders ask how to get five thousand leads. The question worth asking is which two hundred of those five thousand deserve an email, because the precision lives in the filters and not the volume. A list is just the output of a definition, and a loose definition produces a long list that converts at nothing.

So the first thing you build is not a list at all, it is the ideal customer profile (ICP): the precise description of who you sell to, narrow enough that a stranger could sort accounts into "yes" and "no" using it: read this article to learn how. That definition then does its work in three passes.

• The firmographic pass fixes the company, by size, sector, region and funding stage.

• The persona pass fixes the person inside it, by title, seniority and department.

• The timing pass is the one most teams skip, and it is usually where the money is.

Take a selection like "mid-level managers who changed companies in the last sixty days at Series B fintechs". Each clause removes far more than it sounds like it should, and what survives is a different quality of list. Someone in their first two months in a new role is between 5-10x more likely to bring in a new vendor than a counterpart who has been in the seat two years, and new executives spend around 70% of their budget inside the first hundred days (First Sales, UserGems). A "manager at a fintech" is a title. A "manager who started six weeks ago and is still choosing their tools" is a reason to send the email this week, which is the same job a buying signal does, built into the selection itself.

The firmographic pass has a sharper form than a list of filters you assemble by hand. Feed a tool like Ocean.io your best existing customers and it returns the companies most similar to them. A close twin of your top account is a better bet than everything sharing its industry code, because those codes group businesses that behave nothing alike.

This is why the order in the stack matters. Enrichment pointed at a loose ICP just enriches the wrong people faster and more expensively, so the definition has to be tight before a single credit gets spent against it.

Waterfall enrichment, and why one provider is never enough

Once the selection is set, you need verified contact details for the people it returns, and waterfall enrichment is how you get them without betting on a single provider.

The naive approach is to buy from one data provider and accept whatever it has. The problem is that no provider covers everyone: a single source typically returns a valid, verified email for 55% to 70% of a B2B list (Clay's own benchmark), and the gaps are not random. A waterfall queries several providers in sequence for the same person and pays only when one returns a verified result. Provider A runs first because it is cheapest; when it has nothing for that contact, the request falls through to B, then C, then a live web scrape if it comes to it. Stack three or four sources this way and coverage climbs to somewhere between 80% and 92%, while you still only pay per successful lookup.

The reason to bother is that provider coverage is regional, and badly so. ZoomInfo has the deepest United States enterprise data, direct dials included, on contracts that start around $15,000 a year, and it thins out noticeably across Europe, the Middle East and Asia. Apollo carries roughly 275 million contacts and is the cheapest way to start, though quality outside the US is uneven and thousands of teams are working the same records. A waterfall is how you stop betting an entire list on one vendor's blind spot, which matters a great deal more once your accounts sit outside North America. The full breakdown of which providers to chain, and where each is strong or weak, is the tech stack piece; at this layer the point is only that you never lean on one.

None of this is free at scale. A waterfall email lookup runs roughly 4-8 credits in Clay, landing around $0.12 to $0.18 a record before provider fees, and phone numbers cost several times that (Clay, after its March 2026 pricing change). At a few hundred contacts it is rounding error; at 50,000 it is a line item, and it is the reason the selection has to be right first.

What Clay does

Clay is the tool most associated with this layer, and it is easiest to understand through what it replaces. The old way to run data was four separate jobs: find it, enrich it, reshape it, then export it into whatever came next. Find, enrich, transform, export. Each was manual, and each lived in a different tool or a different SDR's spreadsheet.

Find. Rather than holding its own database, Clay plugs into a shelf of providers and lets you pull from any of them, charging for the data used rather than a seat. Its scraping agent, Claygent, will go and read the open web for anything the structured providers do not hold.

Enrich. The waterfall above runs here, automatically, across whichever providers you have chained.

Transform. To your enriched database, you can add far more information: a lead score plotted across two axes, tags and categories that decide routing, or a drafted opening line that the outreach step will personalise further. The AI layer sits here.

Export. The finished, scored, deduplicated rows go out to a CRM, or straight into a sequencer to start outreach.

In practice a run through Clay follows a predictable path. You pull a set of companies that fit the firmographic profile, enrich them with the data you need to qualify them, then filter hard to the ones that genuinely match. Inside the survivors you find the specific people by title and seniority, run the waterfall to get verified contact details, extract whatever else you need about them (past roles, tenure, a recent post), and bring the whole enriched set back into one table ready to score and export. Companies, then people, then the details that make the message land.

The list is wrong within a year, so hygiene is not optional

A list decays whether you touch it or not. Around 30% of professionals change jobs in a given year, B2B contact data goes stale at north of 22% annually, and roughly 70% of business contacts have something change, title, phone or email, inside twelve months (Cleanlist, ZoomInfo). A list that was clean the day you built it is materially wrong by the next quarter, and a workflow that assumes otherwise is quietly emailing dead addresses.

Hygiene has two halves. The first runs before every send, and it is mostly subtraction: drop the catch-all domains that accept everything then bounce it later, the titles that matched your search string but not your actual buyer, and anyone who told you no in the last six months. Google and Yahoo filter any sender who crosses a 0.3% spam-complaint rate, whatever the authentication looks like, so a dirty list wastes the send and quietly degrades the domain you need for the good addresses. Deleting a fifth to a half of a freshly enriched list feels wasteful and is usually the highest-return hour in the whole build.

The second half runs on a schedule. Re-verify on a cadence, re-enrich the records that changed, and treat the list as something you maintain rather than something you finish. The job-change that invalidates one contact often creates a better one, since the person who just moved is now sitting in exactly the ninety-day window worth targeting.

Everything writes back to one system of record

The last piece makes the rest measurable. Every enriched account, every send and every reply writes back into a single CRM, HubSpot or Attio for most startups at this stage. A signal engine that nobody logs cannot be measured, and what you cannot measure you cannot improve, which makes the writeback the instrument panel for everything upstream.

That means designing the schema up front: the fields that hold each account's selection reason, its enrichment source, its score, and where it currently sits in the sequence, plus deduplication rules so the same company arriving from two selections does not get worked twice. Done properly, you can answer the only question that matters at this layer, which is which selections turned into meetings, and feed that answer back into the next build. Done poorly, you have a fast machine producing numbers nobody can trust.

The boring layer is the whole game

None of this is the interesting part of GTM engineering, which is exactly why it gets skipped. The teams that win are not the ones with the longest list or the cleverest tooling, they are the ones who wrote the tightest definition of who to sell to and then kept the data behind it clean. Everything downstream multiplies this layer, and multiplying a bad list just produces confident, well-formatted waste at speed.

Getting the data layer right is most of what we do in the first weeks of a GTM engagement at Simplicity Group, because it decides whether anything built on top of it can work. It is unglamorous work that is mostly deleting, and it is where the results come from.