## TL;DR

Opt-out detection must run before everything else in the reply pipeline and it must default to suppression on uncertainty. Add an explicit opt-out intent check as the first classifier stage, wire hits straight to the suppression list, and retro-audit the last 30 days of replies for phrases your old classifier missed.

```
agent followed up with 'just bumping this' to a lead who replied 'please remove me' - reply detection missed the opt-out intent
```

## Steps

1. Pull the actual offending reply and the classifier's output for it. Confirm the miss: the reply said "please remove me" and the classifier labeled it a generic reply or objection.
   Expected: a concrete example of the gap, not a theory.

2. Add an opt-out intent detector as the FIRST stage of reply classification, before sentiment or objection handling. Seed it with explicit phrases: remove me, unsubscribe, stop emailing, do not contact, take me off, opt out, and common misspellings.
   Expected: known opt-out phrasings classify correctly on the first pass.

3. Route opt-out hits to suppression immediately: add the address to the suppression list, cancel all scheduled follow-ups for that lead, and log the suppression event with the reply id.
   Expected: no further sends to that lead from any sequence.

4. For ambiguous replies ("not interested right now" vs "remove me forever"), default to suppression and flag for human review. A false suppression costs one lead; a false follow-up costs legal exposure.
   Expected: the classifier errs toward the safe side by design.

5. Retro-audit: run the new detector over the last 30 days of stored replies. Any hit that was not suppressed at the time gets suppressed now, and the leads get an apology-free quiet close (no new email, just stop).
   Expected: past misses are cleaned up, not just future ones.

## Use this when

- A follow-up went out after an opt-out request
- Reply classification handles objections but has no dedicated opt-out stage
- You need to audit whether past replies contained missed opt-outs

## Not for this skill when

- The reply was an out-of-office auto-response (different detector)
- The reply was a bounce notification (different detector)
- The lead is opting out on one channel but reachable on another (channel-level suppression rules)
- The problem is the unsubscribe link itself being broken (fix the link target)

## Variant phrasings

- "reply detection missed 'please remove me', agent sent a follow-up"
- "opt-out intent not detected, lead got bumped after unsubscribing"
- "agent classified an unsubscribe request as an objection"

## Why it happens

Reply classifiers are usually trained or prompted for sales outcomes: positive, objection, question, referral. Opt-out is a compliance category, not a sales category, so it was never a first-class label. The reply fell through to a generic "engaged" bucket and the follow-up logic did exactly what it was told with the wrong label.

## Edge cases

- Opt-outs phrased as questions ("can you take me off your list?") or wrapped in politeness ("thanks, but please remove me") still count. Pattern-match intent, not exact strings.
- A lead may opt out in a forwarded thread or CC someone new. Suppress every address that appears in an opt-out reply, not just the sender.
- Legal timelines vary by jurisdiction, but the safe engineering default is immediate suppression, not a grace period.
- If the same lead re-engages later through an inbound form, that is a new consent event. Log it explicitly rather than silently un-suppressing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lhr_yRwR4vKqqln3eCy84w