Amey-Thakur Transactional messaging
A transactional message is one the user is actively waiting for, which makes latency and delivery non-negotiable in a way marketing never is. It also usually cannot be unsubscribed from, which places obligations on what it may contain.
Method
- Separate transactional from marketing at the infrastructure level. Different sending domains and streams, so a marketing reputation problem cannot block a password reset (see email-deliverability).
- Send immediately and monitor latency. A reset arriving in five minutes is a failed reset, because the user has already retried twice.
- Say the one thing plainly. The code, the amount, the status, visible without scrolling and without marketing wrapped around it.
- Keep promotional content out. Adding marketing to a receipt can reclassify it as commercial mail in some jurisdictions, with consent obligations attached.
- Make it verifiable and safe. Users are trained by phishing to distrust these, so consistent sender identity and no unexpected link patterns matter (see phishing-resistance).
- Retry with alerting on failure. A failed transactional send is an incident, not a metric, and needs a fallback channel where the action is critical.
- Include what the user needs to self-serve. Order number, support path, and what happens next, so the message reduces support contact rather than causing it.
Boundaries
Transactional exemptions from consent rules are narrow and depend on content; adding promotion can remove the exemption (see pii-handling). Delivery is best effort even at high reliability, so critical flows need an in-product path that does not depend on a message arriving.