6
tables live in the GTM Engine workbook
This is the map I built. It starts as a wide TAM funnel and narrows through a stack of tables that each filter harder than the last, so the last table isn't a guess. It's the people who own the motion, each behind a validation check and a human approval gate before anything sends.
Before the individual tables, here's the shape. Clay's power isn't any single table. It's that each table takes the output of the one before it and narrows it, eight hops deep, until what's left is only the contacts that survived every filter. A person doesn't hand-build a list. The engine surfaces it and keeps it current.
The way to think about Clay is the tables feeding each other. You start with a big funnel, the whole TAM for a motion. I rate, tier, and grade every account on how ready it is for us to reach out. The A and B accounts flow into the next table, which filters them further. You take a column of results from that table, feed it into the next, and that happens hop after hop depending on the motion, until you get to the final contacts.
So when Nate opens that last list, the argument is about weights, not names. They've been filtered enough times that we know they own the Stars portion of the business at that account, they're in our TAM, and the send gate only passes rows with a validated email. That list is ready, set, go, instead of him searching LinkedIn, building a Sales Nav list, guessing at emails, and only then thinking about a message.
This is a head start, not a finished product. The core of the engine is built and validated on the Star Ratings new-logo motion. The outer layers are designed and next to stand up. Nothing has touched a prospect.
I want to be precise about the state. Six tables are live: Accounts, Contacts, the CMS source, and three reference tables. All 137 contacts have been through ZeroBounce; around 106 carry a deliverable email, and the rest stay visible but can't pass the send gate. The signal automation, the delivery sync, and the reply loop are designed and specced, next to stand up. And to get all of this to where it is cost just over 200 of the 5,000-credit allocation, because the guardrails stop it from spending on anything out of window.
Each rung is a Clay table. Each arrow is a real column, a write or a lookup, that carries rows into the next table only if they pass that table's filter. The funnel narrows on purpose.
Eight hops, and every arrow is a column doing the carrying. A row only moves to the next table if it clears that table's filter. That's why the bottom is narrow and trustworthy instead of wide and noisy.
Click any layer to open its detail: the purpose, what feeds it, what it writes to, and the columns that do the work. Turn on the presenter script above for the line I'd actually say on each.
Source tables land the raw universe so a re-import never clobbers enrichment downstream. The CMS table is live: the public 2026 Star Ratings universe, filtered to the plans that are actually in window, below 4.0 stars. The customer-exclusion wire is next, pending your flagged customer file, so the same filter can also drop anyone who's already ours. The Install-Base import is designed, not built; it waits on Salesforce access and will seed the back-office motion. Only rows that pass the window filter get written up into Accounts.
This is the top of the funnel. I keep the raw CMS file in its own table so re-importing October's release never wipes the work we did on the live accounts. The window filter means we only ever pay to enrich a plan that's genuinely a target. The piece I'm holding for your flagged customer file is the exclusion wire, so the filter also drops anyone who's already ours, and that's the same gate holding Wave 1.
This is the hub. Every account gets a fit score, an intent score, and a letter grade from those two. Grade is the gate: only accounts above the grade line push down into Contacts, and where that line sits is one of the dials we set together. This is where "who's worth our breath" gets decided, and it's config-driven, not hardcoded in.
This is the funnel's first real narrowing. I rate and tier every account on how ready it is, and only the grades above the line earn a push to the contact layer. The scoring weights and where that line sits are the things I'd most want your read on, because that's the judgment call that shapes everything below it.
This is what keeps the list alive instead of a dead snapshot. Each signal is one column that fires a point value when a trigger hits: Stars language in an SEC filing, an earnings-call mention, a new quality leader, a claims backlog. Those points flow back into the Accounts intent score and can lift an account's grade or, for the strongest triggers, fire it straight toward outreach. It's also what removes accounts that fixed their own Stars and don't need us anymore.
This is the "why now" engine. It's designed and specced, and it's the layer that mirrors what our own product does, real-time signals triggering action. It's also self-cleaning: when a plan gets itself to four stars, Clay sees it and drops them off the list, so we're never reaching out to someone who no longer has the problem.
This is the payoff table and the one that's most complete. Accounts push in, then a people-find pulls the right personas by title, a persona-key formula classifies each into the buying committee, and an email waterfall finds an address that ZeroBounce then validates. Anything without a valid mailbox can't pass the send gate. Three tags get stamped at creation and never change: engine-sourced, source motion, and sourced date. Those three are how we'll prove the engine's contribution later. Honest state: all 137 rows have been through ZeroBounce on the canonical email field; around 106 carry a deliverable email, and the invalid or email-less rows stay visible but gated.
This is the ready-set-go list. 137 contacts across the eligible Tier A and B parents, personas matched, and around 106 with an email we validated through ZeroBounce for under fourteen credits total. Invalid ones stay visible but the gate won't let them send. And every row carries the tags that let us build a shared scoreboard on what the engine actually surfaced.
Message Gen writes a personalized variant per contact from the account's why-now and the right product angle. It's fenced by small reference tables: a Verified Metrics library so the copy can only use approved numbers, a Product-Angle map that routes a title to Queue Optimizer or Back Office Optimizer, and the locked ICP rubric. Those three are built; a fourth, the variant library for testing, comes with the generation column. That column is the next to wire, and the deeper personalization I'd run through Claude, not templates in Clay.
Clay's job here is to surface accurate people and the why-now. The tailored writing lives in Claude, and the reference tables are the guardrail that keeps an unapproved number from ever reaching a payer. I'll show the full split two sections down, it answers the messaging-logic question from our call.
Nothing sends from Clay directly. Every row that reaches here runs a critic check first. Today the critic checks email validity; the scope, claims, and length checks land with Message Gen. Then it waits on a human checkbox. That gate is built and every single row is held. This is the "human before send" rule made physical.
This is the safety layer, and it's live. The critic catches the mechanical stuff, and then it physically cannot move without a person checking the box. Every row is held right now. That's deliberate, measurement and approval before any volume.
On approval, this hands the verified email and approved copy to Nate's sequencer and writes the source tags onto the Salesforce record. A parallel deliverability monitor watches warmup, inbox rotation, and bounce rate, and it gates the whole thing: the sender stays off until inbox health is green. This is the layer that stops spray-and-burn.
This is the tie to the Salesforce conversation. When Nate approves, the contact and its source tags land in Salesforce automatically, so there's no gap between what he's working and what leadership sees. And the send webhook stays off until deliverability is green, so we protect the domain from day one.
A reverse webhook writes reply and meeting status back onto the contact row, and the attribution table reads those tags to compute the two-motion funnel: enriched, sent, opened, replied, qualified, met. Because the source tags were stamped at creation, we can see what the engine surfaced without arguing about it after the fact. I'd frame this as a shared scoreboard we define together, not a credit claim.
This is how we measure ourselves honestly. Surfaced and realized stay separate, never blended. I'd want us to co-define what "engine-sourced" means so it's a shared scoreboard, not me claiming credit. The tagging is already in place to make that clean.
The last table turns everything above it into a daily view per rep: the A and B accounts with a fresh signal, their committee, the why-now line, and the suggested product angle, filtered to that rep's territory. This is what a seller opens each morning. It's the point of the whole engine, a human working a short, sharp list instead of researching from scratch.
Everything upstream exists to make this one screen good. Nate opens it and works a filtered, current list with the why-now already written. The research part is done for him, and that's the time we're buying back.
When I say a table "feeds" another, this is the actual mechanism. There's no magic, just three kinds of columns chained together, hop after hop, and that chaining is where the depth comes from.
Sends rows from one table into the next, filtered first so only the right rows go, only Grade A accounts, only valid-email contacts. This is the arrow that narrows the funnel at each hop.
Reads a value from another table by a join key. It's how a signal writes intent back onto an account, and how Message Gen pulls only an approved stat from the Verified Metrics table.
Gates every enrichment: only-run-if-empty, only-if-in-window, only-if-in-ICP. This is what makes it cheap enough to run continuously instead of burning the budget in a week.
Chain those three and you get the depth. Accounts writes into Contacts if the grade clears, Contacts writes into the Send Queue if the email's valid, the Queue writes to sync if a human approved, and the reply comes back through a lookup. Clay only flows one direction, so any true write-back to source data goes through Salesforce or a webhook, not a table pointing at itself.
This is the design decision behind the whole messaging layer, and the answer to the question from our call. Clay never writes a sentence a prospect reads. Claude never touches a row of data directly. Everything they exchange passes through the Contacts table, where it stays visible, gated, and auditable.
Deterministic, per-row work that runs the same way every time and leaves a value in a column you can audit.
Judgment work, packaged as skills that run the same for whoever invokes them. Nate runs the drafting himself; nothing routes through me. Each skill takes the row Clay assembled and turns it into something a person would actually send, fenced by the Value Repository so only approved claims appear.
The reason I split it this way instead of cramming the messaging into a Clay system prompt: an AI column in Clay is a black box that burns credits per row and can't be argued with. Keeping the writing in Claude means the copy logic is a document we can read, edit, and version together, the claims discipline is enforced in one place, and Clay stays cheap because it only does the deterministic work.
And the part I want to be unmissable: this is not a me-in-the-loop system. The skills are tools, and they write the same whether I invoke them or Nate does. He drafts, handles objections, and preps calls with the same tools I built them with. My job is keeping the tools sharp and the claims file current, not ghostwriting sends. If I'm out for a week, the engine doesn't slow down.
Two things from our call worth making concrete: the spend guardrails, and why connecting to Salesforce closes the gap between what Nate works and what leadership sees.
credits used of the 5,000-credit allocation to build and validate the whole Stars list.
The point of wiring Clay to Salesforce is that once a contact is surfaced, it becomes an account and contact in Salesforce automatically, with source tags attached. No one re-creates it. No gap between Nate's work and what execs can see.
On credits, the guardrails are the reason I could build this whole thing for just over 200 of the 5,000 allocated. It won't run away because it asks before it spends and refuses to enrich anything out of window. On Salesforce, the case for getting everything talking is exactly what Cheryl said, it makes it easier for everyone when leadership asks how things are going. The tags flow in on their own, so there's never a gap between what Nate's doing and what the execs can see.
The engine is built to run on dials we set together, not on my assumptions. Three of those dials are worth a few minutes today.
None of these block progress, the Stars motion is ready to pace on today. But these are the three dials I'd rather set with you than guess at, because they're the judgment calls, and getting them right early is what keeps the whole thing pointed at the right people.