Telecom APIs Move to the Next Phase – Packaged Applets

3D illustration of tablet and mobile phone with construction workers, trucks and cloudsTelecom APIs in the form of CPaaS (access to telecom functions that reside in the cloud, paid for as you use them) have spurred much innovation and disruption in the communications industry. Developers can easily incorporate these functions to enhance an application (maybe voice enable or text enable an existing application) or create a voice centric communications application from scratch.

Looking at it from a different perspective, if the application is connected to the internet (via mobile, WiFi, or wired), which means most applications these days, access to these APIs is available. That’s powerful and that’s why this model was disruptive. As such, if you have any idea, it is easy to test and try things this way, it is easy to roll them out, and it is scalable as well.

And while there are a few stand-alone CPaaS companies out there (such as Twilio), a few UCaaS companies (such as Sangoma) have their own CPaaS platforms as well. Why is that? Well, for one thing, the customer is already accessing the UC application in the cloud and they are comfortable with cloud-based communications. And we can better enable our UC customers with enhancements they might want to do on top of our UC platforms.

But have we entered another phase in CPaaS, possibly predictable even, where we see more broad industry needs and thus create a catalog of applets / applications that our UC customers can use? Certainly, we see that. So, we have started to create a category of “connected worker” applications, and the incorporation of text messaging for connectivity. And that’s important so we can help our customers service their customers better.

Sangoma is committed to helping our customers service their customers better, so this model is important to us. Expect to see additional applets and applications like this as we see general needs emerge.

Share on Facebook
Share on Twitter
Share on LinkedIn