The five layers of a communications stack, and which one you are actually shopping for

A communications stack is everything between "we should tell the customer" and "it worked". It helps to see it as five layers, because buyers usually compare only the bottom one.

Take a chain of dental clinics sending appointment reminders:

• Transport gets the text to the patient's phone.
• Identity decides that the downtown branch may send under the clinic's name, and the marketing agency may not.
• Orchestration sends a reminder 24 hours before, and a WhatsApp message if there is no reply by evening.
• Consent and governance checks that this patient agreed to reminders on this channel.
• Measurement shows whether no-shows actually fell, compared with patients who received nothing.

Getting bytes to a handset or an inbox. This layer has published per-message prices, appears in every comparison table, and is where differences between serious providers are smallest. It is a commodity in the economic sense: substitutable and price-competitive. That is exactly why vendors like to talk about it — the layers above are where switching is hard.

Who may send what, on whose behalf: API keys, scoped permissions, revocation and — the part most stacks lack — delegation, so one system can act for another with proof and a way to revoke it. Without it you can send, but you cannot answer "who sent this?" after the fact, or cut off one partner without disrupting everyone.

Deciding what to send, to whom, on which channel, in what order, and what to do when nothing comes back. This is where your business logic lives, and where one message becomes a programme. Skip it and every channel becomes its own project with its own definition of a customer.

Permission, preference, disclosure (for example, telling people when they are talking to an AI) and the evidence for all three. It is not a sub-feature of orchestration: it must be able to veto a send, which is why it sits above. See consent is a data model.

Whether any of it worked, in terms someone outside the team recognises. Not delivery rate — outcomes, compared with a group that received nothing. See delivery rate is not a result.

Your evaluation is probably at the wrong altitude. If the shortlist is decided on per-message price, you are optimising the commodity layer and leaving the decisive ones unexamined.

Switching cost climbs as you go up. Transport can be swapped behind a thin interface in weeks. Orchestration holds your logic; moving it means rebuilding every journey in a new tool. Consent holds evidence you may be legally required to keep for years. Buy transport casually; buy the upper layers as if you will live with them for years, because you will.

Almost every vendor claims all five. Ask questions at the boundaries:

• Transport specialists answer routing questions precisely and orchestration questions vaguely. Ask how a journey branches on a customer's reply and you get "send us a webhook".
• Orchestration specialists have strong views on journeys and vague ones on routes. Ask which operator carries a message to a given country and the answer is "our partner's".
• Suites claim both. Ask whether the journey builder and the messaging log share one customer record. If they are different objects, the products were joined after the fact, and that seam becomes your problem.

None of these is wrong to buy. The point is to know which layers you are getting, and plan for the rest.

Negotiate export rights hardest on the layers you are least able to leave — orchestration and consent — which are often the ones vendors are least keen to make portable. A contract that lets you export message logs but not journeys or consent history is a one-way door.

An order that avoids rework:

1. Consent first. Everything else eventually asks it a question, and retrofitting a consent ledger under a live send path is the worst migration of all.
2. Transport second, behind a thin interface so it stays replaceable.
3. Orchestration third, once you know what your journeys actually are.
4. Measurement fourth, with a holdout group designed in from the first campaign.
5. Identity and delegation as soon as a second system or partner sends on your behalf — retrofitting it later means changing every integration at once.

• Which of these five layers do you build yourselves, which do you partner for, and which do you leave to me?
• Can I export journeys, templates and consent history in a documented format?
• Can I give a partner limited sending rights and revoke them without affecting anyone else?

• Delivery rate is not a result — the next step in this track.
• How to choose a CPaaS provider — putting the layers to work in a shortlist.
• When to build messaging infrastructure — the build-or-buy decision.