It’s obvious from the marketing press releases that cloud UCC is going places. An obvious question is whether the news is real or just marketing hype. Perhaps a better question is whether there’s really a case to be made for UCC in the cloud at all. The best question? Could cloud save UCC from competitive and market forces?
A cloud instance of Asterisk, the simplest cloud UC approach, doesn’t really add much to premises-based UC. It would be better if you could somehow scale PBX instances with load, and replace them without losing calls if something fails. These features lead from simple hosting toward something more like cloud-native, microservice-based voice services. What you’d need to do is establish a call database that recorded call state and that could be accessed by any instance of a UC/UCC application involved in call handling. Now we’d have truly elastic scaling and resilience, a real cloud application.
Is it valuable, though? Valuable enough to justify building a new model of call handling? We talk about “five-nines” voice services, but anyone with a mobile phone knows that real-world calling rarely gets anywhere near that level of reliability. What do you do if your call drops? Call again. Some marketeers might argue that that call you dropped was a million-dollar order that you’ll lose because the caller will get disgusted, but in the real world that’s not likely. Anyway, you could improve UCaaS reliability without going “native” in a cloud-native sense. A couple instances of traditional PBX software and a shared call database would probably do the job.
More than Voice
What gets cloud UCC interesting is the presumption that it’s not just voice services. One easy example is the call center. Call centers typically have to link call activity with customer databases, order entry, and so forth. These applications are all logical candidates for cloud hosting, and so it would make sense to have UCC components and call-center application components coexisting in the cloud as part of a multi-application workflow.
Providing they could be integrated, that is. A call, directed to an agent, is the logical stimulus for a lot of application activity, but “pure” UCC systems probably won’t include the hooks to integrate call direction and application/data “direction” to give a distributed pool of agents all the stuff the cloud might hold for them. If you have to do this integration yourself, then you’ve diminished the value of cloud UCC.
Another example is today’s web conference, which is rapidly becoming the preferred strategy for collaboration, and is also already being used in at least some call center-like missions, like customer technical support. When you have voice, video, whiteboard, presentation sharing, and a lot of other stuff, a distributed base of users could be served best by deploying parts of the software close to concentrations of users, to reduce latency. Nothing is more annoying in a conference than voice/video out of sync, and synchronization is easier if you have common processing points and common traffic paths for all the media involved.
Web Conferencing Trigger
In fact, it may well be that cloud UCC is a response of traditional UCC vendors to the whole web conferencing thing. Why? Two reasons. First, mobile devices have largely killed the original mission of “unifying” communications, meaning creating a single app to do everything. Second, what mobile devices haven’t killed, web conferencing is in the process of killing.
Most people these days will follow Facebook, Twitter, SMS, Skype, WhatsApp, and a few other text, voice, and video applications. They’ve found that most of their interactions with others are really logically associated with a single form of exchange — text, voice, video. They use what works, and rely on the device to switch them between apps when different people or missions change the preferred medium of communications. And some of these popular apps will already handle voice, data, and video in pair-wise or even group connections. The workforce of the present is already multiapp-literate, and the future workforce will be dependent on these apps.
Formal multiparty conferences and calls seem to fall outside this mobile app-centric approach. People who want to present something to me, or get a presentation from me, will invariably ask for a web conference. But that’s not because web conferences are cloud applications; most people wouldn’t know (or care) how the applications were hosted. Clever marketing has more to do with the success of the web conference as the beyond-the-app solution to collaboration.
Cloud-Native App Design
That means that clever marketing might be the basis for cloud UCC success. What proponents of UCC in general, and the cloud version in particular, should be looking at is how distributable components of communications and the applications needed to support the communications could be synchronized in the cloud, hosted in optimum locations to ensure timely delivery of quality information. This is less an issue of communications than one of cloud-native application design.
What we need here is a kind of call scripting that handles not just calls or communication, but also the related applications. With this, users could describe what information they want delivered in parallel with communications, what application connections they need to have made, and perhaps even the format of information being displayed. The entire relationship between users and information could be described, and we could have a variety of scripts, one for each major type of interaction.
This isn’t technically difficult, but UCC vendors don’t seem to be jumping out to support it. If that continues to be the case, then market conditions and competition with web conference firms will surely threaten, and further erode, the UCC value proposition. Collaboration isn’t communications alone, and UCC vendors need to accept that, quickly.