You Cannot Sell What You Cannot Bill For

With the caveat that it has been decades since I was professionally required to think about or write about billing and operations support systems, these days often referred to as converged charging systems, some issues do not seem to have changed. 

The limitations of legacy systems still seem to be an issue. Flexibility, monolithic architectures, high support costs and real-time charging limitations still seem to be issues. The scalability of legacy solutions--seen as limiting the ability to create new products, services or features, remain issues.

The old adage that “one cannot sell a service one cannot bill for” seems to remain a key issue. 

“Legacy BSS systems constrain CSPs’ ability to make timely launches of new products and offerings, or even provide real-time usage and billing information, says Oracle. 

“This put severe limitations on CSPs’ ability to compete with over-the-top (OTT) providers and new entrants,” says Oracle. 

Up to a point, this all makes sense. In principle, the ability to charge for anything, any way, is an advantage. But unlimited capability also tends to come with unlimited cost, and the general rule is that a charging system instance cannot cost more than the item sold. 

source: Vinod Sharma 

A charging instance cannot even cost more than a fraction of the sale price and proceeds. In fact, in many instances, the cost of tracking a discrete event also has to be infinitesimally small, as there might be no direct revenue associated with that instance. 

In a practical sense, converged charging arguably is more relevant as a way of lowering billing instance and overall cost, while supporting real-time charging capabilities that might be needed for on-demand products whose use varies considerably, and whose charging model is based on some combination of usage, services, features, quality metrics, account discounts, payment model and other criteria a marketer might devise. 

These days, converged billing systems also are required by computing-as-a-service suppliers as well. 

The broader trend of billing systems requiring integration with operations support systems was an issue decades ago, and remains a live issue today. Perhaps the big difference is the heightened importance of supporting real-time rating, as more services and features can be created for on-demand use. 

One thing has not changed: service provider charging systems are oriented around customers with whom one has a business relationship. Connectivity provider systems are not designed around users with whom there is no formal business relationship. 

That remains a big difference between “fee for service” business models and “indirect monetization” models used by many application providers. 

App providers who have users and service providers who have customers both need to track usage and identity. But the need to charge is different. Indirect user monetization relies on knowledge of consumption or dwell time, so third-party monetization is possible. 

Some vendors will argue that converged charging systems are required so connectivity providers can “compete” with application providers. That arguably is not the case. A connectivity provider that owns an application with indirect monetization would use the different sorts of tracking systems needed to validate user engagement, based on “users” rather than “customers.” 

Or so it continues to seem.