This question is a follow on from the previous impossible mission question posted a few weeks ago.  One of the comments posted on the question asked whether the problem of un-linkable data was a Revenue Assurance issue? I think this is an interesting question and would like to hear other readers views before posting my own.

I think the easiest way to explain why setting a fixed rate KPI against revenue reclamation doesn’t work is to first look at a couple of  revenue loss scenarios per revenue stream

One Off System Faults 

• A pre-pay billing system collapses for a period of time, during that period all calls are free.  Recovery 0%
• A post-pay billing system collapses for a period of time, during that period no calls are rated. The CDR’s can be re-processed and recovery is 100%

Erroneous Reference Data

• A pre-pay billing system is rating calls at 1p instead of 10p. You can’t back bill. Recovery 0%
• A post-pay rating engine is rating calls at 1p instead of 10p, dependant on local regulations, duration of issue, company politics etc Recovery 0 to 100%

Now just from the above couple of examples, it’s plain to see that there is a drastic difference between recovery in pre-paid revenue loss to that of post paid revenue loss. This is mainly due to the fact that pre-paid recovery is rare(not impossible), so therefore when defining recovery KPI’s the first thing you need to do is seperate your revenue streams.

What is Recovery?

This seems like an easy/obvious answer - however when you bring in the subject of opportunity loss, is it so clear?  Well, can you recover an opportunity loss? - some people will say that because there is no billing error with an opportunity loss just a service prevention, there is no revenue to recover. However others will say, that by enabling the service to be used, the revenues that are achieved going forward are the recovery. The debate then grows into: if forward billing is classified as recovery, do we therefore have to track all customer accounts forever and if so how can we have KPI’s?  This debate can escalate exponentially and until there is a standard definition, any work on KPI’s and other standard measures is pointless.

I personally believe that to make life simple, recovery can only relate to revenues already lost(the stuff in the past) for resolution of opportunity losses and the ongoing revenues from fixing a recovery I would term these as Benefits. (Please note I’m really watering things down here, there are many more Benefits that need to be defined like OPEX and CAPEX savings resulting from any resolution)

Does Maturity Impact Recovery?

Of course it does!

I’m not going to write too much here(I’ve already written more than I’d wanted to), but quite simply the level of maturity of a function dictates the types of Revenue Loss that’s identified and as we’ve already seen “type” dictates recovery.

Summing Up

If we define recoverable leakages as being the moneys that should have been billed, but for some reason haven’t. Then what we are looking at is something we really have no control over. Pre-paid revenues generally can’t be recovered and post paid revenues are so wrapped up in regulations and customer choice that again we have little or no control over reclaiming this money. What we do have control over are the Benefits, every attempted recovery should have an associated benefit no matter what the type of loss

I’m sure that the headline of “Operators Recover Only a Third of Indentified Revenue Leakages” is statistically about right if you exclude all of the un-recoverable loss types stated above. Ultimately though, in the case of the majority of African Operators (99% prepaid), what you are talking about less than 1%(financially) of issues they will identify, therefore the KPI is pretyy much pointless.

If we want to look at Revenue Assurance as a whole, then a better study would be to look at All of the assoicated Benefits of each revenue leakage prevented/recovered 

A complete change of question this week.  I saw this article and it made me chuckle, especially  “This study is a considerable breakthrough in the field of Revenue assurance KPI’s measurements,”

I’m sure I’m not the only person who has quoted the one third rule as a “nice average” for at least the last 5 years and I hope I’m not the only person who knows why it can’t be used as a KPI - so that’s this weeks question - why can’t 33% be used as a KPI for leakage recovery

There are a few options available to us when data is not directly reconcilable. All of which hold benefits and pitfalls - so I’ll let you decide which is best:

1) Data Enrichment - In the majority of cases it will be possible to find a tertiary data set that can enrich your primary source to allow the reconciliation to take place. However it’s not just a simple case of updating one side of the reconciliation and proceeding as standard. Certain decisions need to be made:

• Which data set do you enrich? ie network, billing or both
• How to treat records that cannot be enriched?
• How to treat duplicate enrichments?
• How to perform the reconciliation - it’s technically now a 3 way rec, so should be dealt with accordingly

 2) High Level Reconciliation - Even if data is not directly linkable at the individual record level, it is more than likely still possible to reconcile at a grouped level ie total active network customers Vs total billed customers. However, if you perform a reconciliation at this level there are certain risks/issues:

• RA Equilibrium - you lose visibility of the individual issues and just see the net effect ie in its worse case you are overcharging 50% of customers and under charging the other 50%, however due to a high level reconciliation you see the net effect of perfect billing.
• Revenue Loss/Gain - the high level reconciliation shows a tangible error,  in this case you can’t fix anything as you don’t have detailed results so you end up having to perform the detailed reconciliation anyway.

To avoid issues the simple trick is to perform the reconciliation multiple times at different grouping levels, it will avoid the equilibrium issue and should enable you to isolate specific issues - thus avoiding an all encompassing detailed reconciliation.

3) Data Source/Process Enhancement - Quite simply, get the original data sources enhanced by their business owners to include a common key.  RA isn’t just about finding money, it’s also about ensuring good business process to reduce the risk levels against the company’s revenues. Clearly if there is no direct link between a customers product and their bill then there is an associated risk.

Summary

Ultimately the way I like to deal with these situations is by consolidating the above 3 options. Firstly I would perform the high level reconciliation - this will generally find risks and issues, that will allow you to justify the need for a business process enhancement by the data owners. To assist the data owners with the enhancement I would then perform a one off data enrichment exercise - identifying all records that can be easily updated and isolating the areas at risk. Eventually we end up with a fully cleaned system that can be monitored with ease going forward.

For this weeks question, I want to discuss one of the most annoying parts of working in RA - When data doesn’t link. A typical example is a network to billing reconciliation of the ADSL product. Typicallly a DSLAM will only contain information like dslam id, port, slot and maybe an IP address whereas the billing system will generally have some sort of service identifier along with associated billing information. The data as such is un-linkable and therefore would appear non-reconcilable - what would you do in this scenario?

There are a number of ways you can find quick RA wins within an operator, the following are just a few tips for routing out the low hanging fruit:

1) Existing Reports - Most departments produce there own reports detailing customer numbers, system throughputs, revenues etc.  Take these reports and compare the numbers ie NOC customer numbers vs Finance customer numbers - quite often you’ll find large differences that indicate that some sort of problem exists

2) Interviews - Try and identify the key personnel who have manual processes that are Revenue critical - ie someone who manually inputs service orders. Interview the SME and you may find serious control weaknesses that indicate a potential revenue loss

3) The Internet - This is my favourite and the easiest way to find revenue loss(fraud). Go online and search the internet for free calls with your operator. You’ll find a number of chat sites where people swap tricks for getting free calls - test out what they say - you may get lucky.

4) Customer Services - When customers get over-charged they’ll complain, these complaints will be logged in a CRM system and hopefully categorised.  Try and identify the most common complaint - obviously what you’ll have is a Revenue Gain issue, but if the issue is the result of a system failure/problem you’ll often find that the inverse issue exists whereby customers are being under-charged.

The above are just a few tricks that can be used, but the basic theme is simple - when faced with short timescales, don’t try and source your own data just use what’s already available.

This weeks question is more of a general discussion topic, which I would be very interested in hearing peoples opinions.

As a consultant I am often asked to find a quick win, either to demonstrate a teams capability or to get executive buy in. To do this I have a number of tricks/tactics that can often flush out a small amount of revenue loss.

I’d like to know, how other people deal with this type of request

For this weeks question, the route cause was one of many possibilities that were investigated. The actual issue was identified after validating data used for performing a prepaid balance audit.

A prepaid balance audit is a simple control whereby the following steps are conducted:

Step 1: At a fixed point in time record the total amount of credit held on your prepaid billing system

Step 2: Record the total number of credits(top ups) to the prepay billing system for a given period(say 24hrs) - use an external source like the prepaid card database along with any other crediting mechanisms

Step 3: Record the total amount of debits from prepaid accounts for the same period(as a negative number)

Step 4: at the end of the period record the total credit held on the prepaid billing system

Step 5: Perform the following reconciliation:  1 + 2 + 3 = 4

Now the above didn’t identify the issue, however by validating Step 2 against cash received for sales of top up cards we could see that there was a general issue, where more credits were being applied to the prepaid billing system than those being sold.

For this week’s question I’m going to return to the subject of fraud and it’s cross-over into Revenue Assurance analysis.

Whilst working for a mobile phone operator, it was identified that someone in the prepaid top up card printing factory had been copying down the card’s unique codes and topping up their own account.

How would you identify this issue?

To resolve this week’s issue, we went for the most obvious resolution path and performed a CDR to SS7 reconciliation against a days worth of traffic. After performing the reconciliation, we were still left with a large amount of SS7 records with billable duration that didn’t match to CDR’s.  So we then started to analyse these SS7 records and the underlying customers ie

Had the customers produced any CDR’s - Yes,

Were calls to the specific destinations producing CDR’s - Yes,

Was it a specific duration issue - No,

Was there a unique flag on the SS7 record - No,

Did the SS7 records just originate from one switch - No - but not the entire network.

It was this last point that started to hone us in on the actual issue, all of the additional SS7 records came from a specific region of the country, which was served by 8 switches.  According to the company’s engineers, there was nothing unique with this part of the network, so it was back to the analysis.  At this point we started to look at individual customers calling profiles and it was when we did this that we found the problem. We effectively had duplicate SS7 records - although they weren’t true duplicates in that the call times and durations were ever so slightly different. We had duplicate checked the data right at the beginning of the analysis (as any good analyst will do), however because the records were different - they weren’t flagged up to us. 

Each pair of SS7 records were being recorded by different probes, the overall SS7 solution worked in such a way that only the originating probe generated the dummy SS7 CDR, so the fact there were two records, both stating they were the originating probe, suggested something was wrong with the network ie double call routing. At this point the issue was handed back to the engineers to work out what the cause was.

The network had originally operated an “A-Link” signalling network (signalling that goes down it’s own pipe via an SCP), however the operator had moved to an “F-Link signalling network (signalling is carried by the same pipe as the call) a few years prior to the investigation described above.  The old A-Link signalling was supposed to have been fully decommissioned once the new F-Link was put in place, however it transpired that in this region of the country, the decommissioning had somehow been missed. So what was happening, was that for each call being made, the signalling was being sent across two pipes and hence two originating SS7 probe CDR’s were being made -as there was a probe on every part of the signalling network(I know - you would have thought they would have spotted the issue when installing the probes!!)

An SS7 to CDR reconciliation is one of the best pieces of analysis an RA department can perform - it allows us to verify the one piece of information we rely on for the majority of our other reconciliations (the switch CDR). Ultimately though, I hope the above issue has demonstrated that an SS7 record cannot be treated as definitive and does require the same levels of authentication as any other record produced by a network.