Cisco Spark – Amongst a Sea of Collaboration Tools, What’s the Point?

July 31, 2017 Collaboration, Trends

Cisco Spark has been a thing for quite a while now, and it comes free with Cisco’s WebEx SaaS Annuity platform. Yet, not every organization who subscribes to WebEx is witnessing rampant end-user adoption of Cisco Spark. One client described it to me as “a solution in search of a problem.” Honestly, how many of us who have tried it really get the point of it? After all, we have no shortage of communication tools. How does adding one more to the mix help us in any way? Well, it turns out that Cisco Spark actually solves a very specific problem.

If you aren’t familiar with Cisco Spark at all let me quickly bring you up to speed. I first heard of it at the end of 2014. At that time Cisco was calling it Project Squared. It was a cloud-hosted, team-based persistent chat application that offered threaded conversations, the ability to share files, and video meetings. Over the years it has been re-branded and new features have been added. It can now function as a cloud PBX with Cisco phones and video endpoints registering directly to the Cisco Collaboration Cloud and can provide SIP trunking services via 3rd party providers. Furthermore, the elegantly designed Spark Board has caused quite a buzz lately by bringing tablet-like usability to meeting rooms. The Cisco Spark service can also be tied back to your on-prem Cisco Collaboration infrastructure via Spark Hybrid services to provide additional functionality.

The problem with end-user adoption of Cisco Spark as a communication tool is that from an end-user perspective alone it is no better than any of the other communication tools that are available all over the place. On the weekends in my spare time I like to play online PC games with friends. One of my friends that I play with is a Cisco employee. When we first started getting together to play he suggested, “Hey, maybe this is a good use case for Spark?” To which no one replied, and the conversation quickly turned to a debate of the pro’s and cons between Discord and Twitch’s Curse application–both of which are free to everyone. Discord and Curse are both specifically designed for collaboration around playing video games, and they offer some excellent features just for that particular use case that no other collaboration tool offers. And I suspect that it is a similar situation for many specific use cases. For example, Autodesk offers two different collaboration tools (BIM 360 and Collaboration for Revit) which are specialized and targeted at some very specific industries. You can look around and find a similar situation in just about any industry.

So, what is the point of Cisco Spark then if it is not the communications tool to end all communications tools? The way I see it, Cisco Spark is about one thing and one thing only–better meetings.

Have you ever been in a meeting that was completely on point the whole time? When I ask that question, most people say laugh and say “no.” Well, I have. And it was awesome.

  • The meeting started with a solid agenda
  • Everyone was on the same page about why they were meeting and how they needed to be prepared to contribute
  • At least one person at the meeting was focused and kept bringing everyone back to the agenda
  • Visual aids were prepared and distributed to everyone — in paper because paper is compatible with everything and doesn’t take 10 minutes to figure out how to operate
  • Everyone walked out with action items and actually followed up in a timely manner

The problem is that when I have these awesome meeting experiences it is because one person steps up and puts in the preparation and follow up (aka, nagging people to follow through with their action items) that it takes to maximize the productivity of their meetings. That usually isn’t the norm. Once you sit through a really productive meeting like this and then go back to what I think of as an average meeting, you really feel like you are missing out.

Let me walk you through another scenario.

Let’s say your name is Mr. So-and-so Project-contributor (So-and-so would be an awesome name). A colleague asks you “Hey, do you have the tracking info on the equipment for the project?” And you say, “Oh, I didn’t even know that project got the green light. That’s awesome. Let me reach out to our procurement team and see if they have tracking info.” So, you send an email to your procurement distribution list. A couple of hours later you get CC’ed on another email thread about the same question… and another. Eventually you see a couple of messages back on the different threads from the procurement team. Then someone does a reply letting everyone know that there were three threads for the same topic and to please use this one from now on–oh, and by the way, we still don’t have the tracking info yet. Then around 4pm you get a calendar invite for the next morning at 9am–sandwiched between your 8:30am and 9:30am meetings. When you get on the call the next morning, you find out that you are the star of the meeting. Everyone has decided that the plan for the call is for you to explain the project to everyone. You haven’t even looked at the project for 6 months so you have to spend the first ten minutes collecting your notes and gathering your thoughts before you give a totally unprepared explanation and look like a complete clown. Then you have to jump off and go to the next call with no plan on how to move this project along and the expectation that you will probably have a repeat of this call later–hopefully when you are better prepared.

Well, Mr. So-and-so, didn’t that suck?


The difference between the first meeting example and the second is that the first one was somebody’s baby, and whoever it was put a lot of love into it so that it would go right. The second example was a meeting that was initiated as part of a workflow or business process. You could even say that the process “Sparked” the conversation… (If you wanted to be really cheesy you could say that… Which I do… Okay, I am putting my air quote fingers down now. I know that you aren’t laughing. That’s okay. It’s still funny to me.)

The key to getting value out of Cisco Spark is baking it into your business workflows. Doing so inherently brings a subroutine to those meetings: prepare, meet, follow up. In our example, the meeting could have been initiated at the beginning of the workflow instead of at 4pm the day before the meeting occurred. That would have avoided the multiple email threads and given everyone an easy method to just coordinate a little bit for the call the next morning.


So, maybe you see the advantages of preparing for a meeting and following up, and maybe now you see how a team-based persistent chat application can help facilitate that. So, with all of the persistent chat applications out there, why Spark? We can designate someone who will manually create a meeting space and manually add all of the relevant team members to the space. Why not just use any available persistent chat application?

It’s like my Nimble SE says, ‘Hey… the 00’s called. They want their Myspace accounts back. In the 10’s we automate things.’

With all of the application integrations available at this is no different. You are already setting an opportunity to Booked or setting up a new project. Why not have a Spark room automatically created with all of the team members from whatever web-based tool you are already using? As and end-user, adoption is no longer an issue for me at that point. If I get a message on my phone telling me that my project is a go, I can see live that people are asking about tracking information, I don’t have to serial call if I need immediate info because I have one button to call everyone, and preparation for my inevitable meeting has already begun.

No one has to explain the value of the software for me or when I should use Spark vs Instant Message vs Email. At that point Spark has become specialized to a particular use case, and it is clear to me when to use it because I am already using it and seeing value from it.



Travis Wilson is an in house collaboration guru and has his CCIE to prove it! At ABS, Travis designs and architects sophisticated networks for some of ABS’ largest clients.