CCaaS: Taking a Look Under the Hood
Updated: May 21, 2019
When it comes to the CCaaS vertical we have seen feature functionality changes throughout the years. Most recently, AI has been inserted into CCaaS as a seemingly viable augmentation of existing product sets and in some cases a brand-new feature set. Features, such as chat, SMS Text, email, social media, outbound dialers, and other options, often attract customers to providers. However, it is important to understand the differentiators between providers and their underlying feature set, and who is providing them. There are very few providers who own and support 100% of their own product stack (TFN/DID voice, dialer, SMS Text, chat, email, social media, visual IVR, WFO/WFM etc.). Some providers try to conceal this important information and others broadcast it as a “value add” with their go-to market strategy. The key take-away from this is if the supplier does not own a part of their technology stack, it is important to understand the SLA and support agreements that are in place.
Features are an exciting part of CCaaS, however, it is vital to review is how services are architected and supported. CCaaS providers vary on how they are built. Some are built on their own infrastructure, while others utilize hyperscalers such as AWS/Azure/Google. However, most have adopted a hybrid approach. In the hybrid approach, some providers are extending their environment by using hyperscalers for storage and reporting feature sets, while others are moving critical applications into this style of infrastructure. Then there are CCaaS providers who white label and provide tier 1 and 2 engineering support, but don’t own the underlying technology. This can be beneficial if the white label provider has extremely proficient support models, wholesale pricing or deep integrations.
It is helpful to know the pros and cons of the providers infrastructure, but one of the most important items to review are their BCP, and DR failover. Some good questions to ask are; How often is BCP and DR tested? What is the latest documentation/how often does the testing take place? One thing we all know about technology, it can fail.
While SMS text, chat, email and social media can have delayed response in the event of a DR failover, DID/TFN voice should be seamless. It is vital for the provider to be their own RESPORG and have a failover strategy. If there are issues with TFN and DID services, this allows them to move to a different voice strategy or underlying provider. Some CCaaS providers give the option to bring your own voice provider. Traditionally this can create finger pointing and adds complexity to the solution, however, there can be beneficial cost considerations with brining your own voice to a CCaaS environment.
Regardless of what provider you are entertaining for your CCaaS solution, it is important to look under the hood to see how services are being provided and not get caught up in the sizzle.