Clay

Building an Outbound Workflow With Clay

A stage-by-stage build for outbound in Clay: list, enrichment gates, scoring, verified contacts, personalization, deliverability rules and sequencer handoff.

Mauricio Esparza By ·Published ·8 min read
mithub.club
Short answer

An outbound workflow in Clay is a table built in stages: define the row, enrich only what passes a gate, score before you buy contact data, verify every email, personalize from facts you can point to, then hand the approved rows to a sequencer. Each stage should remove rows, not just add columns.

If you're new to the tool, start with What is Clay?. This article is the build itself: the order, the gate conditions, the deliverability rules you cannot negotiate with, and the numbers to watch afterwards.

In short

  • Order matters more than tooling. Enrich company → score → contact data → personalize. Reversing steps two and three is the most common way to waste a budget.
  • Gates, not filters. A gate is a condition that stops the next column from running, which is different from hiding rows in a view.
  • Verification is a separate job from finding. Clay reports statuses including valid, invalid, catch-all, unknown and role-based (Clay Docs).
  • Deliverability is infrastructure, not copy. Google and Yahoo both publish hard requirements for senders (Google, Yahoo).
  • The handoff is part of the build. A table with no destination is a cost centre.

Stage 0: decide what one row means

Before a single column, answer this: is a row a company or a person?

Mixing them is the original sin of outbound tables. Company-level research (locations, services, tech, hiring) belongs on a company table. Contact-level work (title, email, phone) belongs on a people table that was created from the companies that already passed. Two tables linked by domain beat one table with 60 columns, because you can see where the funnel narrows.

Write the row definition at the top of the table as a note: "One row = one US lending company with 8 or more branches." That sentence is your spec, and it makes the whole build reviewable by someone else.

Stage 1: source the list

Three honest ways to get rows in, in order of quality:

  1. A defined segment you can describe in one sentence. Built from a search inside Clay, an export from a directory, a map-based list, or an association membership page.
  2. Lookalikes of closed-won customers. Take the accounts that actually paid, find the two or three attributes they share that are visible from outside, and search for those. This is Follow the money applied to list building: start at the payment, not at the tool.
  3. Inbound or event data you already own, pushed into a webhook table.

What is not a list: "everyone in the industry." A list you cannot describe in a sentence cannot be scored, and a list that cannot be scored cannot be gated.

Stage 2: enrich the company, cheapest source first

Company enrichment answers should this account ever buy from us. Keep it to the fields that feed a score, a routing rule or a sentence in the message. Everything else is decoration.

Two cost mechanics are worth knowing before you run anything. Clay meters Actions for the orchestration work — enrichments, AI, sending data out — and Data Credits for data bought from providers in its marketplace; connecting your own provider API key removes the Data Credit cost but still consumes an Action (Actions & Data Credits). So "bring your own key" reduces the bill, it doesn't make a sloppy table free.

The second mechanic is the waterfall. Clay's Work Email waterfall runs providers in sequence, stops when it finds an acceptable result, and charges credits only for the provider that matched (Clay Docs). The same logic applies to the company layer: cheap and broad first, expensive and specific last. There's a deeper treatment in Clay waterfall enrichment.

Stage 3: the Spend Gate — score before you buy contacts

This is the stage most people skip, and it's the one that decides the economics.

The MitHub Spend Gate rule: no row may consume a person-level credit until it has passed a company-level score.

In practice that means a condition column — "Fit >= 2" — sits between your company table and your people search, and nothing downstream runs on a row that fails. In Clay you express this with a conditional run setting on each expensive column; conceptually it's a valve, not a filter.

A workable three-part score, kept explainable:

PartQuestion it answersTypical inputs
FitCould this company ever buy?Size band, industry, geography, number of locations
TimingIs there a reason to talk this month?Hiring for a relevant role, new location, leadership change, funding
ReachabilityCan we reach a named decision-maker properly?Verified email, direct phone, a real name and title

Score each part separately and route on the combination rather than a single blended number — the detail lives in Lead scoring in Clay, and the signal side in Clay signals and intent data. For the build, all you need is the gate: high fit continues, low fit stops here.

Worked example (hypothetical, for illustration): a 4,000-row company list, with a fit gate at Stage 3, sends roughly 900 rows to people search instead of 4,000. Four out of five person-level lookups never happen. The numbers here are invented to show the shape of the saving, not a measured result.

Stage 4: contacts, then verification — they are different jobs

Finding an address and confirming it will be delivered are two separate columns, and the second one is what protects your domain.

Clay reports verification statuses including valid (active addresses that can receive mail), invalid (addresses that do not exist), catch-all (domains that accept everything, including addresses that may not exist), unknown (could not be verified, often a temporary mail-server issue) and role-based (info@, sales@, support@ — tied to a function, not a person) (Clay Docs).

Turn that into a written policy, because "it looked fine" is not a policy:

StatusWhat we do with it
ValidMain sending list
InvalidRemoved from the table, not just hidden
Catch-allSeparate low-volume list, or a different channel (phone, LinkedIn)
UnknownRe-check later; never in the first send
Role-basedOnly when the role is the buyer, and never for personalized copy

Clay's Work Email waterfall also exposes validation strategies described as Conservative, Balanced and Aggressive, which trade coverage against confidence (Clay Docs). Choose consciously. On a first campaign, choose the conservative end: a small clean list teaches you more than a large dirty one, because bounces contaminate the measurement and the domain at the same time.

Stage 5: personalization you could defend in a meeting

The test for any personalized line: can you point at the source?

Build personalization from two or three research columns that each return a fact plus the URL where it was found, then let a writing column assemble the sentence. If the research column returns "unknown," the row gets the generic version — never a guess. An AI research output is a hypothesis until a human checks it, which is the same discipline Prove value fast applies to everything else.

Two rules that have saved more campaigns than any subject line:

  • Never state an inference as fact to a prospect. "I saw you're hiring two ops managers" is fine if the posting is public. "I saw follow-up is slipping" is a guess dressed as insight.
  • Spot-check 20 rows by hand before the first send. Read the actual rendered message, not the column. You'll find the broken possessives, the companies whose legal name reads like a typo, and the row where the research column quietly hallucinated.

Stage 6: the send-readiness checklist

Your table can be flawless and the campaign can still fail in the mail server. These requirements come from the receiving side, and they are published:

Google requires all senders to set up SPF or DKIM, maintain valid forward and reverse DNS records for sending IPs, transmit over TLS, format messages per RFC 5322, and keep spam rates reported in Postmaster Tools below 0.3% — with 0.10% recommended. Senders above 5,000 messages per day to Gmail accounts must additionally use SPF and DKIM, publish DMARC for the sending domain, keep authentication aligned, support one-click unsubscribe and include a visible unsubscribe link (Email sender guidelines).

Yahoo publishes parallel requirements: SPF or DKIM at minimum for all senders, both plus a valid DMARC policy of at least p=none for bulk senders, spam rates below 0.3%, valid forward and reverse DNS, one-click unsubscribe via the List-Unsubscribe header with a visible link — and unsubscribes honored within two days (Yahoo Sender Best Practices).

On top of the platform rules, Clay's own sequencer guidance gives sane operating numbers for cold campaigns: roughly three weeks of warmup on a new inbox before volume, about 20 emails per inbox per day as a starting point, around three inboxes per domain, up to five, sending from brand-adjacent secondary domains rather than your primary one, and keeping bounce rate under 1% (5% is flagged as needing attention) (Sequencer deliverability).

Run this list before every new campaign:

  • Sending domain is secondary, not the company's primary domain.
  • SPF, DKIM and DMARC published and aligned.
  • Forward and reverse DNS valid for the sending IPs.
  • One-click unsubscribe plus a visible link in the body.
  • An unsubscribe actually removes the person from the source table, within two days.
  • Inboxes warmed, daily volume set conservatively.
  • List is verified-valid only, with a bounce target under 1%.
  • Legal basis for contacting these people in their country has been checked.

Stage 7: the handoff, and the four numbers

The last column in the table sends the approved rows somewhere: a sequencer, a CRM, or a workflow tool that routes them. Write back the identifier you get in return, so the row knows where it went.

Then measure four things, segmented by the score tier from Stage 3:

  1. Bounce rate — a data-quality number, not a copy number.
  2. Reply rate by tier — if tier A doesn't beat tier C, your score is decorative.
  3. Qualified conversations per 100 sends — the only volume metric that maps to revenue.
  4. Cost per qualified conversation — Actions plus Data Credits plus sending cost, divided by outcome.

If tier A and tier C perform the same, don't buy more data. Fix the score. That feedback loop is the whole point of building outbound as a system rather than a campaign, and it's the same loop described in Outbound system architecture.

How this usually breaks

  • Enriching people before scoring companies. Expensive, and it teaches you nothing.
  • No written status policy, so catch-all addresses silently enter the main send.
  • One domain doing both cold outbound and customer email. One bad week costs you both.
  • Personalization with no source URL, which is fine until the one row that was wrong replies angrily.
  • No destination. The table runs monthly and nobody acts on it.
  • Measuring opens instead of conversations. Opens are the easiest number to move and the least connected to money.

Build the first version with five companies, one gate and one message. Send it manually. Then widen it. The Faculty of Revenue Reverse Engineering teaches the same sequence for every GTM system: prove the small version works before you let it run at volume.

Frequently asked questions

In what order should I build an outbound table in Clay?

Define the row, enrich company data, score fit, then find and verify contacts only for rows that passed. Personalize last, from verified facts. Scoring before contact data is what keeps the cost down, because people-level enrichment is usually the expensive part.

Should I email catch-all or unknown addresses?

Clay marks catch-all domains as accepting all addresses, including ones that may not exist, and unknown as not verifiable at the time of the check. Treat both as a separate, smaller list or a different channel, and keep your main sending list to verified addresses.

What deliverability rules must I meet before sending?

Google requires SPF or DKIM, valid forward and reverse DNS, TLS and spam rates below 0.3% for all senders, plus DMARC and one-click unsubscribe for bulk senders above 5,000 messages a day to Gmail. Yahoo publishes matching requirements and asks senders to honor unsubscribes within two days.

How much should I send per inbox?

Clay's own sequencer guidance suggests about 20 emails per inbox per day as a starting point for cold campaigns, with roughly three inboxes per domain, up to five, and about three weeks of warmup before volume.

Sources

  1. Email sender guidelines — Google (Gmail Help) (accessed 2026-09-17)
  2. Sender Best Practices & Requirements — Yahoo Inc. (Postmaster) (accessed 2026-09-17)
  3. Sequencer deliverability — Clay Docs (accessed 2026-09-17)
  4. Email verification statuses — Clay Docs (accessed 2026-09-17)
  5. Work Email waterfall — Clay Docs (accessed 2026-09-17)
  6. Actions & Data Credits — Clay Docs (accessed 2026-09-17)
ClayOutboundEmail DeliverabilityGTM Engineering
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of Clay on MitHub.

Keep going