One system: a raw conference roster, turned into rep-owned, fully-sourced outbound

We start from the delegate contact list exported from the event’s in-app attendee list — not a clean account list. So one roster drives two linked workflows: a contact workflow (who is this person) and an account workflow (what company do they represent). Everything below is a real piece of code doing one job, and each step hands its number to the next.

The roster is names only — nothing to match or enrich on yet. Everything after this manufactures the data we need. Tool: made-event-scraper (Firecrawl) + the in-app export.

A name can’t be matched or enriched, so our domain-finding code resolves each of the 677 companies to its real web domain. This is the unlock — nothing downstream can run without it.

Tool: run_event_domain_finds.

With domains in hand we check every company against our accounts database (Made’s canonical account records) by exact domain. Of the 677, 359 already existed in the database; the rest are net-new candidates that get carried into the next steps rather than dropped.

Contacts ride along — each delegate is attached to their company. Tools: promote_event_to_registry (domain match) · match_event_contacts_to_leads.

Next we decide what each company is. This is a fast, cheap name + domain triage — an LLM reads the company name and website (for the matched ones, we already carry a classification in the database) and sorts each into a therapeutic developer (our buyer) or the ecosystem around them. It’s deliberately lightweight: its job is to decide who’s worth pursuing, not to enrich. 230 are developers; the other 447 are ecosystem, held on a separate track — not thrown away.

Name + domain only — no Clay yet. Firmographic enrichment comes next, and only for the accounts we’re keeping. Tool: classify_event_companies_icp (LLM triage).

A name-only pass isn’t enough — so a strict second check reads each company’s own L3 website and removes anything that isn’t a therapy developer (advisors, CDMOs, tools/vendors a name pass let through). That took the set from 230 to 210 true developers; the 20 removed join the ecosystem track.

So of the 230 developers — did we already have them? Mostly, but not all. 173 were already in our accounts database; 57 were genuinely new therapeutic developers we discovered at this event and minted into the database (human-approved, each given a Made-ID). Every attending developer is now in the database, 100% matched. (A later strict re-check then removed 20 non-developers from this matched set — leaving 210 true developers.)

Tools: the orphan-seeder (dedup-guarded mint) + promote_event_to_registry (link-back).

Now that we know who we’re keeping, we enrich them. Every developer account in our database is pushed through Clay to pull full firmographics — size, financing, location, modality signals. This is enrichment for the dossier and the messaging, not the buyer decision (that was step 04). Nearly every one of the 210 developer accounts came back with firmographics; a handful had no record on their domain.

Clay only runs on companies that live in our accounts database — we don’t spend it on the ecosystem we set aside. Tool: Clay “Made Company Enrichment” — the push carries supabase_id so the enrichment writes back.

Now the two workflows converge. Of the 1,150 delegates who attended, we keep the ones who actually sit at one of the 210 developer accounts: 319 contacts. Those are the people who matter — everyone else belongs to the ecosystem companies we set aside.

The 319 came in as names, so FullEnrich finds each one’s work email and reverse-finds their LinkedIn. We do this before enriching them, because Clay’s person enrichment keys on the LinkedIn URL.

Tools: FullEnrich — find-email + reverse-find LinkedIn.

Of the 279 with a LinkedIn, 278 are enriched through Clay to pull their full profile — headline, experience, background — the raw material the persona classifier reads next.

Tool: Clay “Made Contact Enrichment” (push carries supabase_id).

Our persona code runs over each of the 319 (title + Clay profile) and assigns exactly one standardized Made buyer segment — the segment the messaging agent reads to pick an angle. Contacts outside our buyer model are tagged NOT_ICP and suppressed.

Tool: classify_contact_persona.

With emails and identities in hand, we cross-reference every account and contact against Salesforce and HubSpot — broken out fully, so a rep knows exactly what relationship already exists before a single message goes out. This runs after we’ve found emails, because the email is a match key.

None were in a prior outbound campaign — this cohort is net-new to outreach. Tools: tag_event_crm_alignment + enrich_event_crm_from_reporting.

For each of the 210 developers we assemble ONE canonical intelligence record: our L3 scraper reads the company’s own website, and we pull real, sourced signals from live life-science data and our stored news history. (The CRM footprint from step 11 folds into this same record.)

The Account Intelligence pages are the per-account manifestation of this record — re-enrich the backend and the page updates itself. Tool: run_event_l3_scrape + the LS-intel API pullers.

With everything known, we route each of the 210 developers — twofold, in a strict order: (1) the Salesforce owner if that owner is one of our reps — an owner links to one person; else (2) the geographic territory, which links to a group of two reps — EAST = Chat + Simona, WEST = Karen + Simran; else (3) Joe as the international / no-signal catch-all. Owner and territory are tracked separately, so a pair can split or trade within their region.

Of these, 27 carry a Salesforce owner who is a rep (that person wins over territory). Tool: reconcile_event_tiers (territory/owner derivation).

Using everything above — buyer fit, CRM relationship, pipeline, persona coverage — Greg has pre-assigned every one of the 210 developers a tier. This is the one call that gates the whole engine, and it’s where the reps come in: review your accounts and adjust the tier where you know better.

Set the tiers in the Rep Console — changing a tier or owner there writes back immediately and realigns everything downstream. Nothing sends until the tiers are locked and the messages are approved.

Once the tiers are locked, every Tier-3 account receives a coordinated combination of email, LinkedIn, and event-portal messages, managed by Greg and the marketing team. The SSO Matrix agent writes each one: for a single contact it reads who they are, what account they’re at, the account’s modalities and cell-sorting type (from the L3 scrape), and the contact’s Clay profile + persona — then maps to the SSO system to choose one value proposition + one pain point + a call-to-action to meet at the event, and drafts the message for that channel.

See the real drafts on the Messaging page — by rep, by channel. Tool: the MADE SSO agent (select-then-write matrix).

Execution and response are separate jobs. Greg manages the response side in the Made AI Campaign Tasks hub: view every accepted LinkedIn connection and send the follow-up, manage portal messages in the event hub, and triage replies. Email sends run through the EmailBison setup (separate sending domains to protect deliverability), which Greg also manages from the Campaign Tasks page. Every send, reply, and connection is compiled back into the numbers.

Every step above is a named piece of code that hands its number to the next. Swap the roster and the whole chain re-runs — find domains, match, enrich, classify, reach, persona, CRM-map, build the hub, route, tier, write, send — feeding the same commercial engine every time.