Own the relationship: subscription bundling beyond the BSS bottleneck

BSS stands for Business Support Systems: the billing, product catalog and customer management platforms that sit at the center of telecommunications operations. They are essential systems, but they were built around products the operator owns. Subscription bundling adds third-party services with partner-controlled pricing, APIs, trial terms and lifecycle changes. That mismatch is why a promising bundle can become another IT project before it reaches customers.

Subscription bundling has moved from experiment to commercial priority for operators. Customers want better value from the digital services they already use. Operators want stronger loyalty, lower churn, new revenue and a more compelling reason for customers to stay. Content providers want distribution at scale, with partners that can bring net new paying subscribers to them in large numbers.

The demand is there. The commercial case is there. So why are many operators still moving slowly?

Bango research shows that 62% of subscribers say they would be more loyal to a telco offering subscription bundles, while 51% want better value from bundled subscriptions. The results are already visible in market: Verizon has reported a 60–70% churn reduction from bundling, while Telenet reported a 26% churn reduction among customers taking a bundle. Sky’s Ultimate TV Bundle is another example of how a multi-service offer can make a 24-month contract renewal more compelling. The bundle becomes the reason to stay, not broadband alone.

The difference between bundling and owning the relationship

It is worth being precise about what subscription bundling means. Bundling is not new. Third-party distribution is not new. Vouchers are not new. Inclusive hard bundles are not new. What is different here is the commercial relationship. A true subscription bundle puts the third-party subscription cost onto the telco bill. The operator owns the customer relationship, controls the billing lifecycle and captures the revenue through its own channel.

That distinction is important. A voucher can help with short-term acquisition, but it often sends the customer back to the content provider. An inclusive hard bundle can support a retention goal, but it does not always create a new third-party subscription revenue line. Subscription bundling changes the role of the operator. The operator moves from passing customers through to owning the commercial relationship.

Early movers are learning faster

Operators like Sky, Comcast and Verizon are no longer testing bundle one. They are on bundle three, four or later. Each launch gives them more information about what customers buy, what they keep, which partners perform and how to package the next offer.

That does not mean the gap cannot be closed. It means operators still on their first bundle need a faster route to market. Early movers have more evidence, but their lead comes from repeated launches, not from one perfect offer. An operator that can act fast can still catch up: launch, measure, refine and move to the next bundle. The real risk is not launching later than others. It is launching later with a model that only gives the business one serious attempt per year.

Adding one major streaming service to a mobile or broadband plan can still have value, but the market is moving past the novelty stage. Customers are used to seeing subscriptions attached to connectivity. Differentiation now comes from the quality of the bundle, the relevance of the services, the way offers are packaged and the speed at which an operator can react when customer demand changes.

The business case is there. Then it hits the IT queue

In many operators, the idea is not the problem. The proposition is agreed. Marketing is ready. The commercial case has been signed off. The numbers work. Subscription bundling is in the plan as a business strategy, to use third-party services to support the operator’s own business objectives.

Then it goes to IT.

What began as a growth plan becomes another IT project involving the Business Support System (BSS). The subscription bundle sits next to the platform migration, the compliance work, the product catalog work, the mobility plan refresh and every other program already committed for the year. The bundle may be commercially valuable, but now it must compete for the same engineering capacity as everything else.

First-party systems were built for first-party services

BSS platforms are central to how operators run. They manage billing, products, customers, service and operational control at enormous scale. They are systems doing the job they were built to do. The feature list matches to subscription bundling, but the job does not.

The problem starts when they are asked to support a type of product they were not designed to manage.

A first-party product catalog assumes the operator owns the product definition. The operator sets the price, defines the tiers, controls the lifecycle and schedules the change. That model works when the product is mobile, broadband or pay TV package. It starts to break when the product is Netflix, Disney+, Paramount+ or Apple TV+. The operator no longer owns the price decision, the API, the trial terms, the promotional model or the product roadmap. The content provider does.

That creates a mismatch between the customer journey and the systems behind it. To the customer, the experience should feel simple: one bundle, one bill, one place to manage the relationship. Inside the operator, that simplicity can hide a growing operational load. The content provider changes something. The operator has to mirror it. The partner changes the price. The operator must update the catalog. The provider changes trial terms. The lifecycle logic must catch up.

The more successful the bundle, the heavier the load

At first, teams use what they already have. Entitlement logic gets connected. Provisioning is built. Third-party products are represented inside the first-party catalog as that is where billing lives. Technically, it can work. Commercially, it creates a long-term dependency on every decision every content provider makes.

One partner may be manageable. Three partners create more work. Five partners can become a standing maintenance program inside core infrastructure. Every licensing change, promotional offer, price update and plan change must find its way back through engineering, testing and release. The more successful the bundle program becomes, the more weight it adds to systems that were built for a different job.

One project per year becomes a hard cap on growth

That weight changes the economics of launch. When every bundle needs BSS work by engineers, many operators end up with one subscription bundling project per year. The first bundle goes live. The product/engineering team then needs time to prove subscriber uptake, ARPU impact, churn benefit and operational load. That proof does not arrive after a few weeks. It often needs several months of live performance before anyone can make the case for the next bundle.

By the time the results are ready, the next internal case is written and the build queue opens, bundle two may already be two years away. If bundle one underperforms, the issue is worse. The team is not just waiting for another project slot. It may have to rebuild the case for subscription bundling from the beginning.

This is more than delay. It is a hard cap on the number of commercial attempts an operator gets. Leading telcos are testing version three or four while others are still asking for build slot two. That gap is not just about time to market. It is about learning. Every launch teaches the operator which services convert, which customers retain, which price points work and which partner combinations deserve more focus.

A slow build model makes every bundle carry too much pressure. Bundle one must be the proof point, the test case and the internal case for bundle two. That is a lot to ask from a first attempt, especially in a category where customer demand, content rights, pricing and promotional terms keep moving.This shift – from projects to platform – is what allows subscription bundling to move from experimentation to sustained growth. 

Customer journeys are where the mismatch shows

The customer journey issue becomes sharper when the bundle is live. It is one thing to launch a bundle. It is another to run it through the full lifecycle of plan changes, upgrades, downgrades, renewals, promotional periods and partner updates. This is where first-party systems can look “ready” on a feature checklist, but still struggle with the reality of the journey.

The catalog issue is one part. A first-party catalog is designed around products the operator controls. When a third-party product is added, the catalog becomes a representation of someone else’s offer. It must mirror decisions made outside the operator. If the content provider changes a tier, updates pricing or alters a promotional period, the telco system must catch up.

Plan lifecycle is the other part. Subscription bundling is meant to give the operator ownership of the billing relationship. That is the whole point. The bundle is on the telco bill. The customer relationship sits with the telco. Churn means leaving the operator’s bundle, not just cancelling a separate streaming account.

However, owning the billing relationship means owning the lifecycle. That gets hard when each provider has its own terms, APIs, trial logic, offers and timing. Netflix changes trial terms. HBO Max adds an ad tier. Disney changes pricing. Same subscriber. Same quarter. Different external events. The customer still expects one simple bundle experience.

The operator then has a choice. It can simplify the lifecycle and lose some fidelity to what the provider offers. Or it can build custom lifecycle logic for each provider and turn every new partner into another engineering project. Neither option helps a bundling strategy scale beyond a small number of offers.

Price changes expose the bottleneck

Let’s look at a price change in depth to demonstrate the challenge.

A subscription content provider changes wholesale pricing. Three weeks’ notice may feel short inside an operator, but in the content market it can be normal. Studio costs move. Rights deals change. Libraries are acquired and dropped. Promotional terms move. Content providers are responding to their own market pressure and their own subscriber economics.

The operator has a different clock. If the price change has to be reflected in the first-party product catalog, it may need an engineering ticket, planning, testing and release. In one real operator example discussed in the session, a price change needed to be handled in three days. IT had just entered a new development cycle and said the change would take 12 weeks to roll out. The workaround was painful: apply the change into the BSS later, then ask customer service to apply the extra amount to customer bills manually each month until the system caught up.

That is not just an IT inconvenience. It creates risk across the business case. Manual charging adds error risk. Errors create service calls. Service calls add cost. Customer confusion damages trust. Margin may be lost while the ticket clears. The operator may delay the offer. It may push back on the partner. None of those are good commercial options.

This is the BSS bottleneck in practical terms. The content provider moves at market pace. The operator moves at IT queue pace. The customer still expects one bundle, one bill and one simple relationship.

End-to-end needs to mean billing, not just provisioning

That is why “end-to-end” needs a stricter meaning in subscription bundling.

End-to-end is not just entitlement management. It is not just API abstraction. It is not just provisioning kept consistent across content providers. Those things are useful, but they solve only part of the problem. If catalog, charging and plan lifecycle are still held inside first-party systems, the operator is still left managing third-party change through first-party infrastructure.

Vouchers do not solve this for telcos that want the ongoing relationship. They can support acquisition, but they do not give the operator the same billing lifecycle control and the top line revenue. Entitlement-only approaches can connect to content providers, but the billing layer remains inside the operator’s own stack. The content provider side may be abstracted, while the operator side still carries the catalog work, the price-change work and the lifecycle work.

Solving half the problem leaves half the problem.

True end-to-end means the provisioning layer and the billing layer. It means a catalog built for partner change, with price changes handled outside the telco IT queue. It means lifecycle control across every bundle, without rebuilding each provider’s logic inside the operator’s own systems.

Bango DVM™ puts bundling outside the first-party product stack

The Bango DVM handles the work required to sustain that model across multiple content providers, each with different APIs, pricing, promotional terms and lifecycle logic. The operator owns the subscriber relationship, the billing lifecycle and the commercial relationship.

The aim is not to build a better version of the operator’s billing system. The aim is to stop asking the billing system to solve a problem it was not designed for.

The Bango DVM starts from a different question: what does subscription bundling infrastructure need from day one? The answer is not just partner connectivity. It needs catalog, lifecycle, provisioning and charging designed around third-party subscription change. It needs to support multi-party bundles, price changes, upgrades, downgrades and promotions without turning each variation into operator-side complexity.

The Bango DVM catalog is built for the market, not the operator’s internal architecture. When a content provider updates pricing or promotional terms, the catalog can reflect it without rebuilding that product inside the BSS. Add a partner, update a bundle or change an offer: it becomes catalog work inside the subscription bundling layer, not a new engineering dependency inside first-party systems.

Price change handling follows the same logic. When a content provider changes pricing, the Bango DVM can receive the change, process it and execute the operator’s configured response, including charging, subscriber communication and lifecycle update. The operator defines the commercial response. The Bango DVM executes it. The event does not need to travel through the operator’s internal change queue.

Lifecycle ownership also becomes more manageable. The operator still owns the billing relationship, the upgrade path and the moment a subscriber considers leaving. That does not change. What changes is where the content-provider complexity sits. The Bango DVM sits between the operator and the providers, abstracting different APIs, lifecycle logic and promotional timing so the operator manages one bundled subscription experience.

More launches mean better bundles

When launching a bundle no longer requires months of BSS work, the one-project-a-year cap starts to lift and the project economics begin to change. The first bundle gets a fairer test. If it underperforms, the team can adjust the offer, price or partner mix. They are testing the commercial idea, not the billing backlog.

That distinction is vital. A bundle should succeed or fail on customer demand, proposition strength, pricing, partner relevance and promotion. It should not fail as a result of catalog overhead, lifecycle edge cases or delays that have little to do with the customer offer itself.

Every delayed launch also carries an opportunity cost. Each month spent waiting for a build slot is a month not testing a new partner mix, not learning which services customers keep, not proving which offers reduce churn and not giving content providers a reason to bring the next deal. The cost is not only the project. It is the learning the operator never gets.

This is where early movers are building their real advantage. They are not ahead simply as they launched first. They are ahead as they have had more chances to learn. More launches mean more feedback. More feedback means better offers. Better offers mean stronger retention, higher ARPU and a more compelling reason for customers to keep the operator relationship.

For operators still behind those market leaders, speed is the catch-up route. The gap can close, but only if the launch model changes. An operator that can move from bundle one to bundle two quickly can start to build the same learning curve: launch, measure, refine, launch again. An operator waiting for the next annual build slot gives the leaders another year of evidence, customer insight and partner confidence.

The lesson is direct. Subscription bundling should not be treated as a one-off IT build. It is a repeatable commercial capability. The winners will be the operators that can launch, learn, adjust and launch again while keeping the customer relationship on their bill.

Operators that have not launched are not short of ambition. The commercial case is there. Customer demand is there. The blocker is how bundles are launched, run and changed after launch. It is no longer about deciding to bundle. It is about how many attempts an operator gets before the gap becomes too hard to close.

Own the relationship. End-to-end. That is how subscription bundling moves beyond the BSS bottleneck.