What To Look For In A CPaaS // Product Design

September 9, 2021 // Product

According to Gartner, “By 2023, 90% of enterprises will leverage API-enabled CPaaS offerings as a strategic IT skill set to enhance their digital competitiveness.” A projected 70% increase from 2020. The question isn’t should you make the switch to a CPaaS, but when you do, do you know what to look for?

In this series, we will cover a handful of important factors to consider when investing in and making the switch to a CPaaS for your telecommunication needs.

Product Design

No matter what CPaaS you choose, you will have to allocate time and human resources to integrate with and build around it. Whether it be in the design, implementation, enhancement, or maintaining phase, you will spend time creating harmony between your humans (employees/customers/vendors), your applications, and your CPaaS provider. However, some communications providers, like Voxology, can require far less work from your developers and telecom engineers than others.

One of the primary benefits of utilizing a CPaaS is that you can reduce the amount of communications-related complexity your team must deal with. However, the design of your CPaaS’s product can have massive implications on that benefit, particularly how much complexity their product enables you to do away with.

Less Equals Less

One of the biggest differences you’ll find in CPaaS offerings is the amount of code that’s required to build and integrate with their API. Not all voice APIs are equal. Specifically, some are far more chatty than others. Some voice APIs require developers to write code to handle each independent action on a phone call, so creating a simple customer service call flow to allow a customer to call in, answer a few questions, and be routed to the correct department can force developers into a painful place known as callback hell. Callback hell is a phenomenon that software developers find themselves in when dealing with nested callbacks. Keeping track of the state of each phone call while accounting for all the error conditions and predictable (or unpredictable) user errors can be a nightmare. While this is undoubtedly a place developers would love to avoid, some voice APIs require your developers to unnecessarily deal with this complexity instead of allowing the platform to deal with it.

To help highlight, imagine a simple IVR (interactive voice response, or automated phone system) as a path that the customer walks down to get to where they’d like to go. We’ll call this first example the “Happy Path” - a term used to describe a user experience that is free of exceptions or error conditions (that your developer/designer ultimately needs to deal with).

Example Call Flow (Happy Path):

Step #1:

• IVR // “Thanks for calling ACME, Inc. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Presses ‘1’

Step #2:

• IVR // “Thank you! Now enter your 5 digit zip code.”
• Caller // Enters ‘60606’

Step #3:

• IVR // “We are currently experiencing abnormally long wait times. If you would like us to call you back say ‘call me back’ or press ‘1’. If you would like to be placed on hold, just stay on the line.”
• Caller // Decides to stay on the line to wait for an agent.

On the “Happy Path” above, the caller doesn’t do anything unpredictable. Even then, many of the popular voice APIs require your application to keep track of the caller’s state which requires your developers to build a multi-threaded state machine just so you know where the caller is in the IVR to play the correct prompt.

Now imagine what happens just on Step #1 if the caller starts to diverge from the happy path…

Example Call Flow (Unhappy Path):

Step #1:

• IVR // “Thanks for calling ACME, Inc. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Distracted and didn’t press or say anything.
• IVR // “I’m sorry, I didn’t understand. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Presses ‘0’
• IVR // “I’m sorry, zero isn’t a valid option. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Presses ‘11’
• IVR // “I’m sorry, eleven isn’t a valid option either. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Says “Speak to an agent, please”.
• IVR // “I’m sorry, I understand that you want to speak to an agent. I just need to know which department you would like to speak with so that I can transfer you. For sales, say ‘sales’ or press ‘1’. For support say ‘support’ or press ‘2’. For all other inquiries, press ‘3’.”
• Caller // Says “support”

Step #2:

• IVR // “Thank you! Now enter your 5 digit zip code.” ...

As you can see, the unhappy path(s) can get complicated quickly. What if the caller presses ‘0’? What if they don’t press any digits? What if they press two digits or more? What if they say “Hi, my name is Charles and I am not very happy with your service”? Your first step just turned into multiple paths that may or may not converge in the future of the phone call. And, your developer now needs to deal with all those predictable and unpredictable use cases in their code.

Many of the popular CPaaS providers require a tremendous amount of code to deal with both the happy and unhappy paths, and the more code your developers have to write and maintain, the less reliable and more cumbersome the backend of your application will be.

Here at Voxology, 99% of the call flows on our platform are supported with a single callback response. We believe that a CPaaS should empower you to easily uncouple your business logic from your communications so that a change to the business logic doesn’t call for a refactor. This also allows your communications integration to more easily be treated as a microservice of your application - a part of the whole but not wholly dependent on the other parts of your code base.

Reduced Server Processing = Reduced $

Another benefit of choosing a CPaaS that requires less code and less chattiness is a reduction in server costs. There’s no getting around paying for cloud services on the major carriers like AWS or Azure (unless you are running your own equipment), but it is very possible to mitigate your spend on server usage and capacity when it comes to your communications platform. For some large corporations, who are able to construct their walkways out of gold bars, the reduced server processing power may not be a major concern, but for the majority of businesses, large and small alike, any amount of fiscal savings is always a good thing.

Why Choose Voxology?

By building your communications applications on Voxology, your dev teams and telecom engineers can build and maintain far less middleware than will be required on other CPaaS. While you can craft a solid architectural framework with any CPaaS provider, only Voxology gives you the tools to make it easier, more cost-efficient, and require a minimal amount of work.

Voxology is the telecommunications backbone of industry leaders in a wide range of markets. In addition to providing your developers with an easy-to-use API, we also provide the phone numbers, minutes, and call control functionality you need to modernize and maximize your entire communications infrastructure.

We supply the customized support, documentation, and getting started guides your team needs to build the features you and your customers are looking for, including:

• Local Phone Number Coverage // Search and provision phone numbers from our massive inventory of local numbers based on prefix (NPA-NXX), city/region, LATA, Rate Center, or postal code.
• Toll-Free and Vanity Phone Numbers // Provision dual-homed toll-free numbers that can easily be SMS and MMS enabled. You can even bring your own RespOrg (if you are one, or considering it).
• Programmable SMS/MMS // Send and receive SMS and MMS on toll-free and local phone numbers via an API.
• Logging // View message and call logs to see when automated interactions took place in the application.
• Answering Machine Detection // Provide alerts via voice, and create a customized experience for your end users — understanding whether you are leaving a message for a live person or a voicemail inbox.
• Call Control // Provide seemingly endless optionality on your call flows via the Voice API.