Choosing a channel per message, not per programme

Most organisations pick a channel once, for a programme, and then discover that a third of the messages in it would have been better somewhere else.

Intent. A one-time code, an order update, a promotion and a support reply have almost nothing in common except the transport. They differ in urgency, in what consent basis covers them, in how they are billed, and in what happens if they are late.

Region. The same promotional message is a registered campaign in the United States, an AD- prefixed message in the UAE, a registered template in India, and comparatively unconstrained elsewhere. This is not a footnote; it decides deliverability.

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

1. Is there an open conversation? If the customer wrote recently, reply on that thread. Cheapest, least constrained, highest engagement. Nothing else competes.
2. Is it time-critical? If a late delivery makes it worthless — a code, a fraud alert — pick for latency and reach, which usually means SMS despite everything.
3. What consent do you hold? This is a veto, not a preference. No basis, no send.
4. Which channel does this person actually use? Observed behaviour beats a stored preference, which beats a guess.
5. Only then, cost.

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

Make the channel decision a function, not a configuration value. It takes intent, contact, region and consent state; it returns a channel and a reason.

Return the reason. When someone asks in six months why a customer got an SMS instead of a WhatsApp message, the answer should be retrievable rather than reconstructed.

Automatic fallback — "try WhatsApp, then SMS" — is attractive and quietly dangerous. Consent is per channel. A fallback that sends on a channel you have no basis for has converted 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.

Three symptoms show up before anyone traces them back to the channel decision.

The programme has one channel and a lot of exceptions. Every exception is a message the router would have placed elsewhere. Counting them is the cheapest audit available: if more than a fifth of your sends need a manual override, the decision is being made in the wrong place.

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 the single most common cause of a customer repeating themselves, and it costs more in handling time than the transport ever saves.

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

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

The router belongs behind your own send function, not inside a vendor's console. Two reasons, and neither is about vendor risk.

The first is that 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 at exactly the point where guessing is expensive.

The second is that the decision needs a log. Vendors log delivery; almost none log why a channel was chosen, because they only see the one you picked. When a regulator, a customer or your own finance team asks, the answer has to be a row, not a reconstruction.

Channel is a property of a message, not of a programme. Move the decision to send time, give it the four inputs it needs, make it return its reasoning, and put cost last. The programme gets cheaper anyway — just not on the line you were watching.