---
title: "Choosing a channel per message, not per programme"
summary: "The channel decision belongs at send time, driven by intent, region and what consent you hold — not to a procurement meeting eighteen months earlier."
canonical: https://cpaas.co/en/insights/choosing-a-channel-per-message
kind: article
depth: applied
origin: original
published: 2026-07-29T11:34:07.986Z
updated: 2026-09-08T11:34:08.117Z
topics: ["Messaging", "Architecture", "Conversational Marketing"]
language: en
---
# 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.

> **Interactive figure — channel-router.** Pick an intent and a region. The rule that applies is rarely the one people expect.
> Available at https://cpaas.co/en/insights/choosing-a-channel-per-message

## The three inputs

**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.

## The decision, in order

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.**

```diagram:flow
# The order the decision has to run in
Open conversation? | If they wrote recently, reply on that thread. Cheapest, least constrained, highest engagement — nothing else competes.
Time-critical? | If lateness makes the message worthless, pick for latency and reach before anything else.
Consent held? | A veto, not a preference. No basis for this person, purpose and channel means no send.
Reachable where? | Observed behaviour beats a stored preference, which beats a guess.
Cost | Last, deliberately. Optimising unit price first buys a programme that is cheap per message and expensive per outcome.
> Every step above cost can disqualify a channel outright. Cost only ever chooses between channels that already passed.
```

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.

## Building it

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.

## The fallback trap

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.

## What this looks like when it is wrong

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.

## The rule set, written down

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.

```diagram:compare
Case | The naive route | What the router does
One-time code, India | Promotional template, delayed | Transactional SMS on a registered header, sub-10-second path
Order update, UAE | Promotional SMS, AD- prefixed | Service message on the existing WhatsApp thread
Win-back, US | SMS to the whole list | Suppressed — no marketing basis on file for most of it
Support reply, anywhere | New SMS thread | Same conversation the customer opened
> The naive column is not a straw man. It is what a per-programme channel choice produces once the programme meets more than one kind of message.
```

## Where to put it

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.

## What to take away

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.

## Sources

- [Ten-Digit Long Code (10DLC) Registration Guidelines](https://learn.microsoft.com/en-us/azure/communication-services/concepts/sms/ten-digit-long-code-guidelines) — Microsoft Learn

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.