Twilio Signal 2019 was all about contact centers and legendary customer engagement. And then some.
This one is going to be long. There’s just a lot of ground to cover…
Twilio Signal is the biggest event of the programmable communications industry. I had the opportunity to join the first one and have been covering these events ever since – mostly remotely but also in person. This time, I had to do it remotely 🙁
I took the time last week to sit down for the two hours needed to watch the first day’s keynote and a few more hours thinking and reading about the event everywhere I could.
If you haven’t seen the event already, but CPaaS and programmable communications is of interest to you, then I warmly suggest you take the time to sit down and view the keynote:
From here on, I’ll try to explain my thoughts about the keynote and the new announcements in it.
The main theme?
Seriously. Jeff Lawson, CEO and co-founder of Twilio, and other Twilions brought on stage made certain they mention that number 160,000.
I’ll have more on numbers later, but this is something that Jeff and Twilio really wanted you to remember. That they are the biggest and baddest vendor offering programmable communications.
The real theme though was Legendary Customer Engagement:
It came up some 35 minutes into the event and set the pace for many of the scope, context and announcements that Twilio wanted to make at Signal.
“Legendary Customer Engagement” translates into a focus is on contact center use cases in 2019. Or is it the other way around?
Anyways, here’s what Twilio had in store for us in the keynote:
If you ask me, Flex dictated that focus. SendGrid gave it the marketing tint it was missing, but seemed it was there mostly as lip service. More on that later.
In the two hours of the keynote, Twilio tried to cover a lot of territory. A lot is going on for Twilio in a year to be able to cover it all. My coverage will be based on these announcements more than on the actual flow and topics dictated by the keynote. I’ll keep most of the coverage in the order that it was presented at the keynote.
Twilio by the numbers
This year, Twilio took the Moscone Center in San Francisco, the largest conferences building in town, to be able to fit all the visitors it wanted to cater for. I am assuming that meant doubling the number of visitors than the previous year.
Two main numbers were important to Twilio: Developers and Customers
That said, I’ll start in the reverse order of what Jeff shared… putting it in the order of interest to me.
Here’s what got shared later on during the metrics section of the keynote:
- 750B human interactions / year
- 32,500 calls / minute
- 13,000 peak SMS / second (double than last year)
- 2.8B unique phone numbers / year (dialed in or out)
- 3B email addresses / quarter (in and out)
Twilio. Is. Big
But big where? And in what way?
Twilio were interested in showing peak traffic and not traffic totals.
What does 750B human interactions mean exactly?
We got the calls per minute at peak or maximum – a really impressive stat, but what’s the average? How about calls per day or month or year? And while we’re at it, how many of these calls are short or long? What’s the average call length on the Twilio platform?
Peak SMS is nice, but again, where are we with average? With total? The number shows the ability to scale more than actual scale.
Phone numbers and email addresses show touch points, but less amount of traffic. That part was definitely missing from the numbers. I wonder why.
That’s the number of companies that use Twilio. How many of them actively use it and how many “forgot” a number they acquired and happen to pay a dollar a month out of credits on Twilio? I don’t know. But that’s a really big number.
I wonder how many of these are above $100/month customers. How many are really large customers. These would be the relevant/interesting ones.
6 Million Developers
Jeff started strong, revealing the number of developers using Twilio are 6 million. More accurately, though, this would be registered accounts. I have 2-3 accounts on the Twilio platform myself.
As big as this number is, it isn’t interesting. Not really.
When you look at mature platforms, they stop talking about registrations and start talking about engagement. That’s why most messaging platforms switched to revealing their Monthly Active Users (MAU), some going as far as daily active users. The idea being that people don’t care how many people are on the platform but rather how many are actively using it.
Twilio can definitely do the same today, and change the way CPaaS vendors flaunt their growth – I’d be surprised if anyone comes near to their size today.
Why? 160,000 customers 🙂
As Twilio is moving toward the enterprise for a few years now, they have been beefing up security, adding an enterprise plan, user roles, etc.
What comes next is compliance.
The part that Jeff Lawson mentioned and wanted to share was support for HIPAA compliance across Twilio’s product lines. This is coming in 2020, and will probably start with one or two products and spread from there to the rest, based on their own internal roadmap.
For those who aren’t aware of it, HIPAA is the regulation put in place in the US for patient privacy. Every and all vendors who wish to offer communication in this space must be HIPAA compliant, and to do so, if they are using a third party like Twilio or other CPaaS vendors, they need them to sign something known as BAA (Business Associate Agreement). Up until now, it wasn’t easy to get a BAA from Twilio, now it will be possible.
This announcement was kind of an aside in the keynote, done to get it out and into the open publicly on stage. It is a really important topic just not as glamorous as the rest. It wasn’t picked up by many who were covering the event. Searching Google for Twilio HIPAA gives results from 2017 but not anything from the keynote…
Twilio CLI is a command line interface to the Twilio API. Much like the Nexmo CLI or even WordPress CLI, it offers easy access for scripting scenarios without the need to “really code”. Here’s the Twilio CLI announcement.
This is a long overdue addition to Twilio. What sweetens the wait though is what this implementation includes out of the box:
- Coverage of a lot of the Twilio APIs already (maybe all of it, I am not sure)
- Plugins, which Twilio and third parties can build for the CLI and use
- Proxy capability to handle webhooks locally during development
- Ready-made templates in their documentation for the CLI
- Ability to pipe the tail of the log straight through the CLI
In order to show off the power of the CLI, they even created a kind of an online competition to make a point about it. You can watch it at the 24:30 mark in the keynote.
All in all, this is the only announcement around the Twilio developer tools, but definitely an important addition.
Up until that point at the keynote, Jeff was setting the stage. He got a few things out of the way – explained that Twilio is big by sharing numbers, shared Twilio’s diversity goals and progress, and announced Twilio CLI (because it didn’t fit in the overall theme of the event, but was hugely important to share on stage).
While getting to the communication part of it, and Twilio’s key points for 2019 and on, they had to say something about SendGrid. This was a big acquisition that was announced last year, and the intent was to show progress and cohesion.
Here’s how things went for this 20 minutes session:
Sameer Dholakia, the CEO of Twilio SendGrid came on stage. He spent most of the time explaining SendGrid, why email is important, and why this needs to be relegated to SaaS vendors.
Two things about SendGrid:
- They’re also big
- They’re APIs
That means a perfect match for Twilio.
The explanation given wasn’t really necessary for those used to using email APIs (which may seem like an obvious requirement to many developers). It was meant for the people in the room – Twilio customers – communications people who understand SMS and voice but are somewhat less conversant in the need and importance of email. Remember – most CPaaS vendors are used to explaining why carrier relations is complicated, but probably feel like sending emails should be way simpler.
Why spend all that time about SendGrid and emails? To increase the use of SendGrid by existing Twilio customers.
Sameer shared 3 new features/capabilities that SendGrid rolled out, none of them in too many words:
- Email Validation API; built around the same concepts as Twilio Verify for phone numbers. The intent here is to be able to know if an email is valid or not and with what confidence. Sending emails to invalid addresses may ruin your standing and hurt the deliverability of emails you really want to send to real people, so this can come in really handy
- Marketing campaigns; support for email sequences and the ability to send them as a campaign, which is nice. I use this in my own business by through a marketing automation vendor. This means SendGrid is starting to go up the stack and food chain as Twilio did with Studio and Flex
- Ads; ability to integrate personalized ads in emails. Another usable feature (which was in beta since last year)
All these are targeted towards marketing activities and less towards communications.
The time spent on sharing these new features? 3 minutes. Not nearly enough to grok.
10 minutes into SendGrid, the discussion came back to Twilo. And SendGrid.
The intent was to show how Twilio+SendGrid = more. This makes perfect sense, especially when shifting towards a world of multiple channels and when that world is what Twilio is pitching at Signal. It wasn’t explained in such a way, or integrated as much at this point. A kind of a missed opportunity.
It was done by sharing live code of how you can add email sending via SendGrid within an application that uses Twilio for SMS communications. It was nice. I hope Twilio will have better integration and surprises for 2020 on the Twilio+SendGrid storyline.
Dave Michels said it quite well: “Flex was a major theme of Signal 2019, and I anticipate it will be an even bigger theme at Signal 2020.”
Flex had 3 parts to it in the keynote:
- Why is Flex so great
- What have we done new in Flex since last time?
- Here’s how flexible Flex is
While the product is great from a concept point of view (and I am sure from an implementation point of view as well – never really used it myself), I think the delivery during the keynote could have been improved a bit.
1. Why is Flex so great
Here’s what Jeff said during the keynote about Flex:
“A year ago, if you’ve had told me that the legacy vendors in the space would have even heard of Flex I would have thought you were crazy. Let alone buying up all the ads around Moscone for Signal this year. I mean, isn’t that crazy? But you know what? I think they are afraid. I think they are afraid of what happens when we unleash the creative ability of millions of software developers to innovate in the contact center.”
Next, it went into positioning of Flex within the industry:
First, came the legacy vendors, who were positioned as:
- Hard to support
- Hard to maintain
- Hard to change
All true by the way.
Then came the turn of cloud contact centers in SaaS models, said to be 15% of the market now. These are “neither scalable nor flexible in the way we need […] not built for continuous improvement”.
True or not, that’s Twilio’s stance now, and it seems like they’re competing head to head with their cloud contact center customers – more verbally than last year.
For me, Flex is a great product – it shows that future enterprise products must be programmable products, ushering a new era of programmable enterprise. But that’s for some future article.
Two numbers were given for Flex:
- %500 growth in interactions
- 250 ecosystem partners
Both are somewhat meaningless without context, and there isn’t none as this product is just too new in the market.
2. What have we done new in Flex since last time?
There’s more work and focus on customer acquisition in Flex than in other products of Twilio.
We will probably see more of that in 2020 and 2021 – the same way that Amazon Connect is now winning a lot more deals and going into a lot more deployments than we’ve seen when it launched. It takes time for these products to really get adopted and integrated.
What did get into the announcements here, probably to give it some tint of progress, were the following:
- Native Zendesk CTI integration. Mentioned in a full sentence throughout the whole keynote. Blog post on this here
- Autopilot is now GA. The thing is that Autopilot is a distinct Twilio product in its own right, and it lives as a feature in Flex. The tie-in here to Flex is to show progress of Flex more than to say anything about Autopilot. More on the Autopilot announcement here
- Announced Media Streams API in beta, a brand new product for Twilio. I think this should have gotten a section of its own rather than just a mention and a minute or two wrapped inside Flex
I think Flex is now in the grueling part of getting from an MVP towards a version 1.0 that Twilio can be proud of. Once there, Twilio will definitely open the back burners and start showing a lot more product specific progress in Flex itself.
3. Here’s how flexible Flex is
That was given to Wanjun Li, Senior Software Engineer in the Flex team.
She showed a few ways in which Flex can easily be extended, adding some custom features to it. It was an eye opener to the speed at which you can modify a deployed contact center and improve it, but I am not sure how well that was conveyed to the audience.
I think Twilio has to experiment here a bit further on how to make that into a wow moment.
Media Streams API
Media Streams API is the generic approach CPaaS vendors can offer (and already offer) ML (Machine Learning) to their customers.
With AI and ML you never truly know what a customer would like to use or how:
- There are many cloud based SaaS offerings today around ML that can bring value. Which ones would your customer want to use?
- Each customer is unique, as he might want to train a model using his own unique data
- As a generic player (CPaaS), it is hard to decide what solutions to offer in the ML space
- It is still early days
The approach here is to be able to interfere within an ongoing session, collecting the media out of the session and sending it towards a machine learning algorithm for classification. That can be used to handle things like speech to text, sentiment analysis, recognition, etc.
The easiest way to integrate such a thing today? By shipping that media over a websocket towards a cloud service. Other CPaaS vendors are doing this already. Twilio has added that capability now.
Out of the box? Amazon Lex and Google speech to text engines are provided via websocket interface. This means that there’s a bit of integration work on the developer’s end to get them to work, but it also means it is a kind of an open interface that can be fit (with some effort) to virtually anything.
Gridspace was added as an exclusive launch partner with a direct integration, making it simpler to use than others. Twilio promises this will change with more partners added into the roster, which stands to reason.
I am assuming this will come to Programmable Video at some point in the future (to analyze the voice channel only but also to analyze video).
This got a really small portion of the keynote this year.
The most revealing slides about messaging
I found the following two slides the most interesting in all the keynote at Signal 2019.
In the above, Jeff indicates the reply rate Twilio customers see with the Twilio API for WhatsApp.
To me, this means the following:
- With social messaging, enterprises are actually making an effort to make it a two-way interaction and not only one-way notifications
- People are more inclined to reply over social networks (WhatsApp in this case) than they are to do the same over SMS. Why? Because we’re trained to assume companies won’t listen to us over SMS anyway
- For companies seeking true conversations with their customers, social channels are better today than carrier based channels (SMS)
The second slide was revealing about how Twilio sees things:
This was given as context to unveiling Twilio Conversations.
Here, Jeff tried to explain what is driving these programmable conversations. He did it left-to-right.
The ones mentioned were Apple Business Chat, WhatsApp and Facebook Messenger.
Somehow, Telegram, Instagram, Twitter, Viber, WeChat and all the others were ignored. Why? Because the top 3 are probably over a billion users each. They are the biggest ones. And also the ones easiest for Twilio to reach (being predominantly a US West coast company).
One I found even more interesting here is the reference to Apple Business Chat – they haven’t allowed any of the CPaaS vendors to date access to their API. Up until now, Apple’s focus with it was on chat widgets and contact center type applications. Does this give us any indication about a possible announcement in the future of Twilio as the first CPaaS vendor with Apple Business Chat? Or maybe of Apple opening up to more CPaaS vendors and Twilio being just one of them.
The other thing that caught my attention came later, when Twilio Conversations was unveiled. It doesn’t yet include support for Facebook Messenger. For social, there’s only WhatsApp. For now.
One alternative here is that Twilio is banking on Facebook merging Facebook Messenger and WhatsApp infrastructure to a point where support for WhatsApp only would win. Or simply because they saw more traction to their Twilio API for WhatsApp than they did for their support of Facebook Messenger so this got prioritized for Twilio Conversations.
In any case, the coming year or two is going to be limited in the number of social channels that Twilio will be focusing on.
For some reason, the slide includes RCS and 5G. I am not sure why 5G is there, besides trying to make the slide more appealing to the eye. Jeff might even agree with me, as he made no mention of 5G – on this slide or on any other part of the keynote.
RCS? That’s the carriers’ replacement for SMS. It has been promised in the last 20 years and with Google’s own adoption of it, it is getting more attention. Will it be deployed? I don’t know. Right now, the prospects aren’t that good.
Twilio isn’t alone here. Many CPaaS vendors made and are making announcements around RCS support.
Going back to my thoughts around WhatsApp and social, time will tell of enterprises will use RCS to “spam” customers with notifications and marketing or if they will truly try to use it for conversations. If the former happens, then conversations are better off done via social messaging platforms, leaving RCS to be the enterprise “notifications center” that SMS is today.
For Data, Jeff had AI (Artificial Intelligence). Twilio decided to go for the marketing term as opposed to the technical term (ML for Machine Learning). Makes sense. For non-technical people, they are one and the same and AI just sounds way better.
ML is happening in communications. Got a whole report around AI in RTC on that written with Chad Hart if you’re interested.
This in the context of conversations is what will allow us to optimize and scale.
Twilio Conversations was revealed as the last part of the keynote at Twilio Signal.
It is a shame that at this point, the main stage screen started fidgeting. It probably couldn’t wait to see what Twilio Conversations is about 🙂
After a long setup and explanation of how the world is headed towards multiple channels, how customers expect to be treated better, how enterprises who make an effort to strike conversations win, and how legendary customer experiences is what we should strive for, came Twilio Conversations.
This is a messaging component that handles conversations across multiple channels. Dumbing things down a bit, this is Twilio Programmable Chat does across channels and with history storage.
What does that mean?
It means that on the business side, users can use a single interface on their mobile device or in a browser to interact with customers. And that customers can use different channels to interact with the business. And all this is done as a conversation.
The result? A party.
The demo that Twilio put in place explains that conversations are messy and ever changing, and something that can assist there is Twilio Conversations.
Here’s what you get with Twilio Conversations:
- Support for multiple channels: Chat (IP messaging), SMS, MMS and WhatsApp
- Group chat, mixed with different channels
- Text, images and videos
- History storage of the conversations
Here’s where it can be improved (probably in future releases if this gets adopted):
- Multiple channels are nice. Somehow, Facebook Messenger which Twilio has support for, at least in beta
- Voice (and video) channels, as part of the conversation
- Email. They have SendGrid and decided not to use/include it in the first release of Twilio Conversations
And here’s the announcement on the Twilio blog.
Interestingly, Twilio decided not to cover pricing for Twilio Conversations during the keynote. They usually mention that for new products, at least to some extent. Checking on their website, it seems like Twilio went for a mixture of MAU+Storage approach.
You pay per Monthly Active User (count the number of users who did “something” in the last month, multiply them with the price per user). And then you pay for the storage you have inside conversations per GB. I am assuming storage is there for images and videos but might be also for text. Not written there, but also a reasonable assumption, you pay for each channel interactions separately based on their price list.
An interesting (and reasonable) choice.
Is Conversations necessary? It probably is.
As we’re moving forward with the use of CPaaS and communication APIs, there’s a need to provide ever higher abstractions, giving developers more of the tooling they need and having them write less of that tooling.
With omnichannel being hammered as the next big thing for about a decade, such tooling makes sense.
Twilio isn’t the only vendor headed in this direction either. Nexmo has their own variant, called Nexmo Conversation, somewhat hidden within their developer documentation.
As more conversation revolves around “Twilio is competing with their customers” and “Twilio is expensive”, having new constructs like Twilio Conversations makes perfect sense. It is a usable tool for customers, not competing with their own products (at least for most customers) AND it is a lot more than just SMS and voice.
If Twilio Conversations becomes a popular product for Twilio, this places many of the other CPaaS vendors yet again on the hamster wheel, playing catch-up.
There were other interesting announcements made by Twilio that weren’t introduced during the keynote itself.
Verified by Twilio
This is a different product.
It wasn’t part of the first day keynote, and all I could find is the post about it on Twilio’s blog, the press release and rehash of these two elsewhere. Not much on the product page besides an invitation to the beta program.
Here’s the problem: spam in calls. Lots of it. Most calls probably. Which is why people stopped answering their phone.
Everyone’s trying to solve that problem, each with his own concept – which I find really interesting. How the solutions proposed fit well into the DNA and thought processes of each company. This though, is for another, future article.
Twilio Verify connects between businesses who want their calls to pass through the noise of spam calls, customers who do not want to be bothered with spam and call identification apps. The deal is this one:
- A customer installs a call identification app (unrelated to Twilio)
- The call identification app integrates with Twilio (via an API obviously)
- Whenever a call comes in, the app checks with Twilio who the caller is and if the intent of the call is known. If it isn’t, it does whatever it did up until today. If Twilio has that information, then that information is shown to the customer
- The business identifies itself and its brand to Twilio, connecting that information to phone numbers
- The business can also indicate per call what the intent of that call is (or on the phone number level – that information is somewhat murky at this point)
It just needs most users to install these apps on their phones and businesses to use this new API.
Is that going to be opened to Twilio’s competitors? To the carriers themselves? Would this be adopted by Apple and Google?
Lots of questions. Great initiative.
More on the whole spam solutions space in September.
Missing at Twilio Signal 2019 keynote
A two hour keynote session is long. Twilio had to pick and choose what to talk about and what to leave aside. A few things that were left aside reveal what interests Twilio, or at least what they want to interest us with.
Here are 4 things that didn’t make it to the keynote that I felt were missing.
1. “Architecture” diagram
Every year, Jeff has shared the architecture view of the Twilio products portfolio. It was a fascinating view as to how Twilio sees its mix of products and how it thinks they fit into a customer’s thought processes.
I don’t recall if there was such a bird’s eye view for Signal 2018, but there definitely wasn’t for 2019.
Where is Twilio Conversations located compared to Authy and Notify? What about the new Media Streams APIs? How does Twilio rationalize SendGrid or simply email into the mix and within its ever-growing set of products?
If you head to the Twilio products page, you get this categorization:
- Marketing Campaigns
- Twilio Conversations
- Channels APIs
- Programmable SMS
- Programmable Voice
- Twilio SendGrid
- Programmable Chat
- Programmable Video
- Programmable Fax
- Twilio APIs for WhatsApp
- Super Network
- Phone Numbers
- Programmable Wireless
- Short Codes
- Super SIM
- Elastic SIP Trunking
Nothing on that page is visual. Just a long list of products. It is workable if you know Twilio, but feels somewhat hard for newcomers.
A few interesting things here:
- Conversations as a category under Services and Twilio Conversations as a product inside it. I am assuming marketing has debated this one a bit, trying to resolve the confusion it could bring and decided just to use the same word
- The word APIs appears only on the Channels. Services are considered higher level constructs here, even if (obviously) they are treated as APIs
- Tools includes only “Runtime”, wrapping into them things like Functions and Studio, and ignoring other free of charge tools and capabilities such as the new CLI
- Twilio Pay, Media Streams API and probably a slew of other capabilities get hidden inside the layers of products and not mentioned here at all
I think not speaking about these layers and how Twilio sees the world of communication APIs in a layered structure in their yearly keynote is a missed opportunity.
No video. Nothing.
It wasn’t mentioned at all.
Was it because it isn’t a money maker?
Was it because there was nothing new to say about it?
Was it because the progress made wasn’t important enough to fit in the keynote?
This one’s interesting.
Thinking back at the keynote, there was nothing substantial in it about voice calls. Sure, it was somehow covered as part of the Twilio CLI and Flex, but nothing more.
I am guessing that support for voice is a done deal, so no real need to say anything new about it during the keynote itself.
Closest thing to coverage at Twilio Signal 2019 around voice was the new Media Streams API and even that wasn’t covered much.
The Twilio SIM card and its M2M play wasn’t part of Signal.
The focus was Flex and human interactions. Not bots-to-bots or machines-to-machines.
I am wondering what progress and announcements could have been made.
Where is CPaaS headed?
CPaaS is complicated these days.
SMS and voice? Sure.
But is SMS and voice mandatory? Some think it is, and place the whole focus on that part.
Is video part of CPaaS? What about only video?
WhatsApp support? Other channels?
What makes a CPaaS platform well… CPaaS?
For me, it is being generic, appealing to developers and handling real time interactions (be it text, voice, video or whatever). And it also needs to somehow deal with communications between humans.
We’re at a point where CPaaS is appealing. Both for enterprises who need to improve their communications and to new entrants to the CPaaS market – either as vendors, enablers, partners, or whatnot. There’s an ecosystem building in the CPaaS space for a few years now.
Twilio is somehow managing to stay ahead of most vendors in both breadth and depth of their offering which is not an easy task.
Want to grok Twilio’s API operation?
I have partnered with Kin Lane, aka API Evangelist. I love his content which is super important for anyone dealing with APIs.
One of the things Kin Lane did recently was create an Industry Blueprint for Twilio. This is a paid-for resource but the price isn’t high and the content is top notch. Check it out, especially if you’re thinking of developing your own CPaaS, entering the CPaaS domain or just adding APIs to your communications service.
Trying to figure out CPaaS?
- Who are the players in this market?
- How do they differentiate?
- Where is the industry headed?
- Is CPaaS being commoditized?
- How do you compare to other vendors in this space?
Ping me if you want answers to any of these questions for a private consultation.