An unsubscribe request, end to end
An unsubscribe arrives either as a click on the link in an outreach message or as a reply asking to stop. Both end in the same place: a suppression against that address, checked before any future outreach, with the decision recorded. Nothing about it is best-effort — the check happens in one place, before a message is written rather than after.
From the request to the record#
- Trigger — an unsubscribe link is used, or a reply arrives asking not to be contacted again.
- External event — for a click, the request comes from a browser; for a reply, from the mailbox on its ordinary sync.
- Authentication and workspace resolution — the request is resolved to the workspace that sent the original message, before any record is written.
- Ingest — the address and the message it refers to are identified, so the suppression attaches to something rather than floating.
- Canonical record — a suppression is written against the identity, and the reply, if there was one, stays on the thread as ordinary mail.
- Classification — a request to stop is separated from a complaint and from a bounce: all three suppress, and they mean different things about the address.
- Knowledge, memory and rules — where the intent is broader than one address, a
block:emaildirective on the contact holds across future conversations; the tag list is whatdirectives()reads. - Autonomy and approval — none. An unsubscribe is not a decision a person is asked to approve, and no autonomy mode overrides it.
- Action — nothing is sent. A confirmation message to somebody who asked for no more messages is the mistake this flow exists to avoid.
- Result — the address is suppressed from that point, and every outreach path checks it before writing anything.
- Relationship, timeline and memory — the person's record shows they asked to stop, so the next person to look does not undo it out of ignorance.
- Audit, usage and Needs You — the suppression is recorded, and every later refusal it causes is recorded too, because a refusal is a decision.
Two routes in, one record out#
| Route | What you see | What changes | What can fail |
|---|---|---|---|
| The link in an outreach message | Nothing in the app until the record appears | A suppression against that address | A link followed by a scanner rather than a person, which suppresses somebody who never asked |
| A reply that says stop | An ordinary message on the thread | A suppression, plus whatever the reply itself needs | A reply that reads as a refusal to buy rather than a request to stop — the two are not the same |
| A complaint reported by the provider | A record against the address | A suppression, on a stricter footing | Treating a complaint as an ordinary unsubscribe: it says the recipient reported the mail, which is worse |
| A hard bounce | A record against the address | A suppression for deliverability, not for consent | Suppressing the person rather than the address, when the address has simply gone |
What a suppression stops, and what it does not#
A suppression stops outreach to that address. It is checked in the same single place as unsubscribe, complaints and do-not-contact, before any outreach is written, which is why a suppressed address cannot be reached by a sequence that was configured before the suppression existed.
What it does not automatically do is silence a conversation the person starts themselves. Outreach and a customer reply are separate paths with different gates: somebody who asks to be removed from a mailing list and then writes in with a support question has asked for two different things. Where the intent really is 'never contact me at all', the tool that expresses it is a block directive on the contact, tagged per channel, which holds across channels and across future conversations.
- Scope
- The address that asked. A colleague at the same organisation is a different identity and is not covered unless a block is set on the person or the company.
- Duration
- Until somebody clears it, and clearing is a deliberate act with the origin of the entry shown beside it.
- Who may clear it
- A workspace member with the rights to. The Assistant may not clear a do-not-contact entry at all — that boundary is deliberate and is not a permissions oversight.
- Effect on existing work
- A queued outreach message for that address is refused rather than sent, and the refusal is recorded against the row it belonged to.
Proving it worked#
Open the person's record and look for the suppression on their identity.
Result The entry names where it came from, which is what stops somebody clearing it by accident later.
Check the Decision Log around the time of the request.
Result The suppression is recorded there, and so is every later refusal it caused.
If a sequence was running, confirm it stopped rather than paused.
Result A stopped sequence has a recorded reason; a paused one resumes.
Where the intent was broader than one address, set the block directive as well.
Result The block travels with the contact across channels, which a per-address suppression does not.
Questions#
Does an unsubscribe delete the person's data?
No, and conflating the two would be a mistake. An unsubscribe is a statement about future contact; the history of what was already exchanged stays on the record, which is what makes the suppression explainable.
Can somebody re-subscribe?
A suppression can be cleared by a workspace member, and the origin of the entry is shown so the person clearing it can see what they are undoing. A do-not-contact entry is the one nobody clears casually, and the Assistant cannot clear it at all.
What if the unsubscribe arrives as a reply rather than a click?
It is still an unsubscribe. The reply is ordinary inbound mail, so it appears on the thread, and the request inside it produces the same suppression record as a click would.