Proactive Revenue Assurance

Here’s a new thought. What exactly would we term (correctly) as proactive Revenue Assurance? I have seen quite a few scenarios where an operator claims that he has a proactive check system in place, but on further analysis, we find that it isn’t truly proactive, but merely reactive with a much smaller time period of detection and rectification.

It got me thinking about the nature of revenue leakage. When we take a step back and look at the big picture, we see that a leakage happens due to unforeseen eventualities, misconfigurations/omissions, poor system integrations or maybe even internal fraud. In none of the above cases (which are but a few of the reasons for revenue leakage) can we truly say that we are capturing all leakages. How would we go about proactively checking for integrity/completeness?

In my experience, I find that to a certain level, we can perform proactive checks as far as subscription data is concerned. Standard checks like Subscriber feature information matching between HLR, Provisioning and Billing etc. would in some ways prevent revenue leakages proactively(if the Subscription Data integrity is maintained, we find that many common scenarios which would come in usage data also reduce). Issues in usage data like usage not being billed can be attributed to unsynchronized subscription information across the Provisioning system and Billing system. I have seen cases where a subscriber is provisioned for certain services at the switch but the same set of services is missing in the billing system. What happens in such a case is that the subscriber uses certain services (eg. Voicemail), but won’t have to pay anything for the same.

For usage data (i.e. XDRs), I find that most proactive checks still require at least a minor amount of leakage to occur before an alarm is triggered. The only true way to perform proactive revenue assurance as far as usage data is concerned is to either ensure all root-cause possibilites are covered and alarms are set-up at the core level rather than at the data output level(which is a massive task), or have a RA test bed before launching any service into a production environment (we could scale down the total load to consider). Using the test bed approach, we could effectively run RA metrics to verify absence of leakages, as well as capture issues at an early stage. Once the RA department clears the new service/product, it could be launched into production. Once again, this would not give us a 100% assurance of no revenue leakages.

Any other suggestions for Proactive RA?

Ashwin Menon
Ashwin Menon began his foray into revenue assurance as an implementation on-site engineer with Subex Ltd. During the course of his career, he has been involved with various clients across the Asia-Pacific region, including tier 1 telcos. He is currently employed at Subex as a Senior Consultant.