Friday 4 March 2011

Billing, Charging & Settlement

Originally, telecoms billing was post-paid. In other words, a bill (originally this was generally a paper bill) was generated in arrears periodically stating what was owed to the CSP by the customer. The customer was then expected to settle the bill (payment). The bill would typically show a number of different charges, including "line rental" (a fixed charge to cover the cost of maintaining the line and the network) and "call charges" (a variable charge for calls made).

Telecoms bills were calculated according to a number of parameters. For example, the charge for a call would vary depending on factors such as the time of day, the distance and the duration of the call. Initially, consumer bills were typically summary documents, but later so-called "itemised billing" was introduced, which involves listing the charges for individual calls.

With the advent of mobile/wireless telecoms, a new type of telecoms service - prepaid - was introduced. This involved the customer paying a sum in advance, which was depreciated as telecoms services were consumed. The introduction of prepaid services necessitated a change in technology: the solution that supported "prepaid billing" needed to operate in realtime or near-realtime to ensure that customers could not use more services (and therefore incur more charges) than their balance permitted. Prepaid billing became known as "realtime charging" or "online charging" (to contrast with so-called "offline" billing systems that run in batch).

Realtime charging was typcially implemented using a completely separate infrastructure to the billing systems used to support postpaid or contractual customers.

Although post-paid and prepaid billing and charging were typically implemented separately, lately it has become necessary or desirable to offer more flexible and hybrid billing models. This has resulted in so-called convergent charging, which refers to solutions that can support different subscriber types, different networks and different billing models using a single convergent billing system. Increasingly, convergent charging suppliers emphasise the desirability of basing such as solution on a single data model.

Settlement is the term used to refer to the processes and systems that enable CSPs to pay, and receive payment from, partners and suppliers. This includes Interconnect settlement, as well as settlement with content providers, roaming partners and so on. Settlement solutions also often include billing capabilities, as well as Partner relationship management (PRM) functions, Business intelligence (BI) and so on.

Revenue Management

Revenue management is a Business support systems (BSS) process, and refers to those processes in a communications service provider (CSP) that are concerned with collecting, making and assuring payments for services supplied or received. There are two main processes: collection of payments from customers (consumers and businesses) and collection of payments from partners.

Revenue management encompasses technologies and processes such as: Billing, Charging and Settlement; Revenue assurance and Fraud management; Mediation; Rating; Payment.

In addition to vendors of Commercial off-the-shelf software (COTS), revenue management processes are also supported by custom-built systems (built in-house or by third parties), providers of Managed services and other types of outsourced services and solutions (such as Software as a service).

A specialist form of outsourced services in this area is provided by Clearing houses, which support roaming and interconnect partnerships, as well as data exchange and financial settlement between partners.

BSS OSS Revisited

Business support systems (BSS) is a collective term for the telecoms software solutions used to support customers. The term encompasses software that supports billing & charging; customer management; product design & management; sales & marketing; order & order activation.

BSS contrasts with the related term Operational support systems (OSS), which are network-facing solutions.

In reality the two sets of solutions are closely related and increasingly need to work together, thus the terms BSS/OSS, OSS/BSS, BSSOSS and BOSS are often used. Although there is broad agreement over what BSS encompasses, some types of software sit between the BSS and OSS, and the emphasis on "flow through" processes means the separation of systems into BSS and OSS layers is becoming somewhat artificial. Historically, however, this separation was because two separate departments handled these processes - BSS being handled by IT and OSS by networks. Likewise two sets of vendors supported the layers. As time has gone on many vendors have broadened their portfolios to encompass both BSS and OSS.

BSS support four key processes:

  • Order management - involves taking and handling the customer order. This is now often included as part of the customer management solution and involves a close integration with OSS solutions.

Each of these processes is inter-related, and also increasingly closely aligned to allied OSS processes. Although a process may be technically distinct, it is often from an operational or business perspective embedded in another process or closely aligned to it. Thus order management, for example, is an integral part of customer management, the business driver for the OSS process of Service fulfillment, and closely aligned to Revenue management (since it is imperative to ensure that an ordered service is billed for).