SMS and email orchestration without cannibalizing either channel

The week a customer got the same message four times

We inherited a client whose email program and SMS program were run by two different tools that did not talk to each other. One launch week, a customer got the abandoned-cart message as an email, then the same offer as an SMS two hours later, then a reminder email the next morning, then a final SMS that evening. Four touches, one decision to make, and the customer made it: they unsubscribed from both.

That is what happens when SMS and email run as two separate programs rather than one orchestrated system. Each channel optimizes for its own open rate and the customer absorbs the sum. We rebuilt the client's lifecycle so a single orchestrator decides which channel sends, when, and whether the other channel is even allowed to follow. Here is the logic.

One orchestrator, not two programs

The core change is that no message picks its own channel. A single orchestrator in n8n owns every outbound lifecycle touch and makes three decisions in order: does this person qualify for the message at all, which channel should carry it, and is a send allowed right now given everything else they have received.

That ordering matters. Most stacks decide the channel first because the tool is the channel. Klaviyo sends the email, the SMS tool sends the SMS, and nobody owns the question of whether both should fire. When the orchestrator owns the decision, the channel becomes an output of the logic instead of the starting point.

Channel-priority logic

Each lifecycle event has a channel priority, and the priority depends on urgency and cost.

SMS is expensive per message and far more intrusive, so it is reserved for two cases: time-sensitive events where minutes matter, and high-intent moments where the lift justifies the intrusion. An abandoned checkout within the first hour, a back-in-stock alert for a watched item, a shipping exception. These earn an SMS.

Email is the default carrier for everything else: education, nurture, receipts, newsletters, slow-burn re-engagement. It is cheap, it is roomy, and people tolerate volume there that would get an SMS program shut down.

The priority rule is concrete. For each event we set a primary channel and a fallback. If the primary is SMS but the person has no valid mobile or has hit their SMS cap, the orchestrator falls back to email. If the primary is email but the person has not opened an email in 60 days and we have a fresh SMS consent, a single high-value event can promote to SMS as a last attempt before we suppress them. The fallback is something we decide deliberately rather than let happen by accident.

Frequency caps that span both channels

The rule that fixed the four-touch problem: frequency caps count across channels, not per channel.

We maintain a single touch ledger per person. Every send, SMS or email, writes a row. The caps read that combined ledger. The defaults we run for most lifecycle programs: no more than 1 SMS in any 24 hours, no more than 4 emails in any 7 days, and a combined ceiling of 5 total commercial touches in any 7 days regardless of channel. Transactional messages (receipts, shipping, password resets) are exempt and tracked separately so they never eat into the commercial budget.

Because the caps are combined, an SMS spends part of the weekly budget that email would otherwise use. That is the point. The customer experiences one brand talking to them at a sane volume, not two tools each staying under their own limit.

Cross-channel suppression

Frequency caps limit volume. Suppression handles the worse failure: the same message arriving twice on two channels.

Every lifecycle message carries a content key, a short hash of the message intent and the entity it refers to. Abandoned-checkout for cart 8842 has one key whether it goes out as email or SMS. The orchestrator checks the touch ledger for that content key before any send. If cart 8842's abandon message already went out on either channel in the last 48 hours, the second channel is suppressed. The customer gets the abandon nudge once, in whichever channel won the priority decision, and never the duplicate.

Suppression also runs the other direction on outcomes. If someone clicks the email and completes the action, the queued SMS follow-up is cancelled outright rather than merely delayed. If someone replies STOP to an SMS, the orchestrator writes the opt-out to the shared profile and the email program reads it immediately, so an SMS opt-out never leaves email blasting away. One opt-out, both channels, no lag.

A concrete result

We ran the rebuilt orchestration for the same client over a full quarter against their prior split-tool setup.

Total message volume dropped 22 percent, because the cross-channel caps and suppression killed the redundant sends. Combined unsubscribe rate fell by roughly a third. And the revenue attributed to the lifecycle program went up 14 percent, not down, even though we sent fewer messages. Fewer, better-timed touches converted better than the firehose did.

The abandoned-checkout flow tells the story cleanly. Before, it was an email at 1 hour, an SMS at 3 hours, an email at 24 hours, an SMS at 48 hours, each tool firing on its own clock. After, it is a single orchestrated sequence: SMS at 1 hour if the cart is high-value and we have consent, otherwise email at 1 hour, then exactly one email follow-up at 24 hours if the cart is still open and the person has not hit their weekly cap. Two touches, both suppressed the moment the customer checks out. Recovery rate held steady while complaints went to near zero.

The data model that makes all of this possible

None of this works without one prerequisite: a single profile per person that both channels read and write. The four-touch disaster we inherited was not really a logic problem. It was a data problem. Two tools each kept their own copy of the customer, their own consent state, their own send history, and neither could see the other.

So the first thing we built was a shared profile store that both the email engine and the SMS engine treat as the source of truth. It holds the person's identity, their consent state per channel with the timestamp and source of each consent, the combined touch ledger, and the suppression list. Every send writes to the ledger before it goes out, not after, so a near-simultaneous SMS and email cannot both read an empty ledger and both decide they are clear to fire. We use the ledger write as a lock: the orchestrator claims the touch slot first, then sends, so two messages racing for the same weekly budget cannot both win.

Consent lives here too, and that turned out to matter for compliance as much as for experience. SMS consent and email consent are legally distinct and have to be tracked separately, but the suppression that flows from a STOP reply or an unsubscribe has to propagate sensibly. A STOP suppresses SMS hard and immediately. It does not auto-kill email, because they are separate consents, but it does flag the profile so a human can decide whether the person is souring on the brand entirely. The shared store is what lets that nuance exist instead of an all-or-nothing toggle.

Timing windows so neither channel arrives at a bad hour

The orchestrator also owns send timing, because a perfectly suppressed message at 6am is still a mistake. Each channel has its own quiet hours. SMS never sends outside roughly 9am to 8pm in the recipient's local timezone, which is both a courtesy and in many places a legal requirement. Email has gentler bounds but still avoids the dead-of-night send that signals automation and hurts deliverability.

When a lifecycle event fires at a bad hour, the orchestrator does not send and then apologize. It holds the message until the next valid window for the chosen channel, re-checking the frequency caps and suppression at release time, because the situation may have changed while the message waited. A customer who converted overnight should never get the held nudge in the morning, and the release-time re-check is what catches that.

What we would tell another operator

If your SMS and your email live in two tools that do not share a ledger, you do not have orchestration, you have two programs competing for the same attention. Put one decision-maker in front of both. Build a single profile both channels read and write, and use the ledger write as a lock so simultaneous sends cannot both think they are clear. Count frequency across channels on a single ledger. Give every message a content key and suppress the duplicate. Let opt-outs and conversions on one channel cancel the queue on the other instantly. Respect quiet hours per channel and hold, then re-check, rather than send blind.

The customer does not think in channels. They think in how often that brand bothers them. Build the system that thinks the same way. More on how we wire cross-channel lifecycle at arthea.ai.