Messaging, consent and opt-out
The area where a technically flawless implementation can still be unlawful, so the requirement is part of the specification.
Messaging automation is where a technically flawless implementation can still be unlawful. The code sends what it was told to send, to the list it was handed, and not one of the questions that decide legality — how consent was obtained, whether it remains current, whether an unsubscribe has been honored everywhere — is visible anywhere inside it.
Consent is stored as data, not assumed from the existence of a contact record: when it was given, through what mechanism, and the exact wording shown at the time. A claim that somebody opted in is worth precisely as much as the record standing behind it, and the moment that record is needed is the moment somebody is disputing it.
Opt-out is checked against a single suppression list at the point of sending. The characteristic failure is a person unsubscribing in one platform and continuing to receive from another because every system holds its own copy of the list, and each one is individually behaving correctly.
Suppression is evaluated at send time rather than when the list was assembled. A list built on Monday and sent on Thursday will message everyone who opted out on Tuesday, and the gap between assembly and delivery is invisible in the sending platform's own reporting.
Channel requirements are handled separately rather than generically, because they differ: identification of the sender, a working unsubscribe mechanism, quiet hours where they apply, and the boundary between transactional and promotional content. A single promotional line inside an otherwise transactional message can reclassify the entire message and the obligations that attach to it.
Transactional automations are therefore scoped narrowly and defended against well-meant additions. An appointment reminder carrying an offer has stopped being an appointment reminder, and the person who added the offer will not be the person who has to account for it.
Sending is rate-limited and volume-capped as a safety property instead of for deliverability. A loop that sends is the most damaging defect available here, because unlike almost every other failure it cannot be undone — the messages have arrived, and the remedy is an apology, not a fix.
Non-production environments cannot reach real people, and the guarantee is structural rather than procedural: outbound messaging in any environment that is not production routes to a sink. A rule that depends on somebody remembering to point the test at a safe address is a rule that holds until the first busy afternoon.
Bounces, complaints and delivery failures are recorded against the contact rather than discarded. A rising complaint rate is simultaneously a deliverability problem and a consent problem, and the two have the same root cause often enough that treating it only as the former is how a sending reputation degrades quietly.
What this does not cover.
- Unsolicited outbound messaging, and any sending program without a working, honored opt-out.
- Purchased or scraped contact lists.
- Promotional content inserted into transactional messages.
Automation & Integration
Silent failure
Instrumenting automations so that not running is a detectable state, and proving the alarm reaches a person by breaking things deliberately.
When work runs twice
Everything in ordinary use delivers at least once, so whether a second delivery is harmless is decided before anything is written.
Scheduled work
Timezones pinned, clock changes handled deliberately, overlap prevented, and missed runs given a defined behavior.
Event-driven work
A public address carrying somebody else's reliability: verify it, record it, acknowledge fast, do the work afterwards.
Working with other companies' systems
Built against what another company's system actually does, not what its documentation says, with the differences written down.
The automation register
Six fields per automation, kept with the code, so that what runs is knowable and switching something off is possible.