With banking being the hot topic at the moment, I thought it would be a good idea to look at the next generation of Telecoms services - the mobile credit card(mobile wallet). For years the Telco industry watched the banking sector with envy, they’ve seen them making up to 7% on every credit card tansaction and how - by having a fixed line telecoms network into all retail outlets and (supposedly) oodles of cash to lend to the consumers. 

The mobile industry spotted the synergies between the banks and themselves and decided that they could offer the same services(all be it by sitting on the back of the existing architecture),  the operators have acquired banking licenses and now a few years on, the service would appear to be ready for launch - the idea being that you’ll swipe your phone instead of your credit card

So the question/discussion I wanted to have is: What does this all mean for Revenue Assurance?

There are a few topics that need to be considered:

Regulatory - currently operators only have to deal with Ofcom, however by offering credit card services things like the consumer credit act come into play as well as bodies like the FSA

Technically - To offer credit card services, the operators are going to have to add new systems - a seperate billing system  for credit card transactions(I would hope), seperate accounting, third party revenue share systems, maybe seperate CRM.

Fraud - Obviously the scope for fraud grows 10-fold by introducing consumer credit. Credit card companies charge high interest to cover the cost of fraud, so what are the implcations for the operators?

Revenue Assurance - where do we start? There will be the need for transactional monitoring systems ie all events pass from A to B successfully, rating assurance -  interest charges are applied correctly, billing verification, third party revenue share assurance etc etc. 

 For anyone thinking this doesn’t sound too complex consider the following scenario : I pay for my mobile phone bill via direct debit to my mobile credit card, upon receipt of my phone bill I notice that I have been charged 2 line rentals. I contact the operator and tell them of the mistake and they promise to reverse the mistake on the next bill. I do not pay off my credit card this month and as a result pay interest against the balance - including the extra line rental. Who owes me the interest?

The Mobile Credit Card is probably going to be the single biggest change to Revenue Assurance that we will ever see. Whether the operators push forward with it in the current economic climate is still to be seen, however if they do - what do we need to do to be ready?

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?