Vantis: Outbound Automation

Problem

Build an outbound automation in Clay that picks the right accounts, finds a real reason to reach out now, chooses the right person, and writes messages and replies an SDR would send. Deliver each one to a test destination once.

What I built

The problem Vantis's two SDRs emailed 2,000 people from a bought list last quarter and booked 4 meetings, about 0.2 per 100 emails. One email went to an existing customer, who complained. Vantis pays for Clay Web Intent and a topic feed nobody uses, and 40 target accounts looked at the pricing page last month with no follow-up. The VP of Sales wants 15 qualified meetings next quarter from the same two SDRs. So the build works the accounts that are already looking, finds the right security leader, writes something an SDR can send without editing, and delivers each account once. It never contacts a customer or anyone who opted out. How I measure it Meetings booked per 100 accounts worked, with reply rate and positive-reply rate next to it, all split by tier and by trigger. Target: 5 meetings per 100, so 15 meetings from about 300 accounts a quarter (about 120 pricing visitors plus accounts with a new leader or funding). 10% of qualified accounts are held back by a hash of the account ID and never contacted, so the lift is measured against accounts that looked just as good. Guardrails: verified emails only, bounces under 2%, spam complaints under 0.1%, 30 to 50 emails per inbox a day. What would disappoint the VP, and the control: a customer emailed again (exclusions before spend and again just before delivery), drafts the SDRs rewrite (only verified facts, then a fact-check), credits spent on accounts that never qualify (every paid step sits behind the free checks), no lift (the held-back group). The ICP, derived from the six known deals Size and industry separate won from lost. All four closed-won accounts are software companies (two vertical software) with 140 to 320 employees. Closed-lost 1 is a 900-person retailer, closed-lost 2 a 35-person software company. Country and title don't separate them: all six are US, all six contacts are Heads of Security. So the ICP is US software (SaaS and vertical software count) with 50 to 500 employees, and 100 to 350 is the core band. Six deals is a thin base, so both limits are settings I recheck after 30 days. Buying committee, in fallback order: the economic buyer (CISO, VP or head of security), then a champion (director or manager of security). A security engineer is held so the SDR can find the leader. Under 100 employees the CTO or VP of Engineering owns security and is accepted. Sales titles never pass. Why these triggers One primary trigger: a pricing-page visit in the last 30 days. Pricing pages convert at 3.8% on average (HockeyStack, 80 B2B SaaS companies), and intent tools work in weeks, so 30 days. Two modifiers, 90 days each, add priority and alone only earn the Tier B template: a new security leader (UserGems: new leaders are 2.5x more open to new tools in their first 3 months) and a funding round (a stated hypothesis: investors ask for compliance proof). Each has a campaign brief with its own angle, ask and what never to say. How it works (one Clay Workflow with a webhook trigger, built

My contribution

I built this as one Clay Workflow, using the Clay CLI What I built - A webhook-triggered Clay Workflow with 53 steps (published as V6): token and kill switch checks, exclusions before spend, an ICP check on every record, dated signals with event dates kept apart, tiers, a held-back group, an account lock, an email waterfall that rejects role inboxes, a fact-checked Tier A AI message, a recheck before delivery, retries with parking and recovery, and a run log with each provider's status and tries. - A test Google Sheet as the destination, test CRM, run log, review queue, lock table, parked tab, outcomes and control row. - The rules in one Python file that every code step uses, a local simulation of the whole workflow, an answer key written before each pass, and a script that compares every live run with it field by field. - 29 extra test cases on top of the brief's 47 records, most added to test a point from my assessments. - A campaign brief per trigger (angle, opening line, proof point, ask, what never to say). Key decisions - A pricing-page visit is the only primary trigger: it is the unworked demand in the brief and Web Intent is already paid for. A new security leader or a funding round adds priority but can't earn the AI message alone. - AI only for Tier A; Tier B gets its trigger's template. - Hold instead of guess: unclear industry, a security engineer instead of a leader, a catch-all or role-inbox-only email, contradictory web data and hidden instructions all go to

Results reported by the participant

Everything below comes from Clay's run records for the graded pass on V6, the final version. Anything marked ESTIMATE is my own calculation, not a real charge. What arrived - 16 rows at the destination, one per account: 6 Tier A with an AI-written email and 10 Tier B with the template, including all 5 eligible accounts. Each row has stable account and contact IDs, role, tier, the trigger's observed and event dates, why it fits, why now, the email, three replies and a source per claim. - What didn't arrive, on purpose: 13 excluded, 24 held for a named reviewer, 6 not worked, 9 duplicates, 3 rejected inputs, 2 paused by the kill switch, 1 held back for measurement, 1 support request routed, 1 parked after three failed deliveries. - Earlier full pass on V5: 16 rows: 6 Tier A with an AI-written email and 10 Tier B with the template, including all 5 eligible accounts. Cost (graded pass, 77 runs) - 7 data credits and 217 actions. Only the AI step uses credits, about 1 per message. Sheet lookups, code and rules are free; each Sheet write is 1 action. - By outcome: Tier A delivered 0.83 credits and 6 actions a run; Tier B delivered 0 credits and 5 actions a run; excluded 0 credits and 1.8 actions a run; held for review 0.04 credits and 3 actions a run; not worked 0 credits and 1 action a run; rejected 0 credits and 1 action a run. - The 13 excluded runs used 0 credits. - Per delivered account, counting everything the pass spent: 0.44 credits and 13.6 actions. - ESTIMATE: 24.2 more credits if the simulated providers were real (Clay Find contacts 0.5, Icypeas 0.2, LeadMagic 0.3 only after an Icypeas miss, ZeroBounce 0.1). - Earlier V5 pass: 7 data credits and 219 actions for 76 runs; the 13 excluded runs used 0 credits. - The whole V5 and V6 retest, including smoke tests and token checks: 25 data credits and 564 actions (certification 1 in total: 58 credits and 1,601 actions, inside my cap of 60 and 1,800) Time - Median from a record arriving to delivery: 55 seconds, inclu

Limitations

This project uses assessment data. Results do not represent a live business.

Application or promotion summary

I built a Outbound Automation project in Clay and completed a build assessment and an interview about my decisions.

Selected evidence