The 5-stage event pipeline: a worked RSA example

TL;DR: A mechanism walkthrough of source, enrich, sequence, capture, attribute on the Series C cybersecurity program that produced $2.4M in attributed pipeline and 85 qualified meetings.

The handoffs between targeting, outreach, capture and attribution affect what the team can follow up and report.

This walkthrough follows the 5 stages of a Series C cybersecurity program (260 employees) at RSA, Black Hat, and a regional summit. The program produced $2.4M in attributed pipeline and 85 qualified meetings.

The sections below cover the decisions, records and handoffs at each stage.

The 5 stages are source, enrich, sequence, capture, attribute. I will walk them in order.

Stage 1. Source

Start date: 6 weeks before RSA, 4 weeks before Black Hat.

RSA’s public attendee count for 2025 was roughly 43,000. Black Hat was roughly 20,000.

Neither organizer shares a full attendee list with sponsors. The list exists, but it arrives as a post-event delivery, 3 days before the conference opens, partial, and unenriched. That is too late for enterprise outbound.

Source is the stage where we build the list ourselves, ahead of the organizer. For RSA 2025, the raw inputs were:

• The public exhibitor directory.
• The speaker list.
• The session catalog.
• LinkedIn event-attendee signals (people who marked themselves as attending).
• Sponsor rosters.

For Black Hat, we added the briefings speaker list, the arsenal track, and DEF CON adjacency (people attending both).

The customer also uploaded a CSV of hand-curated named accounts they wanted coverage for. This is the only non-public input. Everything else is publicly available in fragments that Luminik stitches together.

Output of stage 1: deduplicated target records with source tags. The case study uses roughly 43,000 as RSA attendance context; that is not proof of an accessible, fully identified 43,000-person prospect list. Record the actual number of usable contacts separately.

Stage 2. Enrich

The target records are enriched through the customer’s Apollo and ZoomInfo contracts, as described in the linked case study. This is the BYOV stage: Luminik orchestrates the lookup, the customer’s existing vendors do the enrichment. No second data contract.

See BYOV: why we refused to own your enrichment for why this matters pricing-wise.

Enrichment is where the list shrinks to a scored target set. Each record gets hit with the customer’s ICP profile, which for this Series C cybersecurity company was CISOs, SOC leaders, security architects, and VP-level security buyers at companies with 500+ employees in financial services, healthcare, and tech.

The ICP was encoded as a scoring rubric with weights:

• Title match.
• Seniority.
• Company size.
• Industry.
• Target-account flag.

The case study describes a 1-to-5 ICP score and tier assignment. Keep the score and its reasoning with the account record.

The case study reports 1,840 ICP-matched accounts in its RSA pass. It also cites roughly 43,000 attendees. Accounts and attendees are different units, so those figures do not establish a 4.3% contact-match rate.

The number matters. 1,840 is too many for 9 AEs to hand-touch. A Tier 1 group of 600 would be a planning choice to test against AE capacity. The rest become Tier 2 for warm outreach and Tier 3 for post-event nurture. The scoring rubric makes that tiering defensible.

Stage 3. Sequence

4 to 5 weeks before each event.

The case study describes 3 Outreach sequences, one per ICP tier, with a 6-touch Tier 1 sequence starting 5 weeks before the conference.

Event-specific angles are the piece teams skip when prep starts too late. A generic invitation says “we will be at RSA, want to meet?” A more specific invitation explains why the conversation fits the attendee’s work. Measure the reply and meeting rates for your cohort.

The angle depends on the signal source from stage 1. Speakers get a speaker-angle. Exhibitor-list matches get a peer angle. LinkedIn-signal attendees get a conference-specific angle.

An illustrative 4-touch sequence might look like this. It is not the 6-touch sequence described in the case study:

1. Email one.
2. LinkedIn connection.
3. Email 2 with meeting slot.
4. LinkedIn message with specific time offer.

The customer’s existing sequencer does the sending. The ranked and tagged list provides the context.

The case study reports 40 pre-booked meetings within its 85+ meeting program. It does not establish that all 85 were booked before the booth opened. Keep booked, held and qualified meeting counts separate.

Stage 4. Capture

During the event, on the floor.

The mobile app (iOS and Android) is what reps use on the floor. Reps capture from anything:

1. QR scan on badges.
2. On-device badge and business card OCR with per-field confidence scoring (for events where the QR is locked behind the organizer’s app).
3. LinkedIn profile screenshots, and imported photos of badges, cards or notebook pages.
4. Voice notes.
5. Typed name and company for booth conversations that did not start with a scan.

At RSA’s exhibit hall or Black Hat’s Mandalay Bay venue, check capture under booth conditions, including a dropped Wi-Fi connection. If the app cannot save the badge and voice note offline, the rep may have to choose between troubleshooting the phone and starting the next conversation. Confirm which records are saved locally and which still need to sync.

A tool that requires a live connection may interrupt capture when the network drops. An offline queue lets the rep save a record and sync it when connectivity returns. Luminik’s app queues up to 200 captures with 5-retry exponential backoff. For a 3-hour outage, check queue capacity and confirm that every saved record synced after the connection returned.

The capture that matters most is the voice note and meeting log attached to the badge scan. On the floor, the sequence is:

1. The rep scans a badge.
2. The app pulls the pre-event ICP score and deal-stage context.
3. The rep records a 30-second voice note summarizing the conversation.
4. The rep tags the meeting outcome (hot, warm, nurture, non-buyer, competitor), and moves on.

The voice note transcribes to text on sync. All of that lands on the contact record in Salesforce.

For the RSA capture stage, the case study records 347 badge scans and 89 voice notes over 3 days. Its 1,500+ scan figure describes the earlier program’s volume per event, not the same capture cohort.

The pre-scored captures are worth more than the cold scans. More on that in pre-booked vs booth-scanned: how event pipeline compounds.

Stage 5. Attribute

Within 48 hours from event end.

Attribution is 3-tier matching.

Each match writes a field on the Salesforce Opportunity or HubSpot Deal record: event-sourced, event-influenced, confidence badge (HIGH, MEDIUM, LOW), first touch date, last event touch date.

The 2-field split (sourced versus influenced) is non-negotiable. Collapsing them into one “campaign revenue” number destroys the signal. See your event attribution model inherited inbound logic for the full argument.

The linked case study reports 22 opportunities and $2.4M in attributed pipeline. Its summary scopes the result to RSA, Black Hat and regional events. Keep the $2.4M as a program-level result, and report the snapshot date and sourced/influenced definitions with any new event-level analysis.

The speed of the writeback matters. 48 hours is the window in which the VP of Marketing has a QBR or a board update, and needs a number.

If attribution lands in week 4, the number is useless for that meeting. It lands in the next QBR, which means the budget defense is a full quarter late, which means the event line gets cut before the number is visible.

What the worked example makes visible

Each stage has a distinct output and a distinct failure mode.

The reason the 5-stage shape produces compounding pipeline is that each stage’s output is the next stage’s input, and the data model is shared across all five.

• You cannot sequence a list you did not score.
• You cannot score a list you did not build.
• You cannot attribute a meeting you did not capture.
• You cannot capture a target you did not sequence.

Stage 5 closes back into stage 1 because the writeback lands in the CRM, where the next event’s sequencing starts with a contact record that already has event history.

Teams that run these 5 stages on separate vendors, with separate data models, lose the compounding. An intelligence-tool-plus-scan-app-plus-manual-attribution stack gives you 3 islands and 3 CSVs.

The $2.4M cybersecurity program was not the result of 3 point tools stitched together. It was the result of one shared data model across 5 stages, with the customer’s CRM and enrichment contracts at the edges and Luminik in the middle.

If you want to see the same pattern applied to a fintech program instead of cybersecurity, the IDV $2M across 15 events case study walks through a similar 5-stage run with different event shapes.