No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Pairing UCaaS and CCaaS With Your Enterprise Cloud Strategy


Image: alice_photo -
Once you move to a cloud communications platform, should you care what goes on in the vendor’s cloud?
The question reminds me of a story a colleague once shared about his teenage son trying to use his mobile phone on a camping trip in the Sierra Nevada mountains. While explaining to his son that he would not get phone coverage, the frustrated teen replied, “But Dad, aren’t all the cell phone companies in the cloud now?” What a great example of how the terminology was working as designed! The term “cloud” originally referred to a vast “somewhere” on the Internet or Telco network that end users and consumers never had to worry about.
At least for enterprise IT, this is no longer the case, as they move mission-critical applications to cloud services, including the use of unified communications as a service (UCaaS) and contact center as a service (CCaaS). Not only are there large disparities in different providers' approaches, but significant differences also exist within their own product portfolios. As a result, IT decision-makers must pay attention to the underlying cloud hosting the communications services they plan to deploy.
Here are some concerns and considerations that your company should think about when developing an enterprise cloud strategy.
Reliability and Availability
Reliability is the first concern. You can deploy a UCaaS solution as anything from a single instance in a local data center to an array of applications built on Amazon Web Services (AWS) or Google Cloud. I suggest asking two separate questions because they often require two different answers. First, ask what data centers host the UCaaS applications. Second, confirm the location of the Telco interfaces and CCaaS platform. Distance matters to voice quality. If you are in California, data traveling to an east coast location can easily add 60 to 70 milliseconds of latency, which doesn’t leave a lot of play for acceptable voice quality. 
Cloud computing networks such as AWS, Azure, and Google Cloud are rock solid with their Regions, Zones, and Local Edge resources. It looks impressive on a map, but it’s not automatically and instantly available for every application. The UCaaS/CCaaS provider is another customer, and it’s up to that customer to determine the geography and level of availability they build into their solution, all at additional costs.
For example, you have an office in China, and you’re looking at a solution built on AWS; great news! AWS has eight APAC regions. Is the UCaaS solution going to be deployed from the location and the region closest to your headquarters? Are all the real-time services replicated in the region? Is the failover back to the U.S., east coast, or another local zone? With AWS, Azure, or Google Cloud, not all services are available in every region, so even if the provider is not pinching pennies, some services still may need to deploy from a distance.
Strategic Considerations
Cloud communications (and CCaaS solutions in particular) provide an opportunity to use data generated by transactions at an enterprise level. Many enterprises are migrating to a cloud-based data lake and corporate business intelligence platform to manage data in a single repository. Rather than using the traditional (but separate) reporting and analytics tools in a contact center platform, many CCaaS providers offer data connectivity tools and processes to export to these platforms.
What if we can do even better than that? What if you use Azure for your data lake, and the cloud communications provider allows custom storage on Azure rather than exporting comma-separated values (CSV) data? This approach can eliminate external processes that sometimes fail. It helps to think of cloud services as having a “virtual distance” from each other. If the UCaaS or CCaaS provider is on the same cloud platform—it’s right next door. This method can eliminate duplicate data storage costs and expensive data transport costs for data, such as audio recording or high-volume transaction details.
There are many caveats with this architecture; UCaaS and CCaaS vendors sometimes charge extra for a company to store their own data. There may also be limitations on using the data outside of the application itself—due to encryption or proprietary formats. The ability to integrate communications data with other business intelligence in one platform may make it worth overcoming these challenges.
One specific example to give some context is the NICE InContact custom storage option for AWS or Azure. This feature allows storage of your call log data and recordings in an enterprise cloud repository. It potentially saves money—depending on your negotiated storage costs—but this method does not allow much flexibility. If you are storing call or screen recording files in your AWS Simple Storage Service bucket, they are encrypted, and can only be used in the NICE InContact application. Storing the files in Azure uses customer-managed at-rest encryption, which may give you better access to the media for use in external applications such as speech recognition and sentiment analysis.
This process may sound complicated. It can be, but when you have specific objectives in mind for your data, it’s simply a matter of analyzing the following:
  • Where the UCaaS/CCaaS platform is storing your data
  • Alternative ways to use and store the data in an enterprise repository and the virtual “distance” of those options.
  • The potential ways you can use the data out of your own data lake or repository.
One of the downsides to cloud-first enterprise IT strategies is the propensity towards application sprawl. CCaaS and UCaaS solutions don’t help this by providing yet another set of reporting, speech analytics, and storage solutions. Too many different tools do the same job with enterprise cloud applications. As AI capabilities get deployed in multiple platforms, there’s a risk of paying multiple times for the same low-level AI capabilities.
A better approach is for an enterprise to pick one Natural Language Processing (NLP) tool and train it to recognize the language domain of their company. Train once, use anywhere. Google speech is a potential example. You could use its speech adaptation processes to include everything a caller might say about your company, then deploy that model to custom applications. You can deploy the same model to your contact center platform using Google’s Contact Center AI. As a long-term strategy, every hour you invest in training the data benefits the whole enterprise instead of a single application.
It’s possible that this is all too much for your enterprise to consider right now. Perhaps you have just a few domestic locations and no plans to do an extensive corporate business intelligence project. If a turnkey cloud communications solution is all you need, vendors will be happy to provide it to you. All that’s left to think about is the reliability and availability factors. However, if you’re planning an enterprise-wide transformation to the cloud, ensure that your communications technology is part of it.
Join me at Enterprise Connect 2021 in Orlando, Fla., this September during my session, “UCaaS and CCaaS as Part of a Whole Cloud Strategy.” I’ll be joined by Craig Walker, CEO and Founder of Dialpad, Amrit Chaudhuri, CMO of 8x8, and Sanjay Srinivasan, VP & Chief Architect, Vonage. Dialpad is built on Google Cloud, 8x8 is on Equinix, and Vonage is on AWS. It will be insightful to hear their strategies for integrating their services into an enterprise cloud. As a No Jitter reader, use the promo code NJAL200 to receive a $200 discount. Register now!