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

Getting bytes to a handset or an inbox. This is the layer with published per-message pricing, the layer every comparison table compares, and the layer where the differences between serious vendors are smallest.

It is a commodity in the precise economic sense: substitutable, price-competitive, and increasingly hard to differentiate. Which is exactly why vendors would rather talk about it than about the layers above, where switching is hard.

Who is allowed to send what, on whose behalf. Issued credentials, scopes, revocation, and — the part almost nobody has — service-to-service identity, so one system can act for another with proof and a revocation path.

Without this layer you can send, but you cannot delegate, cannot revoke a partner's access without rotating everyone's, and cannot answer "who sent this" after the fact.

Deciding what to send, to whom, on which channel, in what order, and what to do when nothing comes back. This is where the actual business logic lives, and where the difference between one message and a programme is made.

Skip this layer and every channel becomes its own project, with its own definition of a customer. That is how the same person receives the same notice three times in an hour from three different systems.

Permission, preference, disclosure and the evidence for all three. It is not a subsection of orchestration — it must be able to veto orchestration, which means it sits above it.

Whether any of it worked, in terms someone outside the team recognises. Not delivery rate: outcomes, with a holdout.

Two things fall out of it.

Your evaluation is probably at the wrong altitude. If the shortlist is being decided on per-message price, you are optimising the commodity layer while the layers that determine success are unexamined.

Switching cost climbs as you go up. Transport is genuinely swappable. An orchestration layer holds your logic; a consent ledger holds evidence you are legally obliged to keep. Buy transport casually. Buy the upper layers as though you will live with them for years, because you will.

Almost every vendor claims all five. A quick way to find the truth: ask what happens at the boundary.

Transport specialists answer routing questions precisely and orchestration questions vaguely. Ask about branching on a customer's reply and you will get a webhook and a suggestion.

Orchestration specialists have an opinion about journeys and are indifferent about routes. Ask which carrier a message takes to a given country and the answer is "our partner's".

Suites claim both, and the honest question is which half was built and which was acquired. Ask whether the two share an identity model. If a contact in the journey builder and a contact in the messaging log are different objects, they were bolted together, and that seam becomes yours.

Switching cost is not evenly distributed, and knowing where it concentrates changes what you negotiate hardest.

Transport is genuinely swappable — a thin abstraction and a fortnight. Orchestration holds your business logic, and moving it means re-expressing every journey in a new tool's idiom. Consent holds evidence you are legally obliged to retain and may need years later.

So negotiate export rights hardest on the layers you are least able to leave, which are precisely the ones vendors are least keen to make portable. If a contract lets you export messages but not journeys or consent history, you have bought a one-way door.

Of the five, identity is the one most often absent entirely, and its absence is invisible until it is expensive.

Most stacks have credentials for applications and none for delegation — nothing that expresses "this system is acting for that customer, with these permissions, until this moment". It works fine until something is layered on top, and then revocation becomes all-or-nothing and audit becomes archaeology.

If you are assembling this rather than buying it, the order that avoids rework is:

1. Consent first. Everything else eventually asks it a question, and retrofitting a ledger under a live send path is the worst of the migrations.
2. Transport second, behind a thin interface, so it stays replaceable.
3. Orchestration third, once you know what your journeys actually are rather than what you imagine they will be.
4. Measurement fourth, with the holdout designed in from the first campaign.
5. Identity when you first delegate — and not a day later, because retrofitting it means changing every integration at once.

• Shortlists are usually decided on the commodity layer while the decisive layers go unexamined.
• Ask a vendor a boundary question; the vagueness tells you what they really are.
• Switching cost rises as you go up. Negotiate export rights accordingly.
• Build consent first and identity before you delegate; both are miserable to retrofit.