Future of CPaaS; a look ahead

Looking at the future of CPaaS, the lines are blurring in the cloud communication API future. And this isn’t only about UCaaS and CCaaS.

I’ve been asked recently by multiple clients to analyze for them the future of specific technologies they are developing. The process was very interesting and provided a lot of insights - somethings things that haven’t been obvious to me to begin with.

It got me into thinking. What if I do the same around CPaaS? Looking at how the future of cloud communication APIs look like, what are vendors after, what they pitch and brief analysts about, and what their customers are looking for.

I decided to do exactly that, ending up writing this article and creating a new comparison sheet and eBook (this eBook/sheet combo can be found in my WebRTC Course paid-for ebooks section).

-

When looking at what the future holds in the CPaaS domain, there are many aspects to review. If this topic interests you, then you should probably also read these other 4 articles I’ve written previously:

1. 7 CPaaS Trends to Follow in 2018 - the perspective I had a year ago. Mostly still true, but I think we’re accelerating the pace of change and evolving this a lot further
2. What Comes Next in Communications? - a look at how CPaaS, UCaaS and CCaaS vendors are looking at the market and at the blurring lines between them
3. CPaaS differentiation in 2019 - because it shows how different vendors try to operate differently and rise above the noise
4. Twilio Signal 2019 and the future of the programmable enterprise - a summary of the recent Twilio Signal event. Important simply because Twilio is the market leader and innovator in this domain

To take a kind of a "sneak peek" into the future, I suggest you read about CPaaS post pandemic as well 😀

Now that we’re on “the same page”, here’s where I see things heading for communication APIs.

nocode

There’s this new trend of making software development all-encompassing. It boils down to a single non-word used for it known as #nocode

Here’s some of the things people like saying about this trend:

https://twitter.com/Boringcuriosity/status/1172536859513126912

https://twitter.com/dbanisimov/status/1172974365186482176

Interestingly, the place where you see people talk the most about #nocode is in the third party API space. Now that we’ve made integrating with third parties simpler via APIs, it is time to make it even more so by requiring less development skills to do so.

This has been a long time coming to the communication API space as well.

We’ve had visual IVRs for quite some time, and we’ve seen in the past 2-3 years many of the CPaaS vendors adding visual drag and drop tools. Twilio calls their tool Twilio Studio, while the rest of the industry settled on the name Flow.

Who is doing it today with CPaaS?

• IMImobile IMIconnect
• Infobip Flow
• MessageBird Flow Builder
• Plivo PHLO
• Twilio Studio
• Voximplant SmartCalls

Others, like Nexmo, opted for releasing a Node-RED package, enabling developers more flexibility in the integration points the Flow tool has to offer them.

What I fail to understand is why so little activity is taking place in the serverless trend. It is as if CPaaS vendors knowingly decide NOT to offer these and instead jump directly towards the visual drag & drop flow tool.

Look at the diagram above. It shows why I believe it is a mistake to skip the serverless opportunity. We’ve started with APIs, to simplify the task of inhouse development, going towards cloud so we don’t need to install complex systems. We’ve seen a shift towards serverless (think AWS Lambda), where developers can focus on their use case and not think too much about the whole non-functional infrastructure stuff. Then came the visual drag and drop tools, which made life even simpler, as for many scenarios, there is no more need to code anything - just express your intents by connecting dots to boxes.

Developers end up using ALL of the tools given to them. They will use a visual drag & drop tool to speed up development when the flow is easier to express in that tool. They’ll write code when necessary. And they will use serverless functions to reduce the effort of scaling and maintenance if that is needed. So why not give them all of these tools?

CPaaS vendors are doing APIs and moving towards visual. The serverless part is an internal implementation which most don’t expose to their customers. Why? I am not sure.

What should you expect in the coming years?

Visual Flow tools will become an integral part of any CPaaS offering, with more widget types being added into these tools - supporting new features, adding new channels or integrating with external third parties.

Omnichannel

Omnichannel is the biggest thing in CPaaS at the moment.

There are two reasons for this:

1. SMS is crap. And it is getting worse
2. SMS (and voice) is being commoditized. Omnichannel means less churn for CPaaS vendors

Why is SMS crap? Because in the last week or so I’ve received so much spam on SMS related to the election here in Israel that it made that channel useless. I am sure I am not the only one and that this isn’t only in Israel.

SMS is being marketed to marketers as the channel that gets the highest attention rate from the spammed audience. What it gets is the highest deliverability - maybe. Definitely not the highest attention. This makes SMS great for transactional messages but I am not sure how good it is for sales or marketing promotions if done in the current stupid carpet-bombing tactics.

How does omnichannel change that? It doesn’t. But the social networks that act as channels treat their users better than carriers, which means they are guarding the entry to their garden from sales people and marketers, trying to bake the rules of permission marketing into the engagement. This is done by things like manually approving message templates, not letting businesses send unsolicited messages, forcing identity on the sender, allowing users to mark crap they receive as spam, etc.

It does one more thing - it brings the game into a new field which is murkier than SMS today. There are many channels already, with a promise of more channels to come in the future. Will you develop it on your own or rely on a third party CPaaS vendor for that? Most will choose the CPaaS vendor approach.

Timing is also good. Social networks are opening up their APIs, letting CPaaS vendors (and other vendors) access to their users, in an effort to enhance their usefulness to their users and to have more monetization options on their platform. They are doing that while trying really hard not to piss off their users, so spam levels are low and will be kept that way for years to come.

Omnichannel is the leading force of future CPaaS growth. This is where most invest their focus on, and where there’s an easy path for migrating SMS revenue/engagement from.

Email

Email was always shunned from. Akin to fax. A relic of a bad past.

But it isn’t.

Most of my business revolves around the ability to reach people via email. And it mostly works for me (don’t like my content? unsubscribe).

It isn’t a replacement for SMS messages. Not really. But it has many uses of its own. Especially if you factor omnichannel. Businesses need to communicate with their customers and prospects, and doing that only over SMS or WhatsApp is a limited worldview. There’s email as well.

Some CPaaS platforms already had email integrations and capabilities to some extent. Twilio has taken it to a whole new level with the acquisition of SendGrid. Did Twilio decide on this acquisition to increase their bottom line and appeal to Wall Street? Were they after an operation with less costs attached to it to increase their revenue per share? Was it a genuine strategic move towards email?

Doesn’t matter anymore. Email is part of the game of CPaaS. I don’t think many agree with me on that. The reason it is becoming part of CPaaS is because we need to look at communications holistically. As we head towards the enterprise with CPaaS, email is yet another channel of interaction - same as SMS, WhatsApp and others. Being better at email means answering more of the needs of an enterprise communications which means appealing more in a vendor selection process.

Email will take a bigger and more important position in CPaaS. The more omnichannel becomes the norm, the more customers will ask about Email support and capabilities.

Streaming media to third parties

We call it AI - Artificial Intelligences. If we’re not overly hyped, then ML - Machine Learning. And if we’re true to ourselves, then most of it is probably statistics, sometimes sprinkled with a bit of machine learning.

CPaaS is too generic and broad to be able to cover all possible algorithms and models. What do you want to do with that recorded voice call? Transcribe it? Translate to another language? Maybe do some emotion analysis? Find intents? Summarize? Look for action items?

Too many alternatives, with too much data to train from to get a good enough model. And then each scenario needs its own data to train for and get a specialized model to use.

The end result?

CPaaS vendors offer a few out of the box integration with popular features and frameworks. The known culprits are speech to text and text to speech. Or just connectivity to AWS or Google machine learning algorithms in this speech analytics domain.

Another approach which is gaining a lot of traction is to be able to stream the media itself to any third party - be it an on premise/proprietary machine learning model or a cloud based machine learning API. Usually over a WebSocket, but sometimes on top of other transport mechanisms.

The name of the game here? Simplicity and real time.

Enabling easy access to the media streams is key. The easier it is to access the media streams and integrate them with third parties that do machine learning the more attractive the CPaaS vendor will be moving forward.

Chatbots and voicebots

The digital transformation of enterprises is a transition that is taking now over a decade and will continue for many years to come. Part of that transition is figuring out how businesses communicate with users. Part of that communication needs to be relegated to bots.

Why?

1. Because as a business we want greater scale. The more we can automate the more we can accomplish for less price, less friction and less mistakes
2. Because users seem to prefer self service in many cases. “Empowering” users to do more by having a lot of their interactions taken care of with bots help that
3. Interaction interfaces are moving from button clicking towards voice interactions. And text is the main form of communications on social networks (I am ignoring emojis and gifs here)

I’ve written about this trend and its reasoning when reviewing the two recent acquisitions of Cisco and Vonage in this space.

There are startups focusing solely on the bots industry, which is great. But in many ways, this is part of what a CPaaS vendor can offer - enablement of communications at scale.

Some CPaaS vendors today integrate directly or indirectly with bot frameworks such as Dialogflow or have built their own bot infrastructure. Moving forward, expect to see this more.

Enabling easy creation and configuration of chatbots and voice bots will be an important feature in CPaaS. The better tooling a CPaaS vendor will have in this space, the easier it will be for him to maintain enterprise customers looking to better communicate with their users.

UCaaS and CPaaS

Acronyms might be confusing in this section and the next so follow closely (or skip altogether) :-)

UCaaS vendors are looking at CPaaS as a potential growth opportunity.

Vonage has seen that first with the acquisition of Nexmo.

Since then we’ve had Cisco acquire Tropo (and botch that one), RingCentral introducing developer APIs and 8x8 acquiring Wavecell.

There are definite synergies at the infrastructure level of UCaaS and CPaaS, though it is a bit less obvious what synergies there are on the frontend/application/business side. They do exist, but just a bit harder to see.

UCaaS vendors are adding APIs and points of integrations to their service because it makes sense. Everyone’s doin’ it in one way or another. It isn’t CPaaS but in some minor cases it can replace the need for using CPaaS.

What you don’t see, is CPaaS vendors heading towards UCaaS. Yet.

And you don’t see any successful independent UCaaS vendor using a 3rd party CPaaS vendor to operate all of its communication infrastructure. Yet.

For UCaaS, CPaaS is a growth potential. For CPaaS, UCaaS is just another use case. The lines are blurring between these two domains but not enough to matter.

CCaaS and CPaaS

Cloud contact centers take the exact opposite powerplay than UCaaS.

Many of the cloud based contact centers are using CPaaS and not their own infrastructure.

Twilio decided to build a contact center solution - Twilio Flex. In a way, it competes with some of its own customers. As successful companies grow large, they go toward adjacencies and CPaaS is an adjacency.

Will Twilio succeed with Flex? Too early to know.

Will more CPaaS vendors introduce contact center solutions? Probably not, but they are being bunched up and consolidated as larger entities - just see what Vonage and 8x8 have been doing in their acquisitions.

Twilio Flex is a singular occurrence. The norm would be other larger communication players who have CCaaS, acquiring smaller CPaaS players. The end result? A blurring of the lines between the various communication vendors.

For Twilio, Flex might be just the beginning. If this bet succeeds, Twilio will find the appetite to look at other adjacent enterprise applications it could build or acquire and make its own.

M2M / IOT

This. isn’t. part. of. CPaaS.

Or is it?

I’ll start by splitting this one into two areas:

1. M2M (cellular stuff)
2. IOT (messaging between devices)

M2M - Wireless

Twilio has their Programmable Wireless offering, which at its core is a modern M2M solution (for me M2M and IOT are one and the same).

In this domain, communication is needed between devices. Less human intervention for the most part, so some of the requirements are different.

But this is still communications.

CPaaS will redefine M2M/IOT as one of the use cases it covers. I don’t see a reason why CPaaS vendors wouldn’t take that route in an effort to grow their product line horizontally.

IOT - serverless infrastructure for real-time messaging

I tried to find a name for this subdomain and settled on what vendors like PubNub, Pusher and Ably end up with (or something in-between). There’s a set of vendors offering a kind of general purpose managed messaging that developers can use when they build their apps.

These vendors are settling on something like serverless infrastructure for real-time messaging as a name.

Serverless because it sounds modern, advanced and cool (marketing asked for that).

Infrastructure because this is what they have.

Real-time messaging because this is what they do.

How is that related to CPaaS? It doesn’t directly. Because no CPaaS vendor offers a “serverless infrastructure for real-time messaging”.

Here’s a surprising thing.

All of the CPaaS vendors who support WebRTC have a global backend real-time messaging infrastructure already. It is used to drive signaling across the network.

It might be more centralized. It might be slightly slower. It might be simplistic.

But at the end of the day - it is a serverless infrastructure for real-time messaging.

These CPaaS vendors can slap an API on top of that infrastructure and offer that as yet another distinct service. And they will. Either by inhouse development or through acquisitions.

Serverless infrastructure for real-time messaging will be wrapped into CPaaS.

Cloud native, no hybrid

There were attempts in the past by CPaaS vendors to offer both cloud and on premise alternatives.

Some are probably doing it still.

The vendors that see more growth though are cloud native and offer no on premise alternative.

Things aren’t going to change here.

The future of CPaaS is cloud. Hybrid is a nice idea, but until cloud vendors themselves don’t offer an easy (and cost effective) path towards that goal, the hybrid model makes less sense - it becomes too expensive to develop and maintain.

Measurements and SLAs

Quality across vendors, carriers, networks, infrastructures, time of day, day of the week or any other parameter you wish to use is variable at best. CPaaS vendors are “supposed” to handle that. They track and optimize media quality and connectivity across their services. They strive to maintain high uptime and reliability. Some even use quality as reasons for opting for their service.

At some point, TokBox and Twilio started offering quality measurement tools. TokBox introduced Inspector, a way for its users to troubleshoot network issues of recent sessions. Twilio launched Voice Insights, offering its users a quality dashboard of the calls conducted through its service.

A similar aspect is the use of SLAs as part of the service - a binding of what type of service expectations the customer should expect and what happens when the expectation isn’t met. These apply mostly to enterprise plans of some of the CPaaS vendors.

Why am I mentioning it here? Because it see it happening. It is what got Talkdesk to pick testRTC for a network testing tool (I am a co-founder at testRTC). It is also an issue that causes a lot of challenges to customers - understanding the quality their own users experience.

Measurement and SLAs will take bigger roles in customer’s buying decision making. As the market evolves and matures, expect to see more of these capabilities crop up in CPaaS offerings. It will happen due to pressure from competitors but more likely due to pressure from enterprise customers.

Vying towards the Programmable Enterprise

We’re shifting from on premise to the cloud. From analog to digital. From siloed solutions towards highly integrated ones. This migration changes the requirements of the enterprise and the types of tools it would require.

I think we will end up with the Programmable Enterprise. One where the software used is highly integratable. Many of these early trends we now see in CPaaS will trickle and find their way across all enterprise software.