Every outbound tool prints the same sentence: “sequences stop automatically when someone replies.” Almost none of them qualify it. The qualification is the whole engineering problem, because stopping on reply is not one feature. It is an identity match, a timing guarantee and a race condition, and a tool can pass two of the three while still sending step three to someone who answered step two an hour ago. That email is the one that ends the conversation.
Reply detection is an identity problem before it is a timing problem
A reply arrives as an inbound message. Before anything can be stopped, the system has to answer two questions: which person is this, and which of our outbound conversations is it answering?
There are two ways to answer, and they fail differently.
Threading headers. The In-Reply-To and References headers carry the Message-ID of the message being answered. When present, they are exact: this reply belongs to that send. They are also fragile. Mailing list software, some corporate gateways and a prospect who forwards your email to a colleague rather than replying will all break the chain.
Address equality. Match the sender address against known recipients. This catches the reply sent from a phone, from a different client, or after a header-stripping gateway. It cannot distinguish which of your messages is being answered, and it will match anything arriving from that address, including automatic replies.
Neither method catches the most common miss: the prospect who replies from a different address, or forwards your email to a colleague who answers from theirs. No mechanism available to an outbound tool detects that, and the honest response is to design the rest of the system on the assumption that some replies are invisible to it.
Scoping matters too. A message that cannot be attributed to a specific workspace and outbound conversation must be skipped rather than guessed at, because a guess here does not produce a missed exit, it produces an exit applied to the wrong person’s enrollment.
Out-of-office, and which error you would rather make
Address-based detection treats an out-of-office auto-reply as a reply, because in the literal sense it is one: an inbound email from that address. The prospect is on holiday for two weeks, and the cadence stops.
This is a false positive, and the alternative is worse. To avoid it, a system has to classify inbound mail as automatic or human, using headers such as Auto-Submitted and X-Autoreply plus heuristics over the body, then resume the cadence when it decides the reply was machine-generated. That classifier will be wrong in both directions, and when it reads a short human reply (“please stop emailing me, I’m travelling”) as an auto-responder, the cadence resumes and sends the exact email that destroys the relationship.
Given a choice between stopping a prospect who did not really reply and continuing to email one who did, stopping is the recoverable error. A rep can re-enroll someone who came back from leave. Nobody can un-send step three.
The race between a scheduled send and an inbound reply
This is where implementations quietly differ, and where a buyer should ask a direct question.
| Design | What happens when a reply lands at 09:59:58 and a step is due at 10:00:00 | Exposure |
|---|---|---|
| Exits evaluated on the scheduler tick | The reply is processed at the next tick, possibly after the send | One full tick interval |
| Exit applied at inbound receipt | The enrollment leaves the active set before the dispatcher looks for it | Milliseconds |
| Exit at receipt, plus a re-check inside the send path | The send path refuses even a claimed step | Effectively none |
The question to ask a vendor is not “do sequences stop on reply”, because the answer is always yes. It is “when is the exit applied, and does the send path re-check before dispatch.”
A second structural property removes most of this exposure regardless: whether future sends are materialised. A system that pre-queues the next five steps as scheduled jobs has five things to cancel, and cancellation is a distributed operation that can partially fail. A system where an enrollment carries a single pointer to when its next step is due has nothing to cancel. Stopping is not an action taken against pending work; the next run simply does not pick the enrollment up.
The concrete failure: the third email after the meeting was booked
A prospect replies to step two on a Tuesday afternoon: interested, asks for a call, proposes Thursday. The rep replies from their own inbox within twenty minutes and books the meeting.
Step three sends on Wednesday morning at 08:00.
Trace the mechanism, because each link is ordinary. The reply went to the rep’s personal address, not to the sequence’s sending address, since the rep’s twenty-minute reply had already moved the thread. The sequence’s reply detection never saw an inbound message for that enrollment. The enrollment stayed active. The dispatcher found a step due at 08:00 and sent it: a follow-up asking whether the prospect had seen the previous email, addressed to someone who had answered it, booked a meeting, and put it in their calendar.
The prospect’s reading is not “their automation has an edge case.” It is “the first two emails were also automated, and nobody was ever reading.” One of those conclusions is technically wrong and the other is exactly right, and both damage the same thing.
What would have prevented it is not better reply detection. It is a suppression rule wider than the sequence: a manual reply logged against the contact, or a booked meeting on the deal, treated as an exit signal for every cadence that contact is in. Which is the argument for outbound living in the same system as the CRM rather than beside it.
Suppression belongs to the person, not to the sequence
A prospect enrolled in two sequences who unsubscribes from one has unsubscribed. They did not unsubscribe from a campaign, because they do not know your campaigns exist.
Three rules follow. Unsubscribes and complaints suppress the address at workspace level, across every sequence, permanently. Bounces suppress non-optionally, because continuing to send to a hard-bounced address damages the sending domain for everyone else in the workspace. And suppression must be checked in the moment before each send, not at enrollment, because the state that matters is the state now.
That last point separates a suppression list from a suppression check. A list consulted at enrollment is a snapshot of a week ago.
How Oneop handles this
The sequences page states the mechanism with its boundaries, and the boundaries are the useful part.
A reply means an inbound email arriving through the inbound mail webhook, and that is the only path: there is no separate mailbox poller doing the same job, so replies that do not route through the mail provider handling your inbound are not detected. The person is matched by email address against the contacts and leads in your own workspace, and the workspace itself is resolved from the message originally sent to that address, so a reply that cannot be attributed to a workspace is left alone rather than guessed at.
The exit happens when the reply arrives, not at the next scheduled run. And it matters less than you would expect, because there is no queue of pending sends: an enrollment carries a single pointer to when its next step is due, so stopping it is not a matter of cancelling anything.
One honest boundary, stated on the product page rather than buried: this exits enrollments that are running. A paused enrollment records the reply against the person but is not exited, and resuming resumes the cadence. Read a pause as a hold, not a stop.
Suppression is re-checked in the moment before every send, and a suppressed recipient has the send refused and the enrollment exited however it was scheduled. Bounces exit, and that one is not optional on any sequence. Click and meeting-booked signals are optional and evaluated as the next step comes due rather than instantly, which is the right treatment for a weaker signal.
Underneath, one step sending twice is guarded by three independent layers, including a partial unique index that permits at most one recorded send per enrollment and step. Retries are deterministic: spintax and merge fields are seeded from the enrollment and step, so a retry after a network failure renders the identical email rather than a new variation.
The four questions to ask any outbound vendor
Reply detection is a good proxy for whether an outbound tool was built by people who have been on the receiving end of their own product. Ask which channel it detects, when the exit is applied, which cases it cannot see, and what happens to a paused enrollment. A vendor who answers all four has thought about the failure. A vendor who answers “yes, sequences stop on reply” has thought about the sentence.
The broader judgement about which parts of a sales motion should run unattended is covered in when not to automate, and the suggest-approve-autonomous framing behind AI autonomy levels applies directly: an outbound send is an irreversible external action, and irreversible actions deserve the strictest exit conditions you can implement. Pipeline-side discipline is the companion problem, in CRM pipeline stage gates.
For the surrounding mechanics, the CRM holds the contact a sequence enrolls, automation covers the non-outbound rules, and AI governance covers how the optional personalization step is constrained and metered.