Choosing a channel per message, not per programme

Most organisations pick a channel once, for a whole programme — "reminders go by SMS", "marketing goes on WhatsApp" — and then spend the next year handling exceptions. A one-time code, an order update, a promotion and a support reply have almost nothing in common except the transport, so a single channel for all of them is wrong for a large share of the traffic. The fix is to move the decision to the moment of sending, and to make it a small, written-down rule set rather than a configuration value nobody revisits.

Intent. What the message is for. Messages differ in urgency, in which consent basis covers them, in how they are billed and in what happens if they arrive late.

Region. The same promotional message is a registered campaign in the United States, an AD-marked message from a registered sender in the UAE, a registered template on India's DLT platform, and in much of Europe a matter of consent law rather than registration. The rules differ; there is no country where they are absent. Region decides deliverability.

Consent held. Not consent in general — the specific basis you hold for this person, this purpose and this channel. If your send path cannot read that, it cannot make the decision, and you are making it by assumption.

Reachability. Where this person actually reads. Observed behaviour (they replied on WhatsApp last week) beats a stored preference, which beats a guess.

1. Is there an open conversation? If the customer wrote recently, reply on that thread. On WhatsApp, free-form replies are only allowed within 24 hours of the customer's last message; after that you need an approved template. Inside the window, nothing else competes on engagement, and no template is needed. These replies are no longer always free: since 1 October 2026 Meta charges for them after 1,000 free per business number each month.
2. Is it time-critical? If lateness makes it worthless — a code, a fraud alert — pick for speed and reach first. In many markets that is still SMS.
3. What consent do you hold for this channel? A veto, not a preference. No basis, no send.
4. Where does this person actually read? Use behaviour first, preference second.
5. Only then, cost.

Putting cost last is deliberate. A channel mix optimised on unit price reliably produces a programme that is cheap per message and expensive per outcome.

An online retailer needs to tell two customers in the UAE that their orders have shipped.

• Customer A asked about delivery on WhatsApp three hours ago. There is an open conversation, so the update goes as a normal reply in that thread. No template, no new consent question, and the customer sees it where they are already looking.
• Customer B has never messaged the business. There is no open thread, so a WhatsApp message would need an approved utility template and a WhatsApp opt-in on file. The consent record shows SMS opt-in only, so the router sends a transactional SMS from the registered sender ID — not an AD-marked promotional one, because this is a service message.

The router returns, for each: the channel, the rule that fired, and the consent record it relied on. When customer B later asks why they did not get WhatsApp, support can see the answer in one line.

Automatic fallback — "try WhatsApp, then SMS" — is attractive and quietly dangerous, because consent is per channel. A fallback that sends on a channel you hold no basis for has turned a delivery optimisation into a compliance incident.

Fallback is fine. Fallback that checks consent at each hop is fine. Fallback that assumes permission travels between channels is not.

One channel and a lot of exceptions. Every manual override is a message the router would have placed elsewhere. If more than a small share of sends need one, the decision is being made at the wrong level.

Support replies arrive on a different channel from the question. The customer wrote on WhatsApp and got an SMS back, because the reply path was configured per programme rather than per conversation. This is a leading cause of customers repeating themselves, and it costs more in handling time than the transport saves.

Consent is checked once, at the top. If the check runs before the channel is chosen, it is checking a channel nobody has picked yet. It has to run after.

A working router is usually a few dozen rules, not a machine-learning problem. What matters is that they are written where a non-engineer can read and challenge them.

The router belongs behind your own send function, not inside one vendor's console, for two reasons that have nothing to do with vendor risk.

First, the inputs are yours. Intent comes from your application, consent from your ledger, region from your contact record. A rules engine that cannot read those is guessing exactly where guessing is expensive.

Second, the decision needs a log. Providers log delivery; few log why a channel was chosen, because they only see the one you picked. When a regulator, a customer or your finance team asks, the answer should be a row, not a reconstruction.

• Can I choose the channel per message through the API, rather than per campaign or per account?
• When you fall back from one channel to another, do you check consent for the new channel, or do you leave that to me?
• Do delivery receipts and replies on every channel come back through one webhook format, with my own message ID attached?

The open-conversation rule depends on the 24-hour window. The consent check depends on having a real ledger — see consent architecture. For the SMS registration side, read 10DLC registration without tears. To compare every channel by need, place and audience before you write the rules, see which channel for which need and the Channels 101 primers it links to.