How I structure Clay tables
One table per use case, not one master table for everything. The architectural decision that keeps Clay builds maintainable.
The most common mistake I see in Clay setups is the master table, one giant sheet that does enrichment, scoring, filtering, and output all in one place. It works until it doesn’t, and when it breaks you can’t tell which column caused it.
The structure I use on every build:
Intake table. Raw input only. Pulls from CRM, webhook, CSV, or API. No enrichment columns. Just the seed data: company name, domain, contact name, source. This table never gets touched once it’s set up.
Enrichment table. Waterfall only. Takes the intake table as input, runs all provider lookups. Clearbit, Apollo, LinkedIn, Hunter, whatever the build needs. Outputs a clean enriched record. No scoring logic here.
Scoring table. Takes the enriched table and applies ICP logic. Firmographic filters, intent signals, tech stack checks. Outputs a score and a tier. Nothing else.
Activation table. Takes scored records above threshold and prepares them for output. Formats the message, generates the personalisation tokens, sets the routing destination. This is where Claude API calls live if you’re generating copy.
Four tables, clean separation of concerns. When an enrichment provider goes down, you fix the enrichment table and nothing else breaks. When your ICP scoring logic changes, you update the scoring table without touching the waterfall.
The downside is it’s more tables to manage. The upside is that six months later when you’re debugging why a record didn’t route correctly, you can trace exactly which step it fell out at.
One more thing: name your columns like a database schema. company_domain not Company Domain. Downstream tools (n8n, HubSpot, Salesforce) will thank you.