Reply detection

There is no other reliable source. Replies arrive in the mailbox that sent the original, so detection means connecting to that mailbox and reading it — which is also why an outbound tool that sends through a shared relay it controls, rather than through your mailbox, has a harder time seeing your replies at all.

Matching is then a question of evidence: the message identifiers a well-behaved client echoes back, falling back to the sender address against recent sends when they are missing.

The inbound stream is mostly not prospects answering. Out-of-office notices, bounce notifications, auto-acknowledgements and removal requests all arrive the same way, and treating them uniformly produces both false optimism in the metrics and genuine mistakes — stopping a sequence because the recipient is on holiday until Monday.

Categorisation is therefore part of detection, not a reporting nicety. At minimum: a real reply, an automatic reply, and a removal request that has to reach the suppression list immediately.

A reply usually contains the entire thread beneath it. Anything reading the raw body — keyword rules, sentiment, a summary — is reading your own message back and drawing conclusions from it. Stripping the quoted portion before doing anything else is what makes the rest of the pipeline trustworthy.

It is a small piece of parsing that is easy to skip and produces a long tail of inexplicable behaviour when it is.

SalesShift polls your connected mailbox for unread mail, matches it back to tracked sends, strips the quoted thread, categorises the reply — including out-of-office and removal requests — and stops the contact's active enrollments when the sequence is set to stop on reply. Removal requests are added to the suppression list automatically.