PILLAR 1 · WORKING WITH SDRS

Systems the SDR team ran on

I sat next to the SDR team (virtually) and built the plumbing that fed them leads and saved them clicks. The theme across all of it: leads show up in the right rep's queue automatically, the rep acts from Slack, and nobody has to build or maintain campaign infrastructure themselves.

LemlistHubSpotCommon RoomSlackSumble / Crustdata
[ The Routing Layer ]

Lemlist as a shared engagement platform

What it is: two separate systems, not one. A nightly sync pushes current HubSpot ownership into Lemlist's own owner field, because reps and managers reassign accounts in HubSpot throughout the day and Lemlist has no way to see that on its own. That's what lets Lemlist's native "send as contact owner" setting fire from the right rep inside each standing campaign (one per rep, per play, created and updated centrally by script). Separately, a scoring pipeline handles brand-new accounts: a signal (a job posting, a job change for a former prospect) surfaces a company that isn't in HubSpot yet, it gets scored in Clay, and if it tiers as workable with no owner, it's round-robined to an SDR or AE in that segment and written back to HubSpot. Plays that don't need ownership at all — broad LinkedIn outreach, mainly — skip both systems: SDRs use the Lemlist browser extension to drop leads into a shared campaign nobody has to own.

What it did for people: SDRs never built campaigns, copied templates, or worried about who "owned" a shared play. Copy changes shipped to every rep at once. A new hire joined the program by being added to the routing pool. It made a lightweight tool behave like an expensive sales engagement platform.

flowchart TD
  subgraph SYNC["Nightly ownership sync"]
    direction LR
    S1[HubSpot ownership:
reassigned all day by reps + managers] --> S2[Synced to Lemlist's
owner field, nightly] end S2 --> OWNER[Lemlist: send as
contact owner] OWNER --> STAND[Standing campaign,
one per rep per play] subgraph NEWACCT["New-account round-robin"] direction LR N1[Signal: job posting or
job change] --> N2{In HubSpot yet?} N2 -->|No| N3[Scored in Clay] N3 --> N4{Tiers workable,
no owner?} N4 -->|Yes| N5[Round-robin to an
SDR/AE in that segment] N5 --> N6[Written to HubSpot] end N6 --> SLACK[Slack card tags the rep
+ one-click remove button] N6 -.->|next nightly sync| S1 EXT[SDR uses the
Lemlist extension] --> GEN[Shared campaign,
no ownership check] style SYNC stroke:#8b5cf6 style NEWACCT stroke:#10b981 style GEN stroke:#f59e0b,stroke-width:2px
[ Job Changes ]

Job-change auto-enroll

What it is: when a past champion or good-fit contact starts a new job (detected via Common Room), this pipeline verifies their new work email, checks that the company isn't too small, already a customer, or already in a deal, resolves the owning SDR, and starts outreach automatically. The rep gets a Slack card with a one-click opt-out.

What it did for people: job changes are the warmest cold outreach there is, and speed decides who gets the meeting. Reps went from manually spotting job changes (or missing them entirely) to having eligible contacts already in sequence minutes after the signal, with the safety valve of removing anyone with one click.

flowchart TD
  CR[Contact changed jobs] --> TITLE{Right kind of role?}
  TITLE -->|No| D1[Drop]
  TITLE -->|Yes| EN[Find + verify new work email]
  EN --> GATES{Do-not-contact checks}
  GATES -->|Fails| D2[Drop silently]
  GATES -->|Passes| OWN{Rep assigned?}
  OWN -->|Yes| ROLL[Start outreach]
  OWN -->|No| SCORE{Account scored
in HubSpot?} SCORE -->|Not yet: send to
Clay for scoring| CLAY[Clay table scores
the account] CLAY --> INSERT[Score comes back →
auto-inserted into HubSpot] INSERT --> CRON[Recheck every 2 minutes] CRON --> OWN SCORE -->|Scored, but didn't
meet tiering criteria| D3[Drop silently] ROLL --> SLACK[Slack card + one-click opt-out]
[ Job Postings ]

Job posting bot

What it is: a monitor that watches our target companies for job openings in the roles our product helps with. When one appears, it figures out who's likely behind the hire, posts the job and the people to Slack, and drafts outreach with AI. Nothing sends until a rep reviews and approves it, and the CRM gets re-checked at the moment of approval in case a deal opened in the meantime.

What it did for people: a company hiring for the exact pain you solve is announcing budget and timing in public. Reps can't watch job boards for thousands of accounts; the bot does, and hands them a reviewed, editable draft instead of a research task. Every address is verified before it can be enrolled, so nobody burns a send on a dead inbox.

One detail I'm proud of: the vendor choice was tested, not guessed. Live testing showed the first data vendor missed most postings when searching broadly, but was genuinely good at identifying hiring committees once a posting was known, so the architecture uses each vendor for what it's actually good at, behind an adapter so either can be swapped.

flowchart TD
  CRON[Runs every weekday] --> HS[Load target companies
from HubSpot] HS --> POLL[Check for relevant
job postings] POLL --> DEDUP[(Skip anything
already seen)] DEDUP --> COMM[Identify who's likely
behind the hire] COMM --> SLACK[Slack card: the job,
the people, the links] SLACK --> GATE{Rep reviews
+ approves?} GATE -->|No| DONE[Nothing sends] GATE -->|Yes| CHECK[Re-check the CRM,
verify the email] CHECK --> AI[Rep edits the
AI-drafted email] AI --> ENROLL[Enroll in that rep's
campaign]
[ Replies ]

Pelican: reply handling from Slack

What it is: when a prospect replies to a cold email, Pelican filters out the auto-replies, detects interest, and posts an alert to Slack with a Reply button. The rep writes their response in a Slack form and Pelican sends it through the email platform. It confirms instantly, finishes the send in the background, and never double-sends even when Slack retries a click. A daily sweep catches anything the instant alerts missed.

What it did for people: interested replies stopped falling through the cracks. Reps answered from the tool they already live in instead of digging through a sending platform they rarely open, and response time on the most valuable moment in cold email (someone saying "tell me more") dropped to one click.

sequenceDiagram
  participant ESP as Email platform
  participant PEL as Pelican
  participant SL as Slack
  participant HUM as Rep
  ESP->>PEL: Prospect replied
  PEL->>PEL: Filter out auto-replies, detect interest
  PEL->>SL: Alert with Reply button
  HUM->>SL: Click Reply
  SL->>PEL: Reply text submitted
  PEL-->>SL: Instant confirmation
  Note over PEL: Send finishes in background
  PEL->>ESP: Email goes out
  PEL->>SL: Sent receipt posted
    
[ Warm Intros ]

Network Mine

What it is: teammates upload their LinkedIn connection exports; the system mirrors open deals and accounts from HubSpot and matches the two, surfacing who on the team can make a warm introduction into any open deal. A leaderboard shows each person's coverage of our target accounts.

What it did for people: warm paths into pipeline that were sitting in people's LinkedIn accounts became visible and searchable. When a new deal was created, Slack showed whether anyone on the team already knew someone there.

This is the first-degree version of the idea, and it's as far as it got. The full writeup covers why first-degree matching has a ceiling, and the multi-hop Slack + AI + Lemlist workflow I never finished building on top of it.

Want systems like these at your org?

Contact Me 727-637-2778