CPaaS Should Not be Used Interchangeable with Programmable Communications

I’ve pointed out CPaaS (Communications Platform as a Service) is a dumb term since its creation. Analysts are paid by vendors, products are defined so analysts can write reports about them to help vendors sell those products. I’ve begrudgingly used CPaaS, as when I use the term programmable telecoms or communications, people look at me weird. However, I see the term CPaaS creating problems for some in the industry, and realized I should not use those words interchangeably. This thinking is a work in progress.

A common definition of CPaaS is a service that allows companies to add various communication features to their existing business applications. Which is an OK definition but underlying this are a few hidden assumptions:

• “CPaaS will make you like the top CPaaS, Twilio”. Which is most definitely not the appropriate case for most enterprise comms providers, see the diagram at the end of the weblog for a few examples of such companies.
• “Buy our CPaaS technology and you’ll be programmable.” Technology is never a solution, there are also people and process changes required. Often enterprise comms providers do not need to be CPaaS.

Before CPaaS came into existence, I referred to Telecom APIs, I still run a Linkedin group about it. Telecom APIs made telecoms and communications programmable, like the web. The Web didn’t need a WebPaaS, they needed API Management. And for many enterprise comms providers, API Management maybe 80% of what they need with the addition of some partnerships, integrations, and a clear business plan. Not a CPaaS.

We’ve recently seen some ‘CPaaS’ implementations winding down, or focusing on B2B rather than ‘developers’, or being relabeled, or resources being removed. It’s not that programmable communications / telecom is in decline, it’s still growing in the high twenties %, down from the 33% of the pandemic. It’s the product focus of CPaaS as the standard-way to add APIs to a communications platform has some in the industry spending more than they need and chasing too many lines of new business outside the core offer.

CPaaS is a product. However, the problem being addressed is making telecoms / communications programmable, like the web is programmable. The specific approach you take depends upon your business. Hence my realization focusing on your programmable communication needs rather than the implementation CPaaS, a technology-led solution, could avoid some of the recent challenges we’re seeing.

There are Many Different Types of Enterprise Comms Provider: Those that Identify as CPaaS

If you’re an enterprise communications service provider, you make your platform programmable to enable applications and integrations to be built on your communications services. You’ll note I’ve not said the ‘cloud’ in describing programmable communications. If you see the term cloud being liberally used beware, its marketing.

We are entering a post-cloud world, here are some examples. Kaleyra builds private CPaaS for banking customers. We have a great presentation from TADSummit Americas 2019 from Terry Hsiao on private CPaaS. Kaleyra also offers public CPaaS, they’re an aggregator, but I’m not going to argue over what people want to call themselves. Another example, given the country-by-country privacy and compliance requirements, you can now point to the data centers where a company’s software is running to ensure customer data does not leak into other jurisdictions. I mentioned this in the CXTech Week 8 2023 newsletter with region-locked data centers.

I show in the quick sketch at the end of this article for some of the categories of businesses involved in enterprise communications. For example, SMS aggregators like Sinch and Infobip, expose APIs for SMS and for acquiring SMS capable phone numbers. They also expose many other communications APIs, for example IP messaging platforms, voice, etc.. They also provide packaged applications, e.g. a CRM agent messaging console, or an marketing campaign tool, or a workflow tool to alert a customer when the ecommerce basket is left full, etc.

They consider developers strategic to their business, even though most of their deals are B2B. They want their APIs to be easy to use regardless of whether a developer is doing something for their job or as a hobby. They label themselves CPaaS, as they hope the valuation multiples of Twilio also rub off on them, though since the end of the pandemic those multiples have temporarily gone south. And as I think about differentiating CPaaS and programmable communications, perhaps using this labelling for the aggregators is OK.

Twilio is a much more diverse business than aggregation (it generally relies on Syniverse to do aggregation of PSTN services, while it aggregated many IP comms services). Though SMS is the dominant revenue stream for Twilio; Flex (99% of a CCaaS), SIP trunking, IoT, fraud protection, customer data (Segment), serverless etc. are all growing. Twilio’s business is across the end-to-end enterprise needs of programmable communications, not only CPaaS. They enable businesses to gather and clean up their customer data along with fraud detection and identity management to deliver better experiences, this is a nice example of the reach of programmable communications.

There are Many Different Types of Enterprise Comms Provider: All the other Ones

Some businesses are focused on business phone systems, they deploy business networks, phones (both desk and app), and the PBX as it makes business sense for all parties. They have APIs for their PBX or UCaaS, but do they need a CPaaS? It depends on the size of the business and the scope of their offer. They will have APIs for sure on their PBX/UCaaS software, whether they are exposed beyond their customers depends.

They’ll need API management to ensure security for their customers. They’ll have some packaged integrations and applications specific to the customers they serve to be competitive in the market. They will maintain those apps and integrations, where it makes business sense. However, they can not offer every possible integration and packaged app their customers’ needs. Hence APIs enable some tech-savvy customers to extend the platform to meet their specific needs. And there are no-code / low-tools to enable those less tech-savvy to do it themselves, Mendix is an example of a low-code / no-code tool partner.

The line between apps / integrations you own as a provider, versus capabilities you expose for others to build apps / integrations is a complex and evolving one. RingCentral uses this line to squeeze out the competition. So telling customers, ‘you get what you get and you don’t get upset,’ may not be viable into the future. Unless you’re targeting the value end of the market.

UCaaS and CCaaS businesses were led to believe they need CPaaS. They needed APIs on their platform, and that’s expected on almost all software packages. API management is needed and that’s available from lots of providers from open source so you can build it yourself to the big guys like Google and Mulesoft. Do they need a CPaaS with all its integrations, aggregations, credit card billing, and single pane of glass drill down dashboards? It depends.

CPaaS may not be the answer to most comms providers’ programmable needs. However, an API and API management most definitely is. Beyond that, it’s important to think about your business and the partners that can complement your offers. For example a no-code / low code partner, aggregation (CPaaS) partners (to resell part of their offers), etc.

If you offer public APIs and are a large business, then declared developers as strategic to your business and be consistent over decades. This is not a fashion, this is a commitment. Have great documentation and focus on making it easy – that low-code / no-code tool really helps prospects and existing customers get to cash faster. You can partner or build that tool.

Does every enterprise comms provider need a CPaaS to make themselves programmable? Most definitely not. Programmable communications is much broader than CPaaS. You may find a more incremental approach keeps you competitive and delivers value to your customers.

In summary:

• CPaaS: A software product aggregators use to expose communications APIs like Syniverse.
• Programmable Communications / Telecoms: Making your communications / telecom solutions programmable for your customers and ecosystem partners like Twilio.