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

June 26, 2017

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).

Looking for the public announcement that got deleted? You can find it here

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:

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.


You may also like

Comment

Your email address will not be published. Required fields are marked

  1. One strong long term option is moving to open source stack from Tropo or other CPaaS products. Open source (OS) never goes out of business and the OS ecosystem for WebRTC/SIP and related is ready for prime time. Just my 2 cents. – Shawn

  2. Great article Tsahi. Anyone who is a current customer or considering Tropo should take a look at Aculab Cloud. We have been in the telephony game for over 35 years and continue to invest in enhancing the capabilities of our cloud platform. Looking forward to following your blog.

  3. Great article Tsahi!
    I also believe the OS is going to win this game eventually as it always did.
    So, another advice to UCaaS vendors could be – open the source code!

    1. Igor,

      I get the feeling we’re not reading the map the same way.

      Open source is great, but it is no business model.

      Based on your train of thought, there’s no room for AWS either, because AWS isn’t open source. Somehow… I don’t think it holds water.

      UCaaS and CPaaS both fill a real need in the market. And it is one about managed solutions around communications.

  4. I second the Aculab Cloud choice. As a dependable and sustainable company you can not beat Aculab. I was a customer long before they began offering cloud services. They do a great job. They are at worth checking out.

    I do not work for the company and I was not solicited to make this post… I just know the pain of investing years of development into a platform then a big company pulls the rug out from under you (TI Speech Development). We picked Aculab after a path of three other companies, we had beein a Dialogic customer for year and it was great until Intel bought them and well think Tropo/Cisco and you know why we ended up at Aculab. Best business platform/company decision we have made.

    1. Well…

      3 unsolicited comments. On the same article. In favor of the same company. From 3 different people. Who are first time commentators.

      Call me a skeptic.

      Anyway, thanks for sharing.

  5. Just stumbled upon this very well researched article, thanks Tsahi!
    (and congratulations on capturing the Tropo end-of-life notice before it disappeared).

    I completely agree with the trend towards webRTC and APIs disrupting traditional UCaaS.

    I would like to point out an update to a company covered in your report. It is about a legitimate alternative to Tropo called Voxeet True Voice. Voxeet delivers high quality spatial sound, HD video and encryption and its API platform illustrates the point you are making in this post.

    Voxeet was already a Gartner Cool Vendor
    and it was named the 2017 Hot Vendor for Unified Communications and Collaboration by Aragon Research on the very same day you published your post (June 26).

    I hope that helps!
    More on the Voxeet API SDK

  6. Just stumbled on this yesterday after searching to find info about Cisco’s commitment to Tropo. Guess I found my answer.

    I’ve had a development account for quite a while, but just played with it – never developed anything real. But recently I decided I want to stop paying for my home landline, so got the idea to port my number (which is tied to many accounts) to Tropo. As I was working on creating a simple app to forward to my cell, the Tropo-supplied number stopped working – getting a busy signal. Dropped that number and got a new one – still getting busy. Guess I now what’s going on. Nothing communicated from Tropo about it.

    It’s a shame, because from what I’ve seen Tropo’s APIs are more capable than the other platforms I’ve looked at, and I really like their Groovy scripting support.

    For example, Twilio has 3 voices – male, female, and “alice”. Here are just the *English* language voices Tropo supports:

    def voices = [
    [‘Karen’, ‘Austrailian’],
    [‘Lee’, ‘Austrailian’],
    [‘Veena’, ‘Indian’],
    [‘Moira’, ‘Irish’],
    [‘Fiona’, ‘Scottish’],
    [‘Tessa’, ‘South African’],
    [‘Kate’, ‘UK’],
    [‘Serena’, ‘UK’],
    [‘Daniel’, ‘UK’]
    [‘Oliver’, ‘UK’],
    [‘Allison’, ‘USA’],
    [‘Ava’, ‘USA’],
    [‘Evelyn’, ‘USA’],
    [‘Samantha’, ‘USA’],
    [‘Susan’, ‘USA’],
    [‘Zoe’, ‘USA’],
    [‘Tom’, ‘USA’],
    [‘Victor’, ‘USA’]
    ]
    voices.each { v ->
    say(“Hello, how are you today? My name is ${v[0]} and I speak {v[1]} English.”, [voice: v[0]])
    }

    Another nice feature is voice recognition. Most platforms will let you build an IVR that accepts DTMF input, but Tropo’s will let you do things like this:

    def theVoice = ‘Daniel’
    ask(“What color dress do you want? Choose from black, red, blue or green.”, [
    choices: “black, red, blue, green”,
    timeout: 10.0,
    onChoice: { event ->
    say(“Then you should get a $event.value dress! I’ll text you a link.”, [voice: theVoice])
    },
    onBadChoice: { event ->
    say(“I didn’t understand.”, [voice: theVoice])
    },
    voice: theVoice
    ])

    Can anybody recommend a platform that supports voice recognition (preferably without having to integrate with AWS lex) and has robust yet easy to use APIs in many programming languages?

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}