Short answer: use email as the default channel for a compliance notice, then add SMS when the event is time-sensitive and the recipient has given the required permission. Keep the message template in your application, record the rendered content and policy decision, and treat provider delivery data as evidence rather than as the whole audit trail.
The least complex system is usually a durable notification job with a channel policy. It does not start with a provider comparison. It starts by answering one question: what must a reviewer be able to prove six months later?
| Decision | SMS | |
|---|---|---|
| Best default for a detailed notice | Yes | No |
| Good fit for a short, urgent alert | Sometimes | Yes |
| Template ownership | Application-controlled | Application-controlled |
| Audit evidence | Rendered body, recipient, timestamps, provider result | Rendered body, recipient, timestamps, provider result |
| Main operational risk | Suppression and unsubscribe state | Consent, carrier filtering, and limited message space |
For a one-person SaaS, this is a revenue-per-hour decision. Ship the shared audit model once. Outsource the undifferentiated transport work. Keep the policy and template where the business logic lives.
What should the audit record prove?
A delivery record should distinguish intent, dispatch, and outcome. Those are three different events.
Intent means the system decided that a particular notice belonged to a particular recipient. Dispatch means a channel adapter accepted the message for sending. Outcome means the adapter later reported a result, such as delivery, rejection, or a temporary failure.
Do not collapse these into sent: true. That boolean makes a dashboard look calm while hiding the exact question an auditor will ask: what did the system try to send, to whom, under which template revision, and what did the transport report?
A useful event record can be small:
type NotificationAudit = {
notificationId: string;
eventId: string;
recipientRef: string;
channel: "email" | "sms";
templateId: string;
templateRevision: string;
renderedBodyHash: string;
policyDecision: "allowed" | "blocked";
requestedAt: string;
dispatchedAt?: string;
providerMessageRef?: string;
outcome?: "delivered" | "rejected" | "failed" | "unknown";
};
The hash is not a substitute for retention controls or access controls. It is a compact way to detect that the rendered payload later changed. If the notice itself must be reviewable, retain the rendered artifact under the system's data-retention policy and protect it like other regulated records.
Templates belong in the application when the template determines compliance meaning. A transport service can accept a body, but it should not silently rewrite the legal substance, select a different revision, or decide that an email should become an SMS. Those decisions need code review, versioning, and a record.
Which channel is the cost-effective choice for event alerts?
The answer depends on the event, not on a universal price table. Email is the practical starting point when the notice needs explanation, links, formatting, or a durable copy. SMS earns its place when delay has a meaningful operational cost and the content can remain short.
That trade-off has a second dimension: failure handling. An email can remain queued while a recipient checks it later. An SMS alert may be more visible at the moment of the event, but permission, carrier filtering, number changes, and message-length constraints become part of the system you operate. The cheaper transport is not the one with the lower listed unit price; it is the one that meets the event's required response without forcing a second notification flow for every edge case.
For compliance notices, the FTC's CAN-SPAM guidance makes a clear distinction between a message's business context and the obligations around commercial email. The implementation should therefore store the policy decision that allowed the email, along with the recipient's address and the notice content. Do not assume that a successful API response proves compliance.
I would use two decision gates:
- Meaning gate: Can the recipient understand and act on the notice without a second channel? If yes, email is usually the simpler default.
- Urgency gate: Does a delay until the recipient checks email create material risk? If yes, evaluate SMS, but make consent and fallback behavior explicit before shipping it.
The point is not to maximize messages. It is to minimize ambiguous outcomes.
Keep it boring.
How do you keep template ownership from becoming a delivery bug?
Put the template revision into the notification command, then render before handing the message to a channel adapter. The adapter should receive a finished payload and metadata. It should not receive a vague instruction such as send_compliance_notice and invent the content from its own configuration.
type NotificationCommand = {
eventId: string;
recipientRef: string;
channel: "email" | "sms";
templateId: string;
templateRevision: string;
variables: Record<string, string>;
};
type OutboundMessage = {
recipient: string;
subject?: string;
body: string;
templateId: string;
templateRevision: string;
};
interface ChannelAdapter {
dispatch(message: OutboundMessage): Promise<{ messageRef: string }>;
}
This boundary gives a small team a useful property: changing a transport does not change the notice. A later migration can replace the adapter while the policy, rendered body, revision, and audit events stay stable. My rule is to make a template revision explicit even when the first version is tiny, such as 2026-10-28.1; the string is cheap, while reconstructing which wording went out after a policy edit is not. That is the kind of decoupling that pays back in a weekly shipping cycle, because a new adapter can be tested against the same rendered fixture instead of a moving template.
The common trap is rendering twice. The application renders a long notice, the SMS adapter truncates it, and the audit log stores only the original. Now the record proves what the application intended, not what the recipient received. For each channel, render the actual channel payload once, hash that payload, and persist the exact version associated with the dispatch attempt.
What fails in production even when the API call works?
Retries are the first trap. A timeout after dispatch does not mean the provider received nothing. Suppose the worker sends a notice, loses its connection before the response arrives, and retries after the queue visibility window expires. Without a stable notification identifier, the first message and the retry are indistinguishable; the audit view can show one intent while the recipient receives two notices. Retry with an idempotency key or an equivalent application-level deduplication record, and make the notification identifier stable across attempts. Otherwise one compliance event can produce two messages.
The second trap is treating provider callbacks as a complete history. Callbacks can arrive late, out of order, or more than once. Store them as append-only observations keyed by the provider reference, then derive the current status. Preserve the raw event long enough to investigate a disagreement between the dispatch log and the later outcome.
The third trap is testing only the happy path. Test a blocked policy decision, a missing recipient, a template revision that cannot render, a transport timeout, a duplicate callback, and a successful retry. The test should assert the audit record as well as the user-visible message.
Keep observability boring: a correlation ID, structured events, queue age, retry count, and outcome by channel. Do not log full recipient addresses or message bodies into general application logs when a reference and protected audit store will answer the investigation.
When is the runner-up channel the better choice?
SMS is the better choice when the event is genuinely urgent, the payload is short, the recipient has an appropriate opt-in, and the team can handle number lifecycle and delivery uncertainty. It should usually point to a controlled destination for detail rather than trying to carry a complete compliance explanation in a tiny payload.
Email is the better choice when the notice needs a durable explanation, a clear subject, a link to supporting records, or an easy path to unsubscribe where applicable. It is also the better fit when the recipient may need to forward the notice to an internal reviewer.
A dual-channel design can be justified, but only with a clear purpose for each message. “Send both just in case” creates duplicate noise and doubles the audit surface. Define whether SMS is a prompt for an email, an independent notice, or a fallback after a measured delay. Record that relationship.
For a small fintech team, I would ship email plus the shared audit model first. Add SMS after the urgency threshold, consent path, and duplicate-suppression tests are written down. That order keeps template ownership with the team that owns the compliance decision and leaves transport mechanics replaceable.
Top comments (0)