Stop sending when they reply — including when someone else replies

"Stops the sequence when they reply" is on every outreach tool's feature list. It is table stakes. The reason it still goes wrong is that "they" is doing a lot of work in that sentence. The person who answers is often not the person you wrote to, the answer is often not from a human, and sometimes the answer is not an email at all. Here are the cases, and what a system should do with each.

Case 1: A colleague replies from a different address

You write to Dana. Dana forwards it to Raj, who runs the thing you are pitching. Raj replies — from raj@, an address you never sent to. A tool that detects replies by matching the sender against the contact you targeted sees nothing. Two days later, step three goes to Dana: "wanted to make sure this didn't get buried." Raj already said yes. Dana now thinks you cannot keep track of your own conversations.

The fix is in the headers. If every message you sent carried a full References chain and you stored each outbound Message-ID, Raj's reply — which his mail client threaded onto Dana's forward — carries your Message-IDs in its References. Match on that, not on the sender. The sequence stops, the thread lights up in the inbox with Raj as the new correspondent, and the company is marked engaged. A second, cruder net is matching on the sender's domain: any human reply from @theircompany.com is treated as engagement for that company.

Case 2: Out of office

An auto-reply is not engagement, and treating it as one permanently burns a live prospect: the tool marks them "replied," a human sees the thread, realises it is an OOO, and by then the sequence is dead. The opposite mistake — ignoring it — sends step three into an empty inbox, where it sits under a pile of returned-from-vacation mail.

Classify it: auto-submitted headers, the usual subject patterns, the usual phrases. Then parse the return date if there is one. Reschedule the next step to the return date plus one business day. No notification, nothing for a human to do; the pipeline shows deferred · Sep 22 and the sequence resumes on its own.

Case 3: "Talk to Raj instead"

A referral is the best thing that can happen to a cold email and most tools handle it as a generic reply. It should stop the sequence to the original contact, extract the referred address if one is given, and create the new contact — pending your approval, not auto-sequenced, because the right first message to Raj is a short note that mentions Dana, not step one of the template. The thread should show up in the inbox as referred with Raj's address ready to click.

Case 4: They signed up without replying

If you sell software, this is the case that matters most and the one no rented sequencer can see. Step two lands on Thursday. The prospect thinks "fine, let me just try it," installs your app that afternoon, and starts onboarding. They never reply to the email — why would they? They are already in. Saturday morning, step three arrives: "I'll close the file unless you want this." They are a paying customer. Your first impression as a company is that you do not know who your customers are.

The fix is an install signal. Your app posts a signed event — shop or account identifier, product, timestamp — to the outreach system the moment someone installs or signs up. The system matches it to the company, ends the cold track, tags the contact installed, and hands them to your welcome flow on your real domain. A mid-sequence install with no reply is not a missed conversation. It is the system working.

The same channel carries uninstalls, which should surface for a manual note and never trigger an automatic re-sequence.

Case 5: Bounces and "no"

A bounce stops the sequence, flags the address, and counts toward the sending domain's bounce rate — the number that will throttle the domain if it climbs. An opt-out ("no", "unsubscribe", "remove me", "not interested") suppresses the address globally: every sending domain, every product, permanently. Not "for this campaign." A person who said no to product A and hears from product B a month later is a person who files a complaint.

Case 6: The same company in two lists

You sell two products. The same company is a prospect for both, sitting in two campaigns. They reply to the first — and the second keeps going, from a different sending domain, possibly from a different person on your team. From their side: two strangers from the same shop, one of whom does not know the other got an answer.

Engagement has to be company-level. A reply to any track pauses every other track at that company. And, better, tracks should never overlap in the first place: one company, one active conversation, the next product queued behind it with a cooldown.

What this implies about where the logic lives

Every case above depends on something a sequencer bolted onto a mailbox does not have: the outbound Message-IDs, a company-level model across products, a signal from your own product, and a classifier that knows an OOO from a yes. That is why "stop on reply" is easy to claim and hard to do properly. It has to be built into the layer that sends, because that is the only layer that knows what was sent.