Another One Bites the Dust: Tropo Closes its Doors to New Customers

It seems like we’re in an ongoing roller coaster when it comes to CPaaS. Tropo has just closed its doors. At least if you want to be a new customer (which is doubtful at best at this point in time).

Tropo and Cisco - Where it all started?

Two years ago (give or take a month), Cisco acquired Tropo. I’ve written about it at the time, trying to figure out what will Cisco focus on when it comes to Tropo’s roadmap. I guess I was quite wrong in where I saw this headed and where it went to… The two questions I did ask in that article that were probably the most important were:

Will developers be attracted to Tropo or will they look for their solution elsewhere? Was this acquisition about the technology? Was it about the existing customer base? Was it about the developer ecosystem?

We’ve got an answer to the first question - they went elsewhere. If this was a growing business, then developers would be attracted, but it wasn’t. Looking back at my recent update to my WebRTC API report, it made perfect sense that this will be shut down soon enough. Just look at the investment made by Tropo and then Cisco into the platform: Nothing serious was done for developers on the WebRTC part of the platform since September 2014, and then after the acquisition, focus of the Tropo developers went to Cisco Spark. This answers my second question - this wasn’t about technology or customers or even the existing developer ecosystem of Tropo. It was about the developers of Tropo and their understanding of developer ecosystems. It was about talent acquisition for Cisco Spark. Why kill the running business that is Tropo? I really don’t know or understand. I also fail to see how such a signal can be a good one to developers who plan on using other Cisco APIs. When an API vendor (CPaaS, WebRTC or other) discontinues its APIs or stops investing in developers. What message does it send? I don’t know what was the rationale of Cisco to acquire Tropo in the first place. If all they wanted was the talent, then this seems like too big of a deal to make. If it was for the platform, then they sure didn’t invest in it the needed resources to make it grow and flourish. Now, here’s why I think this move took place, and it probably happened at around the time of the acquisition and in parallel to it.

UCaaS or CPaaS? The Shifting Focus

We’ve got two worlds in a collision course. UCaaS - Unified Communications as a Service - the “modern” day voice and video communications sold to enterprises. CPaaS - Cloud Communications as a Service - the APIs used by developers to embed communications into their products. UCaaS has a problem. Its problem is that it always saw the world in monochrome. If you were an organization, then ALL of your communication needs get met by UCaaS (or UC, or convergence or whatever name it had before). And it worked. Up to a point. Go to most UC or UCaaS vendors’ websites and look at their solutions or industries section. The screenshot above was taken from Polycom’s homepage (couldn’t find one on Cisco since their move to Cisco Spark). Now, notice the industries? Education, Healthcare, … All of these industries are now shifting focus. Many of the solutions found in these industries that used to go to expensive UC vendors are now going to niche vendors offering solutions specifically for these niches. And they are doing it by way of WebRTC. Here are a few examples from interviews I’ve had done over the years on this site:

• Financial Services - BancSpace
• Healthcare - Regroup Therapy
• Healthcare - TruClinic

You’ll even find some of these as distinct verticals in my updated WebRTC for Business People free report. The result? The UCaaS market is shrinking because of WebRTC and CPaaS. Why is this happening? Three reasons that come to play here:

1. Cloud. And the availability of CPaaS to build whatever it is that I want
2. WebRTC (and CPaaS), that is downsizing this thing we call communications from from a service into a feature - something to be embedded in other services
3. The rise of the gig economy. In many cases, a business is offering communications not between its employees at all, but rather between its users. Think Uber - drivers and riders. Airbnb - hosts and travelers. Upwork - employers and freelancers.

With the rising popularity of the dominant CPaaS vendors, there’s a threat to UCaaS: at the end of the day, UCaaS is just a single example of a service that can be developed using CPaaS. And you start to see a few entrepreneurs actually trying to build UCaaS on top of CPaaS vendors. If I had to draw the relationship here, I’d do it in this way probably: Just the opposite of what UC vendors have imagined in the last two decades. And a really worrying possibility of how the future may look like. What should a UCaaS vendor do in such a case? Add APIs! So now UCaaS vendors are trying to add APIs to serve as their CPaaS layer on top of their existing business. Most of them do it with the intent of making sure their UCaaS customers just don’t go elsewhere for communications. Think of a bank that has an internal UCaaS deployment. He now wants to build a contact center. He has 3 ways of doing that:

1. Go to a contact center vendor. Probably a cloud based one - CCaaS
2. Build something using CPaaS. By himself. Using external developers. Or just someone that is already integrated with CPaaS
3. Try and do something with his UCaaS vendor

If (3) happens, then great. If (1) happens, then it is fine, assuming the UCaaS vendor offers contact center capabilities as well. And if he doesn’t, then there’s at least a very high probability that there’s no real competition between him and that CCaaS vendor If (2) happens… well… that can be a threat in the long run. And did we talk about Uber, Upwork and Airbnb? Yes. They have internal communications between their employees. Maybe there’s some UCaaS in there. But most of the communications generated by these companies don’t even involve their employees - only their customers and users. Where the hell do you fit UCaaS in there? The APIs are there as a moat against the CPaaS vendors. Which is just where Cisco decided to place Tropo. As Cisco’s moat for its UCaaS offering - Cisco Spark. The Tropo team are there to make sure the APIs are approachable and create the buzz and developer ecosystem around it. Quite an expensive moat if the end result was just killing Tropo in the process (the asset that was acquired).

The Surprise Announcement

Last week, Tropo had a blog post published on their site and had it removed after a few hours. Since Tropo publish the full post content into their RSS, and Feedly grabs the content and has it archived, the information in that post was not lost. I copied it from Feedly and placed it in a shared Google Doc - you can find it here. The post is no longer on Tropo’s website. A few reasons why this may be:

• Someone higher up probably decided to do this quietly by contacting the most active customers only
• The post was published too early, and Cisco wanted to break the news a bit later
• The post got too many queries from angry developers, so they took it down, until they rewrite it to a more positive note

That last one is what I think is the real reason. And that’s because after reading it more than once, I still find it rather confusing and not really clear. This announcement from Tropo has two parts to it:

1. We’ve got your back with our great Cisco Spark commitment to developers (an API portal, a marketplace, ambassadors program and an innovation fund)
2. Tropo is dead if you aren’t on to Cisco Spark. But we will honor our SLA terms (because we must)

That first part is about CPaaS serving UCaaS. Cisco Spark is UCaaS with a layer of APIs that Cisco is now trying to grow. It is also about damage control - if you’re a Tropo user, then this whole acquisition thing by Cisco probably ended bad for you. So they want to remind you about the alternatives they now offer. The second part is about how they see current Tropo developers:

• If you want to onboard to Tropo as a new customer, then tough luck. Doors are closed. Go elsewhere. Or go enroll to the Cisco Spark ISV Program
• If you are just trying the system out and have an account in there that has no apps in production environment (i.e - you are a freeloader and not a paying customer) - you will be thrown out, no questions asked
• If you are an existing paying customer running in production, then Tropo “will honor all contractual obligations”

This reads to me like the acquisition of AddLive by Snapchat. First, the service was acquired and closed its doors to new customers. It honored existing contracts. And it shut down its platform to all existing customers this year - once all contracts have ended. So -

1. Don’t expect Tropo to renew existing paying contracts
2. Expect Cisco to push paying Tropo customers to Cisco Spark instead
3. Tropo won’t add new features, and the existing ones, including any support to them will deteriorate, but will still fit into the SLA they have in place

Where Will Tropo Customers Go?

Tropo was predominantly about voice and SMS. It was also the biggest competitor of Twilio some 6-7 years ago, when both with comparable in size and focus. Or at least until Tropo shifted its focus from developers to carriers. There are two places where Tropo customers can go:

1. Cisco Spark. I think this won’t happen in droves. Some will be headed there, but most will probably go look for a different home
2. Other CPaaS vendors. Mostly Twilio, but some will go to Nexmo, Plivo or Sinch. Maybe even TeleSign

The big winner here is Twilio. The big losers are the developers who put their fate in Tropo.

CPaaS: Buyers Beware

As I always say, the CPaaS market is a buyers beware one. Developers can and should use CPaaS to build their applications. It will reduce a lot of the upfront costs and the risks involved in starting a new initiative. It gives you the ability to explore an idea, fine tuning and tweaking it until you find the right path in the market. But it comes at a price. And I don’t mean the money you need to put in order to use CPaaS. I mean the risk involved in the fluidity of this market. The trick then, is to pick a CPaaS vendor that doesn’t only fit your feature requirements, but is also here to stay. And it is hard to do that. Large companies are not necessarily the right approach - Cisco/Tropo as an example. Or AT&T shutting down its WebRTC APIs. Small startups aren’t necessarily the answer either - they might shut down or pivot. SightCall pivoted. OpenClove has silently closed doors. Dominant players might not be a viable alternative - if you consider Tropo such a player, and Cisco as a sure bet of an acquirer - and where it now ended. You can reduce these risks if you know who these CPaaS vendors are and where they are headed. If you follow them for quite some time and understand if and what they are investing on. And if you need help with that, just follow my blog or contact me.