Where’s your head at: the promise of Headless BSS for telcos

Headless BSS allows telcos to retain their existing customer-facing platforms, while modernising and integrating back-end functions, giving operators the flexibility to choose only the components they need, and benefitting from streamlined, pre-integrated deployment.

The purpose of a product suite is to allow operators to select the modules they need, while providing the benefits of pre-integration within that selected set. But are there common break points in that suite selection, and if there are, what can vendors do to strengthen those interfaces, and make the deployment and integration even easier?

Headless BSS is a strategy used when telcos want to keep their existing customer engagement layer, such as mobile apps and online shops, while also gaining from “pre-integration” of other functions including fulfilment, charging and billing.

In short, with Headless BSS, operators can undertake a full digital transformation project while keeping their customer-facing platforms. After all, sometimes these existing systems persist for good reasons:

• The users like them
• Engagement layer is where you differentiate
• Long-term agreements or different refresh cycles
• … or a full stack transformation may be too complex

There are many benefits of adopting a product suite from one vendor – the proven pre-integration, common architecture, harmonised product roadmap, or just having a single throat to choke if things go awry. But there are equally strong reasons for using other solutions in different situations.

It’s not uncommon for some overlap between product suites as vendors broaden their capabilities, and their boundaries often cover each other (from finance to sales, and vice versa), so a choice will need to be made on which modules to take from which supplier.

Within the Lead-to-Cash journey, which might cover product catalogue, CRM, fulfilment, charging and billing, as well as the entire engagement layer, is there a common transition-point that operators can identify between the suite and other modules?

TM Forum’s Open Digital Architecture (ODA) provides a description of the main capabilities required. This gives us six high-level functional blocks:

ODA Canvas Operators
This is a foundational layer that provides the cloud-native platform, infrastructure services, API management and DevOps capabilities required to host and operate all other ODA components. It ensures scalability, observability, and standardised deployment of ODA-compliant solutions.

Engagement Management
Manages all customer and partner interactions across both digital and physical channels. This is very much about channel orchestration, configurable customer journeys and providing consistent user experiences across all touchpoints.

Party Management
Handles the lifecycle of all “parties” (individuals, organisations, roles) including identities, profiles, agreements and relationships between them, ensuring a single source of the truth.

Core Commerce Management
Covers business-critical processes such as product catalogue, pricing, ordering, billing and revenue management, enabling seamless monetisation and fulfilment of products and services.

Production
Responsible for service design, resource management, activation and assurance, ensuring that services are built, delivered and operated effectively in the network or BSS/OSS environment.

Intelligence Management
Provides real-time analytics, AI/ML-driven insights and comprehensive data management to support operator decision-making, optimise operations and enable closed-loop automation across the architecture.

Across these six areas, we see a consistent and recurring theme; operators want to keep full control of the brand experience they provide. So they focus their efforts on the “surfaces” of their business that will differentiate them the most, the key customer touchpoints:

• Contact centre CRM
• Retail CRM
• Self Service (web portal and app-based)
• Partner Channels (shopfront and catalogue)

To come back to the ODA, these are all part of Engagement Management, and it’s here that we’re seeing operators looking to have specific solutions for each of these routes to market.

For example, a dedicated CRM system in the contact centre. Possibly the same again in the retail environment, or a platform with till and shop peripheral pre-integration. However, we increasingly see an adaptation of the customer self-service platform deployed in shops instead of the CRM. This creates a neat separation between the engagement layer and the rest of the BSS stack.

A good example of this is our recent project with Virgin Media Ireland, which uses a Headless BSS model with point solutions for each of their key customer engagement points: in the contact centre, eCommerce and retail stores. This gives three distinct routes to market (an omnichannel model), but all catalogue-driven from our Enterprise Product Catalogue and passing sales orders back to our Service Manager for fulfilment, via our TM Forum certified Open APIs.

Another example is GO, in Malta. A customer of 25 years and recently upgraded to the latest Cerillion version, they’ve chosen a differentiated model where they’ve deployed distinct upstream components for business and consumer segments. For B2B they use Salesforce CRM, feeding sales for fulfilment, charging and billing into Cerillion. For B2C, they differentiate in the local market with a bespoke self-care solution for customers to manage their own accounts. But once again, it all comes back into the unified Cerillion BSS for centralised management – the single source of the truth.

What can BSS suite vendors do to help with this?

A clear first step is to make their points of presentation to any external system as simple and as standardised as possible – Open APIs provide the ideal foundation. However, out-of-the-box Open APIs are unlikely to be where you end up, since almost every deployment requires custom AVPs for localisation, but having a vanilla plug-and-play integration is still a great place from which to start.

Secondly, clear boundaries between the functional components. Although the ODA maps out a neat set of 66 components, these don’t necessarily align with how BSS/OSS suppliers package and sell their products. Many vendors have not designed either software architecture or licensing models at such a granular component level, so being clear on what’s being requested and what capabilities are being provided is crucial.

For example, managing customer upgrades. This process often involves more information, capability and complexity of software than for pure new sales, but is nonetheless still sales. It makes sense to have upgrades handled by the same teams as new business, but the engagement layer software may not be sufficient if the upgrade involves billing or contract management.

To help with this, BSS suite vendors should offer more specific API access to back-end processes. APIs can also be used to provide a “window” into the BSS from within the engagement layer, presenting key information on credit, contracts, payments and fulfilment using embedded third-party widgets or cards.

Where can operators differentiate?

In short, where they can, they should. As outlined above, this most often comes through their brand experience, whether that be in the call centre, retail stores, online or social media platforms.

But where they can benefit from commoditisation, productisation or standardisation they should do that too – leveraging supplier relationships to address these areas and freeing up their own resources to focus on the points of differentiation.

Best-of-Suite versus Best-of-Breed

A common question for operators is whether to go with a best-of-suite BSS or best-of-breed?

Best-of-Suite refers to a pre-integrated, end-to-end BSS stack from a single vendor. It typically provides easier deployment, as all modules should work together out of the box, but could limit agility and innovation due to vendor dependency.

On the other hand, Best-of-Breed means choosing the best solution for each function independently (billing, CRM, order management, catalogue, etc.) and then using a systems integrator to knit everything together. Its goal is to provide more flexibility, but often comes with much higher integration costs and potential interoperability challenges.

Whilst best-of-suite and best-of-breed have their ideological supporters, Headless BSS provides a third way. A middle ground where core functions like billing, charging, catalogue and fulfilment remain centralised and pre-integrated, but customer-facing applications such as CRM, self-care portals and apps are decoupled. This approach allows operators to retain flexibility at their points of differentiation, while keeping core processes stable, robust and secure.

TM Forum’s ODA and Open APIs provide the ideal foundation for this:

• Promotes interoperability across multiple vendors
• Reduces integration costs with standardised APIs
• Enables telcos to swap components without massive rework

Operators must balance control, agility, and cost when choosing between Best-of-Breed, Best-of-Suite or Headless BSS. With the industry shifting towards cloud-native, API-first architectures, Headless BSS is now gaining significant momentum.

Conclusion

Headless BSS offers telcos a smarter path to transformation. It acknowledges that legacy systems persist for good reasons, be it customer satisfaction, contractual commitments or business continuity, but also empowers operators to modernise their operations on a module-by-module basis.

Rather than choosing between a full-stack digital overhaul or doing nothing, operators now have a viable alternative: evolve at their own pace, without sacrificing stability or customer experience. As vendors continue to refine modular integration and strengthen breakpoints between front-end and back-end systems, Headless BSS will only continue to grow in importance.

If you would like to know more about deploying Cerillion in a Headless mode, get in touch with our team now.