Is Twilio Redefining CPaaS?

Twilio’s Jeff Lawson had a really interesting keynote at their Signal event. I think Twilio is trying to redefine what CPaaS is. If this works for them, it will make it doubly hard for their competitors.

This is going to be long, as the keynote was long and packed full with information and details that pave the road to what CPaaS is going to be in 2020.

Speaking of 2020... check out my Twilio Signal 2020 virtual event coverage.

I suggest you watch this keynote yourself -

https://www.youtube.com/watch?v=6Upr_PRm3dI

What I loved the most? The beginning, where Jeff refers to code as making art. I have to agree. In my developer days, that was the feeling. Coding was like building with lego bricks without the instructions or sitting down to paint on T-shirts (yes - I did that in my youth). When a CEO of a company talks about coding as art and you see he truly believes it - you know that what that company is doing must be… art.

Before we Begin

One term you didn’t hear at the keynote:

CPaaS

One term that was there every other slide:

This was about developers, who is the buyer and how software APIs are everywhere.

It was also about how CPaaS is changing and Twilio is now much bigger than that - in the traditional sense of what CPaaS means.

It wasn’t said out loud, but the low level APIs that everyone are haggling about - SMS and voice - are nice, but not where the future lies.

Twilio by the Numbers

The numbers game was reserved for the first 13 minutes of the keynote, where Jeff asserted Twilio’s distinct leadership in this market:

• 28 billion interactions (a year)
• 70 countries (numbers in) today; plan to grow to numbers in a 100 countries “by this summer”
• Over 900 employees; Over 400 in R&D
• 30,000 annual deployments (the number of times a year Twilio is introducing new releases… in a continuous delivery mechanism to an operational cloud service) - this enables shipping faster with less mistakes. The result? 3.5 days between new product or feature launch
• 1.6 million developer accounts on Twilio; 600,000 new accounts in the past year; doubling YoY
• 99.999% API availability - and 99.999% success rate
• 0 APIs killed

More about the two last bullets later.

Here’s what Twilio deployed in the past year:

To me, this is becoming hard to follow and grasp, especially when I need to look at other vendors as well.

If you look at it, you’ll see that Twilio has been working hard in multiple vectors. The main ones are Enterprise, IP communications and “legacy” telephony.

The main messages?

1. Twilio is the largest player in the communication API space
2. Twilio is stable and solid for the enterprise
3. Twilio is globally available and rapidly expanding to new countries
4. Twilio is fast to introduce new features

All this boils down to stating that a competitive advantage can be best achieved on top of Twilio.

Twilio’s New Layering Model

If you’ve been watching this space, you might have noticed that I tend to use this model to explain CPaaS feature sets:

And this is how Jeff explained it on stage in Twilio’s Signal event 2016:

Building blocks. Unrelated. Could have been placed horizontally one next to the other to get the same concept. But piling them on top of each other is great - it shows there’s lots and lots of services and features to use.

2017 brings with it a change in the paradigm and a new layers model that Jeff explained, and was later expanded with more details:

The funny thing is that this reminded me of how we explained the portfolio and API layers in our VoIP products at RADVISION more than 10 years ago. It is great to see how this translates well when shifting from on premise APIs to cloud APIs. But I digress.

Back to the layering model.

The Super Network wasn’t given much thought in this time around. There were announcements and improvements in this area, but these are a given by now. For those who wish to outmaneuver Twilio by offering a better network - that’s going to be tough without the layers above it.

Then there’s the Programmable Communications Cloud, which is where most of the CPaaS vendors are. This is what I drawn as my own perspective of CPaaS services. The names have changed a bit for the Twilio’s services - we’ve got Programmable Chat now instead of IP Messaging. SMS has 3 separate building blocks here instead of one, and the baseline one is called Programmable SMS - keeping the lower level Communications APIs with a nice naming convention of Programmable X.

The interesting part of this story comes in the Engagement Cloud. Jeff made a point of explaining the three aspects of it: Systems, Departments and Individuals. And the thing about the Engagement Cloud is that services there are actually best practices - they aren’t “functional” in their nature. So Twilio are referring to the APIs in this layer as Declarative APIs.

The Engagement Cloud

The main difference between what’s in the Engagement Cloud and the Programmable Communications Cloud? In the Programmable Communications Cloud you know as a developer what will happen - you ask to send an SMS and the SMS is sent. With the Engagement Cloud, you ask for a message to reach someone - and you don’t really care how it is done - just that it will be done in any channel that fits best.

No Channel To Rule Them All

What is that “any channel that fits best”?

That’s based on what Twilio decides in the modules they offer in the Engagement Cloud, and it is where the words “best practices” were used during the event.

Best practices are powerful. As a supplier, they show you know the business of your customer to a point where you can assist him more than just by giving him the thing that he think he needs. It places you often as a trusted advisor, or one to go to in order to decide what it is you are going to do. After all - you own the best practices, so why not follow them?

It is also where the most value is to be made moving forward.

SMS is probably still kind when it comes to revenue in CPaaS. Not only for Twilio, but for all players in the market. And while this is nice and true, it is also a real threat to them all:

Yes. SMS is growing in use.

Yes. The stupid term A2P (Application 2 Person) is growing rapidly and it is done using SMS.

Yes. People prefer that over installing apps, receiving emails and getting push notifications.

Yes. People do read SMS messages. But I am not sure if they trust them.

Here’s a quick story for you.

Airbnb.

I use them once in awhile. I was just planning a trip with the family for July. Found the dates. Booked the flights. Found an Airbnb to stay at. Reserved a place - and was asked if I am cool with push notifications. I clicked yes. And here’s what I got the next moment on my phone:

Businesses might be recommended to use SMS to reach their customers, but the prices of SMS urges businesses to seek other, cheaper channels of communications at the same time.

There is no money to be had in Communications APIs in the long term.

There is already a price war at this level. Vendors trying to be “cheaper than X”. Developers complaining about the high prices of CPaaS, not understanding the real costs of developing and maintaining such systems.

What’s in Twilio’s Engagement Cloud

Which is where the Engagement Cloud comes - or more accurately - the best practices and smarts on top of just calling communications APIs.

Twilio are now offering 4 APIs in that domain:

1. Authy - handling authentication type scenarios, including but not limited to the classic 2FA
2. Notify - a notification service from applications and services to users. It started as SMS, continued with the addition of push notifications, but now supports multiple channels
3. TaskRouter - a way to connect incoming tasks with workers who can handle them. Can be used to build queuing systems in contact centers
4. Proxy - a mechanism to send connect between people in two separate groups - riders and drivers for example. Suitable for the sharing economy or when the “agents” aren’t “employees” or are loosely “controlled” by the organization

Omnichannel

The interesting bit here is that these all started as functional building blocks. But now the stories behind them are all about multi-channel.

SMS is great, but it isn’t the answer.

IP messaging is great, but it isn’t the answer.

Facebook messenger with its billion+ users is great, but it isn’t the answer.

XKCD says it best:

With such a model in which we live in, programmable communications need to be able to keep track of the best means to reach a person. And so Twilio’s Engagement Cloud is about becoming Omnichannel (=everywhere) with the smarts needed to pick and choose the best channel per interaction.

Are we there yet with the current Twilio offering? I don’t know. But the positioning, intent, roadmap and vision is crystal clear. And with Twilio’s current speed of execution, it is going to happen sooner rather than later.

Vendor Lock-in

The great thing about this layer of Engagement Cloud for Twilio is that it is going to be hard to replace once you start using it.

How hard is it to replace an API that sends out an SMS to a phone number with another API that does the same? Not much.

But how hard is it to replace best practices wrapped inside an API that decides what to do on its own based on context? Harder. And getting even more so as time goes by and that piece of module gets smarter.

Twilio gets a better handle on its customers with the Engagement Cloud. It makes it a lot harder for developers to go for a multi-vendors strategy where they use SMS from the CPaaS vendor whose price is the lowest.

Developer’s Benefits

Why would developers use these Engagement Cloud modules from Twilio?

Because they save them a ton of time and even a lot more in headaches.

Today, there are 3 huge benefits for developers:

1. Logic - the logic in these modules is one you get for “free” here. No need to write it on your own and make the decisions on your own
2. Best practices - I know that your contact center is unique, but it probably adheres to similar queuing mechanisms as all the rest. You end up using similar/same best practices as others in your domain, and having these already pre-built is great. Maybe you can even improve your own business simply by using best practices and not do it alone
3. Multiple vendors - adding channels means figuring out the APIs and craziness of multiple providers. No fun. You get a single API to rule them all. What’s not to like?

These areas are usually those that developers usually don’t like to deal with. That third one especially is a real pain - after you did it for 2 vendors/channels - connected it to SMS and maybe Facebook Messenger, it feels boring to add the next channel. But now you don’t have to anymore. And don’t you get me started with how the APIs there deprecated and changed through time.

Machine Learning and its CPaaS Role

Twilio talked about Machine Learning in two new APIs that it is introducing: Speech Recognition and Understand

The Speech Recognition one is a bit less interesting. It is done in partnership with Google, using Google’s engine for it. The smarts on Twilio’s side here is the integration and how they are stitching these capabilities of text to speech throughout their line of products.

Here what Twilio is doing is acting in the most Twilio-like approach - instead of developing its own speech recognition tech, or using a 3rd party that gets installed on premise, it decided to partner with Google and user their cloud based speech recognition technology. And then making it easier for developers to consume as part of the bigger Twilio offering.

The real story lies elsewhere though - in Twilio Understand.

While Speech Recognition is a functional piece where you feed the machine with voice and get text, Understand is about modeling your use case and then having the machine parse text based on that model.

It is also where Twilio seems to have gone it alone (or embedded a third party internally), building its real first customer-facing Machine Learning based product.

In the past few years we’ve seen huge growth in this space. It started with Big Data, turned Analytics, turned Real Time Analytics, turned Decision Engines, turned Machine Learning.

Companies use this type of capabilities in many ways. Mostly internally, where Twilio probably had been doing that already. But embedding machine learning and big data, making products smarter is where we’re headed. And for me, this is the first instance I’ve seen by a CPaaS vendor taking this route.

It is still a small step, as Understand is another piece of API - a module - that you can use. And just like many of Twilio’s other APIs, you can use it as a building block integrated with its other building blocks. It is a move in the right direction to evolving into something much bigger.

LinkedIn shows that Twilio has several data scientists (the man power you need for such tasks), though none of them was “kind enough” to offer details of his role or doings at Twilio :-)

Moving forward, I’d expect Twilio to hire several more people in that domain, beefing up its chops and starting to offer these capabilities elsewhere.

The only competitor at the moment who is seeing that is Cisco Spark - with their recent acquisition of MindMeld.

The great thing about machine learning? People feel and assume that it is super hard. Which means it is worth paying for.

The Enterprise

Here’s where enterprises find a home at Twilio’s Signal 2017 keynote. Best to just show it in slides:

Twilio’s API calls success rate. This goes on top of its 99.999% API availability and this is where Jeff wants you to focus - not on getting an API returning an error (would would still fall under availability) but rather on how many successful results you get from the APIs.

Since Twilio launched, none of its APIs was ever deprecated or killed (haven’t checked it myself but this is what Jeff wants you to remember).

Twilio has been working hard on reaching out to enterprises. It introduced an Enterprise plan last year. Implemented ISO 2700. Added Public Key Validation. Introduced support for Enterprise SSO.

All these are great, but what I think resonates here the most are the above two items.

99.999% Success Rate

Enterprises LOVE this.

SLAs. Guarantees. All the rage.

Twilio is operating at 99.999% uptime and is happy to offer a 99.99% guarantee in its enterprise SLA:

For an enterprise to go for Twilio requires two leaps of faith:

1. Leaping from on premise to the cloud. Yes. I am told everyone’s migrating to the cloud, but this is still painful
2. Picking Twilio as its vendor of choice and not its natural enterprise vendors (known as ISVs)

When you pick Twilio, who’s giving you any guarantees?

Well… Twilio does. At 99.99% while maintaining 99.999% across all of its services to all of its customers.

That’s a powerful message. Especially if you couple it with 30,000 deployments a year.

0 APIs Killed

This one is REALLY interesting.

In the world of APIs where everything is in the cloud with a single copy running (it isn’t, but bear with me a second), having someone say that they offer backward compatibility to all of their APIs is huge.

The number of changes you usually need to follow with APIs on the internet is huge. If you have a product using third party APIs, then every year or two, you need to make some changes to have it continue to work properly - because the APIs you use change.

0 APIs kills means that if an enterprise writes their code today for a project they have, it won’t need to worry about changes to it due to Twilio. Now, in many cases, enterprises develop a project, launch it and then are happy to continue with it as is without further investment (or budget). Which means that this kind of a soft guarantee is important.

How does Twilio do it?

They launch products in beta and run the beta for long periods of time. During that time, they get developers to use and tinker with the APIs, collect feedback and when they feel ready, they officially launch it - at which point the API is deemed stable.

It works well because Twilio has lots and lots of customers, some willing to jump on new offerings and take the risk of having things break a bit during those beta periods.

The end result? 0 APIs killed.

Will it Blend?

I believe it will.

Twilio has introduced a new paradigm for the way it is layering its product offerings.

In the process, it repositioned all of its higher level APIs as the Engagement Cloud. It stitched these APIs to use its lower Programmable Communications APIs, adding business logic and best practices. And it is now looking into machine learning as well.

It is a powerful package with nothing comparable on the market.

Twilio are the best of suite approach of CPaaS - offering the largest breadth of support across this space. And it is making sure to offer powerful building blocks to make developers think twice before going for an alternative.

Twilio isn’t for everyone. And other CPaaS vendors do have their place. But increasingly, these places become niches.

Is there more?

Yes.

This analysis is long, but by no means full.

There were a lot of other aspects of the announcements and Twilio’s moves that require more thought and details. The pricing model on group Programmable Video is one of them. Third Party Add Ons in certain domains (especially for analytics) is another. Or Twilio heading into the UI layer. And then there’s serverless via Twilio Functions. This isn’t even an exhaustive list...

I won’t be going into these here, but these are things that I am actively looking at.

Contact me if you are interested in understanding more about this space.