Uncovering Revenue Leakage Problems in Broadband and Data Services
Alon Aginsky, President, CEO and Co-Founder of cVidya Networks
08/01/2006
Revenue leakage is a problem for virtually every service provider. Analysts commonly estimate leakage at 1–3 percent of revenues for voice services and 10–15 percent of revenues for data services. In the past, service providers detected leakage when it was too late to recoup losses. Given today’s tight margins and competitive landscape, most providers now understand that revenue assurance needs to be a proactive element of every service rollout.
From a 30,000-foot view, service providers must consider revenue assurance from two perspectives. First, there is the charging scheme for their services: volume or time fee-based vs. constant (flat) fee. The second consideration is the underlying delivery technology: circuit-switched vs. packet-switched services.
In this article, we will look at a configuration-based approach to fighting revenue leakage in flat-fee services that are delivered over packet-switched networks.
Where Leaks Occur
Before considering solutions, let’s first look at the various causes and/or data discrepancies that lead to revenue loss. For most service providers, the three primary issues relate to unbilled customers, “mis-billed” customers and stranded assets. Each is discussed below.
Unbilled customers are those not billed for the services they consume. This situation typically occurs when the billing system doesn’t recognize a customer who uses a service. For example, according to the customer database record, the customer is not entitled to use DSL service, and yet the network equipment (DSLAM) is misconfigured to provide access. As a result, a service is given without being billed, resulting in revenue leakage that can be as much as the potential billed amount.
Aside from intentional fraudulent activities, the most common scenarios giving rise to unbilled customer include these:
• A customer subscribed to a service for a trial period, and did not renew the subscription. The customer database was updated, but network provisioning was not.
• Human errors–typing, work order, in the technical work itself—cause a situation in which a customer who did not order a service received it.
• Data corruption due to software errors, machine failure and/or temporary loss of communication between systems that may cut the provisioning process, resulting in data inconsistency. Other exceptional situations exist as well.
“Misbilled” customers are those that are billed the wrong amount for the services consumed. This situation typically takes place when the network is configured to provide the customer with a different service than the one that the customer has subscribed to. For example, the customer has subscribed to 500 Kb/s service but the network is provisioned at 1.5 Mb/s. In this type of situation, the customer uses the service that is actually configured in the network, but the billing system charges the customer according to the service stated in the subscription.
Misbilled customers are a big problem, sometimes affecting up to 10 percent of a typical customer base. These cases involve customers who are not billed for the actual service consumed but instead is billed for a non-consumed service, resulting in revenue leakage or overpayment as high as the charge difference between the two services. Lost revenue is lost immediately. In cases of overpayment, if the operator fails to handle them immediately, they will lead to customer dissatisfaction, churn or the worst form of revenue loss: a class-action lawsuit.
Several scenarios typically cause customers to be misbilled:
• A customer changed the characteristics of a service order after the technical work order was issued—the definitions in the CRM database and the billing system were changed accordingly, but the work order remained the same due to human error or deficient data flow.
• A change was provisioned in the network without the billing system being updated properly.
• Other reasons include a less than optimal change process (either in software, infrastructure or service topology) that may affect the customer, service or contract data. Examples, among others, include special promotions that are not registered correctly and do not expire for some reason, and billing system errors.
“Stranded assets” are another common source of revenue leakage. A stranded asset is a piece of network equipment or service infrastructure that is available for service but that provisioning and/or inventory systems do not recognize as available (or even existent).
The following are the main causes for such stranded assets:
• Customers ceased to consume the service, the disconnection was physically implemented, but the network inventory database was not updated.
• The customer churned away (to another service provider) but no disconnection procedure was executed.
False indications that equipment is unavailable cause unnecessary investment in new equipment. Although this may be considered an over-cost issue, it is still in the domain of revenue assurance, since it indicates less than optimal processes and resource allocation that result in excessive capital expenses (CapEx). The magnitude of the problem can reach up to hundreds of stranded terabytes of unused but potentially billable traffic.
Revenue Assurance Approaches
The key to preventing leakage from unbilled customers, mis-billed customers and stranded assets is to eliminate the gap between the perceived billing information, which the operator is using to charge its customers, and the actual data that reflects the real use of services and resources by the customers.
Typically, a provider has two options: configuration-based and usage based Approaches. In the configuration-based approach, the RA process checks the static data integrity and finds discrepancies between the different systems and databases involved in the revenue chain. In the usage-based approach, the RA process checks the flow of usage files, records, total amounts, contents, and the aggregated figures and reports discrepancies found.
Packet-based services impose several limitations on usage-based methodologies. Very often, the network-to-bill chain of systems does not provide enough information to shed light on all the dimensions of a delivered service—crucial elements of information about the user, service, content and network equipment utilization are missing.
Second, it is not possible to conclude that there is a revenue or cost issue with unutilized equipment, based solely upon usage information analysis, as there may be many reasons for which network equipment is unutilized, for even a significant period of time. What’s more, this network equipment needs to remain with the same settings and registration, as the subscriber may need it.
Additionally, when services are charged with flat-rate fees, the usage information is usually dropped by mediation systems so as not to create an overload on the rating and billing system.
For these reasons, we believe a configuration-based solution often makes the most sense for most data services.
Configuration-Based RA
In the configuration-based approach, the operator looks for discrepancies between different data repositories within the service delivery, operational and business systems, and quantifies the financial impact of the discrepancies found. Typical repositories include:
• Customer contracts (which may reside in the CRM or billing systems)
• Customer reference data in the billing system
• Network equipment status information gathered from configuration management components of network management solutions
• Network inventory database
• Database of customer orders
• Other configuration information, wherever it may be.
Finding discrepancies between these repositories requires analysis of the business process-related information flow between the various systems (for example, the parameters provisioned in the network and the billing system within the course of a service provisioning process), analysis of the representation of the various data items within each of the involved systems (for example, the customer information as represented in the order management, CRM and billing systems), and the applied timelines (for example, provisioning one type of service may take seconds, while another may take days or even weeks). Based upon such analysis, the operator can take the data bits from various repositories and compare them to each other in the relevant context and timing.
While interfaces are often technically simple, the main issue they present is getting to the owner of the information and extracting the correct data from the databases. Since the solution is based upon configuration data, which is relatively stable, storage of the raw data in a revenue assurance software solution can be for only a relatively short time.
Consider the following examples:
A tier 1 European operator had customers registered as paying by volume, but due to a flaw in the business rules, the mediation system had wrong data in a reference table. As a result, it considered these customers as flat fee-based customers, and discarded the actual usage data related to them. The rating system correctly recognized these customers as pay-by-volume, but it didn’t receive any usage volume and hence did not charge those customers at all. A revenue assurance system that discovered this phenomenon provided indications that helped the operator correct the process and update the reference data used by the mediation system, and thereby gain the ability to charge these customers accurately.
Another operator installed new equipment due to the large growth of its customer base. During the installation, many residential customers were ported from old to new facilities. However, some port configurations were not re-recorded correctly in the network inventory system. Also, some connections that were released during the transition, appeared in the data inventory system as being in use. These stranded assets were revealed by reconciling the network inventory system data with a snapshot of the connectivity status of the equipment. The newly available ports that were discovered helped the operator handle hundreds of terabytes of billable traffic without the need to purchase additional network elements.
In another case, an operator used a third-party technician to deploy residential ADSL service. Often CPE required manual installation and configuration of the modem and connectivity parameters in the network. If customers changed their mind and asked for a higher bandwidth in the interim between the initial order and the technician visit, they got their connection configured to support high bandwidth, but the CRM and billing systems were configured to reflect the lower bandwidth terms and charges. These mis-billed customers were found as a result of reconciliation between the actual configuration of the network and the customer contract terms in the CRM system. The operator could then update the connectivity parameters to provide the customer with the correct service defined in the contract. Alternatively, the operator could consult with the customer, then update the contract and payment terms to agree with the higher bandwidth service provided.
Future Services
The legacy PSTN-based types of telecommunication services provided the luxury of relatively simple representation of the service structure and the charging scheme. For these technologies, the usage-based RA approach made sense when dealing with most of the revenue leakage risks. But that approach cannot handle some of the new leakage risks posed by IP-based technologies such as IPTV, triple and quad play, and IMS. Configuration-based revenue assurance, on the other hand, is much more suitable for addressing these new types of challenges. The reason may be found in one of the fundamental differences between usage- and configuration-based approaches.
The usage-based approach relies on the fact that usage of the service is recorded in a consistent manner, which can be addressed and referenced. If usage data is not available (as in the case of flat fee, where an operator may decide not to collect usage data at all), or if the usage data is collected inconsistently (for example, optional inclusion of content type or content parameters), then using the data for reconciliation is much more complex and difficult.
The configuration-based approach, on the other hand, only needs the static information held in different systems, and can absorb format differences, update timing differences, and different—maybe even inconsistent—structures. Another characteristic of increasingly IP-based services is the greater openness of the telecommunication service infrastructure and, as a result, the growing variety of OSS and BSS residing side by side that will be needed in order to cope with new dimensions of flexibility and complexity of service deployment and operation. Usage-based revenue assurance will miss a lot of the potential financial and operational risks resulting from this evolution of telecommunication services.
Conclusion
The science of revenue assurance is not a perfect one, but all the same it is one that can save operators millions of dollars. As with many other business matters, there is no magic formula that instantly dissolves all revenue assurance issues. For the spectrum of problems cited above, the configuration-based methodology can provide a fast and prompt solution to existing risks, as well as an infrastructure for a set of practices to help the operator proactively attack the problems mentioned above, rather than merely reactive responses.
Nevertheless, the future of revenue assurance involves more than just proactively fighting potential leaks. We feel that ultimately RA should be bundled into any rollout of services, to prevent leakage before it happens. As providers roll out IPTV and triple play, they will be wise to incorporate an RA solution to catch billing discrepancies and stranded assets before they get out of hand.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article