The suppression list
The suppression list is the single place asked before outreach goes anywhere. Unsubscribes, complaints, permanent bounces, manual entries and do-not-contact instructions all resolve through it, and every entry carries where it came from. Some entries may be cleared by a person with a reason; a do-not-contact entry may not, and the Connect Assistant cannot clear one at all.
One check, not several#
Suppression, unsubscribe, complaints and do-not-contact are checked together in one place before any outreach. That is a deliberate design rather than an implementation detail: the alternative is a check in each screen and each code path that composes a message, which works until somebody adds a new way to send and forgets one of them.
Because the check sits at the boundary, it applies to a draft a person approves as much as to something the engine sends on its own. Approving a held reply to a suppressed recipient fails immediately, and the suppression is shown with its origin, so the person approving learns why rather than watching a button do nothing.
How an address gets on the list#
| Origin | Who decided | May it be cleared? |
|---|---|---|
| Unsubscribe | The recipient, by using the link | By a person, with a reason — usually only when the recipient asks |
| Complaint | The recipient, by marking mail as spam | Rarely, and only on the recipient's own initiative |
| Permanent bounce | The receiving mail system | Yes, once the address is genuinely usable again |
| Manual entry | Somebody in the workspace | Yes, by a person |
| Do not contact | A person, on the strongest footing | No — see do not contact |
The origin is kept because the entries are not the same kind of statement. A bounce says an address does not work. An unsubscribe says a person does not want to hear from you. Clearing the first is an administrative correction; clearing the second is a decision about somebody else's stated wishes, and the list refuses to let the two blur by dropping the reason.
What it blocks and what it does not#
- It blocks outreach — the path that starts with Connect deciding to contact somebody who has not written in.
- It blocks the approval of a held draft to that recipient, at the moment of approval rather than at the moment of writing.
- It does not merge with the reply path. Outreach email and a reply to somebody who contacted you are two paths with different gates, and they are never combined.
- It does not delete anything. The person, the thread and the history stay exactly as they were; what changes is what may be sent.
- It is not the same as blocking a person, which is a different mechanism entirely.
Suppression against blocking#
- Suppression
- An address-level rule about outreach, with an origin, checked at the send boundary. It answers 'may this message go to this address?'
- Blocking
- A durable direction held as a memory row tagged for the channel, so it holds across channels and across conversations that do not exist yet. It answers 'what should Connect do about this person at all?'
The tag is what makes blocking work rather than the words in it, because the directive reader looks at the tag list and not at the body. That is worth knowing before writing 'do not contact this company' as free text and expecting it to act: prose in a memory is knowledge, and a tag is an instruction. Blocking covers the mechanism.
Clearing an entry#
Read the origin before anything else.
Result It tells you whether you are correcting a fact or overriding a person's stated wish, which is the only distinction that matters here.
Write down why it is being cleared, in terms that will still make sense to somebody reading the record later.
Result The entry's removal carries a reason, and reasons are what make a compliance record defensible rather than merely present.
Clear it, if it is an entry that may be cleared.
Result The next compliance check lets outreach through. Nothing that was blocked while the entry stood is sent retrospectively.
If it is a do-not-contact entry, stop.
Result It is not cleared casually, and asking the Assistant to do it will not work — that path does not exist for it, deliberately.
Where you see it bite#
The most common encounter is a held reply that will not go out. That is one of four holds on a finished draft, and it is the only one that fails at the moment of approval rather than quietly waiting: an autonomy setting holds a draft until somebody approves it, a spent allowance holds it until the allowance resets, and a suppression refuses it outright.
The second is prospecting, where the compliance check runs before the first message is composed rather than after. A prospect whose address is suppressed does not reach the point of having a message written for them, which is why the compliance check is a step in that flow and not a filter applied to its output.
Questions#
Can the Connect Assistant add or remove suppressions for me?
It cannot clear a do-not-contact entry, and that limit is deliberate rather than an omission. Anything that ends with a person being contacted against a recorded wish is kept as a human decision with a name against it.
Does suppressing an address stop a reply to a customer who wrote to us?
Those are separate paths with separate gates and they are never merged, so a suppression that exists to stop outreach is not a gag on a conversation the customer started. If you want that too, block the person rather than suppressing an address.
Somebody unsubscribed by replying rather than clicking. What now?
Record it. An intention stated in a reply is as real as one expressed through a link, and the list carries manual entries with their origin for exactly this case. Leaving it unrecorded means the next outreach run has no way to know.