The Other Tropo Story: Spark In, Slack Out

by Dave Michels

The Other Tropo Story: Spark In, Slack Out Once a happy Slack user concerned about a forced migration to Spark, the Tropo team now finds value in the deeper workflow integrations it’s gained in the process.

Once a happy Slack user concerned about a forced migration to Spark, the Tropo team now finds value in the deeper workflow integrations it’s gained in the process.

As many of you are no doubt well aware, Cisco acquired cloud API platform provider Tropo in May 2015 to complement and expand its Spark collaboration app. That’s an interesting story itself, and hidden within it is the tale of Tropo’s messaging journey.

Tropo began life in July 2009 as Voxeo Labs, a division of IVR solutions and platform provider Voxeo (now Aspect Software). Voxeo Labs was created to mimic the skunk works model found in some highly innovative companies. The division created several products, one of which was called Tropo, a lighter version of Voxeo’s Prophecy IVR platform in use at several large contact centers at the time.

Tropo provided carriers a way to leverage their own infrastructure with developer APIs and a communications platform-as-a-service framework. When Aspect acquired Voxeo in mid-2013, Voxeo Labs became a standalone company renamed as Tropo after its flagship product.

From Skype to Slack
I’ve been interacting with the Tropo team since its earliest days, so know that when Tropo separated from Voxeo, it didn’t bother implementing its own UC solution but rather decided to use smartphones and Skype for communications. In December 2014, Tropo CEO Jason Goecke (now GM of the Cisco Tropo Business Unit) then switched the company’s internal messaging tool from Skype to Slack with an initial goal of improved messaging. Slack offered features like the ability to preview links and cut and paste code snippets that Skype lacked. Tropo soon went all-in, making Slack its primary tool for messaging and collaboration.

As is often the case at organizations using Slack, it didn’t take long for the service to spread across the company and into the workflow through integrations with business applications. The Tropo team used Slack’s APIs and Slackbots to customize their implementation.

In one integration, for example, Tropo set its internal Zendesk trouble ticketing system to create a Slack room for each new ticket entered. This Slack room then became the point of control and troubleshooting. In fact, the support team could take action from within the room, issuing permission-controlled commands to the Amazon Web Services cloud for problem resolution, for example. Without priority or coordinated effort, Slack became central to many Tropo processes.

From Slack to Spark
During this time, Cisco knocked on the door seeking assistance in developing customer-facing APIs for what it then called Project Squared (but has since renamed as Spark). Cisco was specifically interested in the team’s expertise building out platforms, since it was exploring extending Project Squared from application to platform.

Tropo CTO Jose de Castro (now CTO of Cisco Tropo) and Rowan Trollope, head of Cisco’s Collaboration Technology Group, developed a shared vision for a platform-first approach to communications. This vision led to acquisition discussions, but there was an underlying concern throughout the process. If Cisco acquired Tropo, then it would insist on the replacement of Slack. The fear was reasonable considering the success that Tropo was having with Slack and the relative immaturity of the Cisco collaboration app.

The two companies worked together on several proofs of concept in the early days of Project Squared, and largely due to Tropo’s influence Spark today is very different than Project Squared was when acquisition talks began. A platform-first approach meant taking the time to define the “nouns and verbs” of APIs rather than just focusing on creating a strong user interface. The Tropo team got excited about the potential of Project Squared, de Castro became a strong proponent of the combination, and the acquisition got the Tropo blessing.

Incorporation of collaboration into Tropo’s workflows is now even broader than it had been with Slack. Of course, integrating with Spark i took more effort than integrating with Slack bbecause Tropo had to first turn Spark into a platform, or more specifically, according to de Castro, a “platform-first” approach to communications. With the Spark platform, functions like messaging, voice, encryption, calling are loosely coupled services, each with its own set of APIs.

The Spark integrations can go deeper than Tropo had been able to do with Slack. For example, the previously mentioned Zendesk integration now supports the ability to escalate a chat room conversation into real-time communications across clients, phones, and video conferencing rooms. And, on the application side, the team now uses Spark’s zero-touch meeting feature to automatically create meetings between internal callers, leveraging room-based resources and enabling seamless screen sharing. The Tropo team is enabling APIs so that its development partners can extend this to other applications and activities.

In the year since its official launch, Spark has become central to Cisco Collaboration, both as an application and a platform — and Tropo is indeed Slack-free.

Dave Michels is a contributing editor and analyst at TalkingPointz.

Follow Dave Michels on Twitter and Google+!
Dave Michels on Google+