Send the messages a user is waiting for, such as receipts, resets, and confirmations, with reliability and clarity that marketing messages do not need. Use when building password resets, receipts, or order confirmations.
Installs into .claude/skills of the current project.
Are you the author of Transactional Messaging?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-transactional-messaging)
---
name: transactional-messaging
description: Send the messages a user is waiting for, such as receipts, resets, and confirmations, with reliability and clarity that marketing messages do not need. Use when building password resets, receipts, or order confirmations.
---
# 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
1. **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).
2. **Send immediately and monitor latency.** A reset arriving in five
minutes is a failed reset, because the user has already retried
twice.
3. **Say the one thing plainly.** The code, the amount, the status,
visible without scrolling and without marketing wrapped around it.
4. **Keep promotional content out.** Adding marketing to a receipt can
reclassify it as commercial mail in some jurisdictions, with
consent obligations attached.
5. **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).
6. **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.
7. **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.
