Red Flags That You’re Not Dealing with a Cloud 2.0 Solution

Cloud software as a service (SaaS) are not just buzzwords anymore; they’re ways for organizations to become agile and efficient to meet their changing business needs. This is the age of the cloud. And as technology becomes more diverse and complex, we spend too much time managing it, instead of investing time in our actual business.

The cloud promises to take away this management burden so we can focus on the daily business at hand. But does it really save us time when a cloud contact center provider simply deploys a lift-and-shift strategy, in which they move the physical location of the hardware and software from the business premises to the cloud?

In these instances, businesses are still saddled with the same problems and challenges associated with legacy monolithic applications, including scalability, reliability, recoverability, and flexibility. These monolithic applications were never meant for cloud consumption. And I characterize this lift-and-shift datacenter strategy as a “Cloud 1.0” solution—or a hosted solution.

I know what you are thinking: “Hey! It’s not our problem anymore. We’ve already gone to the cloud.”  Have you? Just because you have a cloud contact center vendor doesn’t mean that you are reaping the true benefits of the cloud.

With the cloud, we all want a commoditized solution—just like our electric, water, or cable companies supply. When we flick on that light switch or turn on the water faucet, we don’t think of when, how much, or where we consume a resource. We expect it to be there and want to pay for only what we consume. It’s time to expect and demand the same service from our cloud technology providers.

Cloud 2.0 solutions exist, but companies need to sort through all the marketing hype that disguises hosted, legacy, monolithic applications as Cloud 2.0. Over the next blog posts, I will identify potential red flags that indicate when you’re not dealing with a true Cloud 2.0 solution for your business. Let’s begin with the first red flag.

Detailed Capacity Planning for Scalability

At a recent prospect meeting, I was handed a discovery/capacity spreadsheet for a company. It not only listed—in detail—the number of agents, media channels, locations, bandwidth, etc., in a company’s existing system, but it also indicated the number of specific features—fax, speech recognition, conferences, and announcements. These were also categorized according to agent, agent groups, departments, and locations. Additionally, they listed software configuration maximums, such as the number of wrap-up codes; maximum system alarms; thresholds; and limits. There were even more tabs that showed capacity as well as resource and feature utilization by day, week, month, and year.

They had provided all this information because they were expecting long and drawn-out capacity-planning conversations. This type of detailed information was essential when designing and architecting legacy communications solutions. Input from spreadsheets helped size the systems with enough resources. Peak utilization and calling patterns ensured that the system would scale for worst-case scenarios. All this information not only kept engineers from making unnecessary assumptions, but it also allowed the architecture to scale to specific thresholds.

However, our prospect was thrilled that PureCloud by Genesys completely obviated the need for such a long and detailed session. A true Cloud 2.0 application does not need that level of detail nor does it consider the maximum consumption or peak utilization of a solution. This is because none of this information changes the underlying cloud architecture.

As a cloud contact center customer, you should be able to scale up and down as and when required. It does not matter if you have 30 agents on Monday and 3,000 agents on Tuesday. That is a drastic example, but it is in the DNA of Cloud 2.0 solutions to accommodate such variations automatically for all their customers. If high-level information, such as number of agents and locations, is collected for Cloud 2.0 solutions, it is simply to provide customers with budgetary pricing information. This is like the cable company asking which channels a customer watches so that that they can identify the appropriate billing package.

If your cloud contact center vendor seeks capacity-planning meetings and requires granular utilization numbers, then it’s time to dig deeper. Find out if you are dealing with a legacy application that is hosted out of datacenters. Unlike monolithic applications, a Cloud 2.0 application is comprised of decoupled, scalable, independent services that work together to form a larger platform that is technically known as a microservices architecture. Such architecture accounts for demand elasticity while providing fault isolation. For those wishing to dig deeper technically, here are is link to get you started:

For a visual explanation, think of each microservices instance as a small fish in the ocean. Any one of the fish individually has its own characteristics and personality, i.e., functionality. Together, those fish form a system that can overcome any obstacle—however large or powerful its jaws.

In my upcoming blogs, I will discuss topics such as time to deploy, datacenters vs. cloud, updates, upgrades and release cycles, global reach, and cloud application simplicity to help identify additional red flags that point to a Cloud 1.0 solution, instead of Cloud 2.0. If you think of additional topics, send me a comment. For now, you can figure out what you will do with all that extra time you save because you don’t have to attend capacity-planning sessions anymore.

Learn more about the administration, configuration, and architecture of a cloud contact center with PureCloud by Genesys global webinar replay, All Cloud Contact Center Software Is Not Created Equal.