What CPaaS actually is, and what it is not

Before CPaaS, adding a text message to your software meant a commercial negotiation with a telecoms carrier, a leased connection, and a protocol designed in the 1990s for machines that no longer exist. Months, not minutes.

Communications Platform as a Service is the industry's answer to that: the carrier relationship, the protocol, and the operational burden are absorbed by a vendor, and what you get instead is an HTTP API and a bill.

That is the whole idea. Everything else is detail.

A CPaaS is a service that lets software send and receive messages, calls or video through channels it does not own, using credentials it issues, with delivery reported back as data.

Three things are load-bearing in that sentence:

• Channels it does not own. The platform is an intermediary. Its quality is largely the quality of its relationships with the people who do own the channels.
• Credentials it issues. You get a key. The key can be scoped and revoked. This is what makes it a platform rather than a bulk-send tool.
• Delivery reported back as data. Not a dashboard — a callback your system can act on. Without this you are not integrating, you are broadcasting.

When you cannot tell whether something is a platform or a reseller with an API in front of it, ask:

1. Can I integrate without talking to a salesperson? Published documentation, self-service credentials and a sandbox are cheap to provide and enormously revealing. A vendor that will not let you try it is telling you something.
2. What happens when a message fails? A real platform returns a cause. A reseller returns "failed", because it does not know either.
3. Where does the money go? Ask what proportion of the per-message price is the underlying carrier fee. Vendors that own more of the path can answer; ones that cannot are passing through someone else's margin and their own.

Answering them in this order separates a platform from a reseller faster than any feature comparison, because a reseller can match the feature list and cannot match the answers.

It is not a marketing tool, though marketing teams use it. It is not a contact centre, though contact centres are built on it. And it is emphatically not a guarantee of delivery — the platform can accept your message and still have it dropped three hops later by a carrier applying a filtering rule it will not describe.

Understanding that distinction — between accepted, delivered and acted on — is the difference between a programme that works and a dashboard that looks like one.

The category is clearest by contrast, and each contrast removes a different confusion.

A detail that explains a great deal about how these products feel to use: the buyer and the user are frequently different people, and the product is usually designed for whichever of them the vendor's sales motion reaches.

A platform sold to developers has a specification, a sandbox and error codes. A platform sold to marketing directors has a campaign builder and a dashboard. Both may send the same message down the same route to the same handset. They are not competing on capability; they are competing on which job they make easy, and choosing the wrong one produces a year of friction that no feature comparison predicted.

Work out which of the two you are before you shortlist. If the people who will live in the product daily are not the people in the room during the evaluation, the evaluation is measuring the wrong thing.

Understanding the economics changes how you read a quote.

For a message that traverses a carrier network, a large share of the price is a fee the platform collects and passes to somebody else. What the platform keeps is the spread, plus whatever it charges for the software around the transport.

Two consequences follow. First, a very low unit price often signals a route the vendor does not control, which is a deliverability decision dressed as a discount. Second, the parts of the product with genuine margin — orchestration, analytics, the console — are the parts vendors are most reluctant to price separately, because doing so would expose how cheap the transport really is.

Neither is dishonest. But knowing it lets you ask a better question than "what does a message cost": ask what proportion of that price is the carrier's, and watch how readily the answer arrives.

A status page is the cheapest available signal about operational maturity, and almost nobody reads one carefully.

Look for three things. Granularity — does it report per-channel and per-region, or is there a single green light for "Messaging"? A single light cannot express the failure you will actually have, which is one route to one country degrading while everything else is fine. History — are past incidents still visible, with timelines and causes, or does the page only ever show today? Honesty — do partial degradations appear at all, or only total outages?

A vendor whose status page has recorded no incident in two years is not more reliable than its competitors. It is less forthcoming.

• The category is defined by removing a carrier negotiation, not by any feature.
• A real platform issues credentials, publishes a specification, and reports delivery as data your system can act on.
• Ask what happens when a message fails; the quality of the answer is the quality of the vendor.
• Price is mostly pass-through. The interesting margin — and the interesting differences — sit above the transport.

A buyer who thinks they are purchasing a gateway negotiates on unit price and gets one. A buyer who understands they are purchasing a right to send under someone else's operator relationships, plus the machinery above it, negotiates on portability, registration ownership and exit — and those are the terms that decide what the relationship costs over three years.

The definition is not academic tidiness. It is the difference between the two negotiations.