How Can Localized CPaaS Players Thrive?

Who really knows?

In the past two months I’ve been conducting briefings with a lot of the CPaaS vendors out there. Some of them are now being added to my Choosing a WebRTC API Platform report that is getting a refresh next month.

During these chats, I came to realize a relatively lesser known type of CPaaS – the localized one.

To me, it was almost always about two types of players: you were either a “telco” or a global players. Telcos were based in their geography of operation, both limited and protected in their environment due to rules and regulations. Global players were the pure XaaS cloud vendors. I even created a nice graphic for that in 2013, comparing telcos to OTTs:

What we see now are mainly UCaaS vendors who are trying to join the CPaaS world. Put simply – vendors offering phone systems as a service to enterprises adding APIs for developers.

There are two reasons why these vendors are local in nature:

1. Their offering is still tethered to a phone number for the most part, making them a kin to the telco
2. They prefer it that way, probably because of where most/all of their business is taking place

For UCaaS, this localization might not a real issue. Corporations are still thinking locally, even the global ones. You work with people. And use phone numbers, so you tend to use the “law of the land” in every country. From how you allocate phone numbers to what exactly BYOD means at that country.

The problem starts when you want to serve one of two markets as your customers:

1. Large multinational coroporates, whose footprint is global
2. Small enterpreneurial teams who are spread out globally

That first one always existed. But I believe there are more of them today – smaller sized companies are reaching out globally, making them “multinatoinal corporations”.

The second? More of them as well, but probably focused on specific industries – high-tech comes to mind immediately.

What changes when moving to CPaaS while staying local?

First thing you’ll notice with these vendors, is that while they may be using AWS for their data centers and are offering WebRTC connectivity and VoIP, their distribution across AWS data centers ends up looking something like this:

This means that WebRTC calling is going to be affected – and not for the better. If I need to get a call going in France (2 people in Paris for example), then they get connected via US East – maybe even rounting their media through US East. Which lends itself to a bad user experience.

For UCaaS we might not care, as this would be an outlier – but for CPaaS?

The difference now is that we are API driven in what we do. We build processes around our company to offer programmatic communications. And these tend to be wider spread than the local mindset of corporate communications.

Are we using CPaaS to enable our customers to interact directly with each other? Are our customers as local as our own company is?

The end result

In most cases, the end result is simple. CPaaS is there as an API initiative for the UCaaS vendor.

As companies learn the importance and strength of integrations (see Slack and many of the new startups who offer B2B services and capabilities), they tend to offer APIs on top of their own infrastructure. One that their customers can use to integrate better. This makes CPaaS just that API layer.

In the same way that a movie rating company would offer an API that exposes its ratings, a UCaaS vendor exposes an API that enables communications – and then coins it CPaaS.

Only it may not really be CPaaS – just an API layer on top of his UCaaS offering.

The business models here are also different – they tend to be per seat and not per transaction. They tend to rely on the notion that the customer already paid for UCaaS, so no need to double dip when he uses CPaaS as long as he does that reasonably.

Does this make it any worse?

No.

It just makes it different, but still something you’d like to try out and see if it fits your needs.

–

Is this confusing? The whole UCaaS/CPaaS area is murky and mired with doubletalk and marketing speak. It is really hard to dig deeper and understand what you’re getting before trying it out.

Tomorrow I’ll be starting out a short series of emails about the decision making process of build vs buy – building a comms infrastructure versus adopting a CPaaS offering. If you aren’t subscribed to my newsletter, then you should subscribe now, as these emails will not be available here on the blog.