The compliance check before outreach
Every outbound first contact passes one check that asks whether this recipient may be written to at all. Suppression, unsubscribe, complaints and do-not-contact are evaluated together in a single place rather than at each call site, so there is no path that skips them. A do-not-contact entry is not something the Connect Assistant can clear.
One place, on purpose#
The failure this design prevents is the familiar one: five features that each send mail, four of which remember to check suppression. Outreach, follow-ups and replies all pass through the same evaluation, so adding a new way to send does not create a new way to miss a rule.
Outreach and an ordinary customer reply are, however, two different paths with different gates, and they are deliberately never merged. Writing to a stranger and answering someone who wrote to you carry different obligations, and collapsing them into one code path is how a suppression intended for cold mail ends up silencing a support reply.
What is checked#
| Signal | Where it comes from | Cleared by |
|---|---|---|
| Do-not-contact | A person's explicit instruction | A person, deliberately — never the Assistant |
| Unsubscribe | The recipient's own action on a previous message | The recipient, in practice |
| Complaint | A provider's feedback about a previous send | Not casually; the record stands |
| Suppression | Bounces, blocks and prior refusals | Depends on the cause; a hard failure is not retried |
| Prior contact | This workspace already wrote to this business | Time and a reason, not a second cold message |
| Block directive | A memory row tagged block:<channel> against the contact | Removing the memory, which a person can see and do |
The block directive is worth understanding because of where it lives. Blocking is not a column on a contact — it is a memory row carrying the tag block:<channel>, and the directive reader looks only at the tag list. That is exactly what makes a block hold across channels and across future conversations rather than applying to one thread and being forgotten.
Prior contact, and why it is a compliance question#
Writing to the same business twice as though for the first time is not illegal, and it is still the failure that costs the most reputationally. It reads as proof that nobody is keeping track, and it is indistinguishable from bulk mail to the person receiving it.
So *already contacted* is a first-class part of the check rather than a reporting nicety. This is also the count that the old headline numbers got most badly wrong: derived from the newest 500 rows, a workspace whose forty already-contacted contacts were its oldest was told zero had been contacted. Nothing was actually re-sent — the check itself was not the thing reading a slice — but the screen was telling a person it was safe to run a campaign that was not new.
What a person can and cannot do#
- Add a do-not-contact entry
- Any workspace member may. It takes effect for every channel and every future conversation.
- Clear a do-not-contact entry
- A person, and only deliberately. The Assistant's rights are narrower than a person's precisely here — it cannot clear one, in the same way it cannot set a price.
- Override a suppression for one send
- Not as a bypass. The cause has to change; a suppression that exists because mail hard-failed is not cleared by wanting to send again.
- See why something was refused
- Yes. A refusal is a decision and is recorded as one, with what was decided, under which rule, and what happened.
That last row is the reason this check does not feel like a black box. The audit trail carries refusals alongside actions, so *why did this prospect never receive anything* has an answer that does not require anybody to reconstruct the run.
Questions#
Does the check run again at send time, or only when the message is drafted?
Again at send. A message approved this morning is re-evaluated when it actually goes, so a suppression added in between wins over an earlier approval.
Someone replied STOP on a text. Does that affect email?
A block held as a directive applies across channels by design, because it lives as a tagged memory against the contact rather than as a per-channel flag. A channel-specific suppression stays specific to its channel; the two are different records and the screen shows which you have.
Can I see everything suppressing one business in one place?
Yes — the reasons show with their origin on the record. That matters when a prospect looks contactable and nothing sends: usually one entry with an unexpected origin explains it in a glance.