Skip to content
~/robynrocha.io
cd /home
Case studyOutbound / Post-send / SDR/AE

SDR systems, and everything after the reply

The systems the seat runs on — ownership routing, job-change and job-posting signals, visitor outbound, warm intro paths — and the full post-send chain that takes over once a prospect answers. I build this layer, and I work the seat it exists for.

Cold email gets all the attention, but the send is the cheap half. Everything expensive happens after someone answers, and that is where most programs quietly leak. This pillar has two halves: the systems the seat runs on day to day, and the post-send chain that takes over the moment a prospect replies.

[ Ownership Routing ] A shared engagement platform, without the platform price

What it is: two separate systems, not one. A nightly sync pushes current HubSpot ownership into Lemlist's own owner field — reps and managers reassign accounts throughout the day, and Lemlist has no way to see that on its own. That's what lets "send as contact owner" 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 surfaces a company that isn't in the CRM yet, it gets scored in Clay, and if it tiers as workable with no owner, it's round-robined to a rep and written back to HubSpot with a Slack card and a one-click remove button.

Why it's built this way: reps should never build campaigns, copy templates, or worry about who "owns" a shared play. Copy changes ship to every rep at once, and a new hire joins the program by being added to the routing pool. It makes a lightweight tool behave like an expensive sales engagement platform.

$render lemlist-routing.mmd

No diagram code provided

rendering diagram…

[ The Warmest Signal ] Job-change auto-enroll

What it is: when a past champion or good-fit contact starts a new job — detected via Common Room — the 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 rep, and starts outreach automatically. The rep gets a Slack card with a one-click opt-out.

Why it's built this way: job changes are the warmest cold outreach there is, and speed decides who gets the meeting. Reps go 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.

$render job-change.mmd

No diagram code provided

rendering diagram…

[ Website Visitors ] Visitor outbound that knows which page they landed on

What it is: when RB2B identifies a company on the site, the workflow branches on which page they landed on — pricing, a product page, a blog post, a lead magnet — and enrolls them into the sequence written for that page. Map page to copy once; after that it runs forever. Heavy repeat traffic gets its own branch: the senior-most marketing leaders at that account, enriched with phone numbers, dropped into a stakeholder sequence.

Why it's built this way: site visits stop being a vague intent badge in the CRM and become evergreen, page-aware outbound. Reps inherit ready enrollments instead of research tickets, and marketing can ship a new page and plug it into the map without rebuilding the workflow.

$render rb2b-visitors.mmd

No diagram code provided

rendering diagram…

[ Hiring Signals ] The job posting bot

What it is: a company hiring for a specific role is publicly announcing a budget, a pain, and a timeline. The bot watches the accounts that already matter, detects relevant roles, infers who owns the hire, and posts a Slack card — the job, the people, the links. A rep reviews, the CRM gets re-checked at the moment of approval, the email gets verified, and the rep edits the AI-drafted outreach before anything enrolls.

Why it's built this way: the gates are layered so nothing sends by accident. Sending is off by default, viewing can't trigger anything, no unverified address ever enrolls, and the AI drafts while the human decides — detection is automated, judgment stays human, execution stays gated.

$render job-posting-bot.mmd

No diagram code provided

rendering diagram…

[ Warm Intros ] Network mine

What it is: execs and reps export their LinkedIn connections and upload them. The system mirrors open deals and target accounts from the CRM and matches the two lists, surfacing who on the team already has a connection at any account that matters — with a leaderboard of each person's coverage, and a Slack nudge when a new deal is created at an account someone already knows.

Why it's built this way: first-degree connections aren't the real graph. The interesting question is multi-hop — does the chain of connections eventually reach the account we're trying to open? LinkedIn only hands over first-degree lists, so the full version pools everyone's complete exports into one database, where the multi-hop graph finally exists outside individual heads.

[ Reply Handling ] 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 — instant confirmation, the send finishes in the background, and it never double-sends even when Slack retries a click. A daily sweep catches anything the instant alerts missed.

Why it's built this way: interested replies stop falling through the cracks. Reps answer 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" — drops to one click.

$render pelican.mmd

No diagram code provided

rendering diagram…

Pelican is the front door. When the reply lands, the second half of this pillar — the full post-send chain — takes over behind it.

[ The Front Door ] Every reply arrives with its context already assembled

What it is: the moment a prospect replies, a conversation object opens and stays open until the thread resolves. Alongside it, a context pack is assembled exactly once: the campaign slice's strategy (with the offer already baked into the play), the account's own evidence — the crawled business summary, its classification, its grade, its corporate structure — the thread itself, and a thin card of current offer facts.

Why it's built this way: assembling context once, at conversation open, is what makes every downstream seat cheap and consistent. Classification, drafting, follow-up, and the call all read the same pack, so they cannot disagree about who this person is. The alternative — each step re-querying and re-deriving — is how two touches end up contradicting each other in front of a buyer.

$render reply-capture.mmd

No diagram code provided

rendering diagram…

[ The Verdict ] A seat proposes the read. A human decides it.

What it is: every reply gets typed on a four-way severity gradient — hostile, a soft no, a referral, or genuinely ambiguous — plus intent and a resolution. Hostile means suppression, permanently. A soft no goes to the dark pool for a later, colder look. A referral gets routed to the named person. Ambiguous goes to a human, every time.

Why it's built this way: it is one pipeline with approval gates, not an automated era that arrives later. The seat drafts its read from day one and a human approves or overrides at the gate. Gates relax per class only when the evidence says the seat and the human already agree, and the irreversible class — suppression — relaxes last, if ever. Every gated verdict is also the training corpus, so the act of supervising the system is what improves it.

$render reply-classification.mmd

No diagram code provided

rendering diagram…

[ Speed to Lead ] Answer fast, and let a person okay it before it sends

What it is: an interested reply starts a clock. The seat drafts a response conditioned on the class it was given, a ping surfaces it, and a human clears the send. Threading is explicit — a real reply on the real thread, not a fresh email pretending to be one — and the returned message id becomes the handle for the next turn.

Why it's built this way: speed is the single biggest lever on a warm reply, and it is also where unsupervised automation does the most damage. Putting the verdict gate and the send gate on the same surface means one glance approves both, so the human check costs seconds rather than minutes. Nothing is sent to an address that has not been verified, and nothing is sent at all until suppression has been consulted.

Links and attachments stay out of first contact and appear only after the prospect has engaged — a rule inherited from the send side, where a first-touch link is one of the cheapest ways to get filtered.

[ Cadence ] Follow-up that stops the instant it should

What it is: a lead who answered but has not booked enters a cadence — chosen from a menu rather than a single hard-coded rule. A tight 7-3-1, a slow indefinite drip, or a two-bump-and-park, picked per lane. Each touch is a deposit, not a nag: it adds something, or it does not go.

Why it's built this way: the halt outranks the schedule. Any inbound message, any booking, any verdict stops the cadence immediately and re-entry starts at the beginning rather than resuming mid-sequence. A lead who goes quiet is parked with a note explaining why, and becomes a candidate for revival later instead of being burned by a sequence that never noticed they stopped caring.

The phone is part of this, with one hard rule: never a cold dial. A call only happens after the person has already replied, which keeps it a warm follow-up on a live conversation rather than a separate channel with its own compliance surface.

$render cadence.mmd

No diagram code provided

rendering diagram…

[ The Conversion Point ] Booked on their behalf, not handed a link

What it is: when a conversation turns into intent, the reply carries actual times. If they named a window, it gets checked. If that window is gone, a nearby alternative is offered. Otherwise, three near options. Booking happens on their behalf; a scheduling link is a fallback, not the opening move.

Why it's built this way: a link asks the buyer to do the work at the exact moment their intent is highest and most perishable. The booked moment is also atomic: the stamp lands, and in the same act the kill-switch halts every competing cadence, so nobody gets a follow-up nudge twenty minutes after agreeing to a meeting.

Booking is not the finish line — held is. A confirmation goes out immediately, then a short countdown of reminders that each carry something rather than just repeating the time. Reschedules are treated as replies and re-anchor the whole sequence. A no-show either restarts the booking motion or falls back to the revival pool.

$render booking.mmd

No diagram code provided

rendering diagram…

[ The Hard Line ] One list that outranks every other rule

What it is: a single do-not-contact store fed by every lane that can produce one — a hostile verdict, a keyword opt-out, a request made over the phone, the platform's own unsubscribe list reconciled back in, dead addresses, and whatever the business excludes for its own reasons. It is read just-in-time at send, not copied into a campaign and left to rot.

Why it's built this way: a suppression list that is merely usually current is not a suppression list. Reading it at send time is the difference between a rule and a hope. When someone opts out it fans out across every channel, not just the one they used, and both their addresses are covered. Permanence is not a setting.

$render suppression.mmd

No diagram code provided

rendering diagram…

[ The Seat Itself ] I can run this seat, not only build it

Everything above is machinery for a job I have done by hand. I work the SDR and AE motion directly — prospecting, sequencing, answering replies, handling objections, booking, and carrying a conversation to a held meeting — which is the reason the system has gates where it does.

The design decisions on this page came out of that: the halt outranks the schedule because a rep knows what it costs to nudge someone who already said yes. Suppression is permanent because a rep has watched a list get burned. Booking beats sending a link because a rep has felt intent evaporate in the seconds it takes someone to open a calendar.

That is the pitch, plainly: I am useful in the seat on week one, and by week twelve the seat runs on something better than memory and good intentions.


The rest of the system: Cold Email at Scale · Data & AI Infrastructure