Anyone want a Revenue Assurance tool?

Fear not, this blog is not trying to change the focus of talkRA from open discussion to an off shoot of eBay for previously loved, only one owner,  RA tools.

The question is to what extent is it essential that the software tools that RA analysts use to identify leakage, be designed with RA specifically in mind. In the early days of RA in an operator, I am sure many of us started with multi purpose desktop applications like Excel, Access, ACL etc and then, assuming the business case was proven, we were able to move up to a “proper” revenue assurance application, sitting on a nice big server and letting us grow the volume of data we could analyse, increase the speed of processing, build repeatable RA analytics and provide coverage across more revenue streams etc.

It is always interesting to observe how RA tools are often represented and this as solving known problems to find untapped revenue potential. It makes sense to state that “by using tool A, operator B was able to reconcile revenue systems C with D and found E millions of dollars”. So by induction if you deploy tool A, then you can do the same type of reconciliation and find E millions yourself, or you might not find E millions but at least you can tell your management, with confidence, that C and D are functioning effectively.

However, knowing what has happened in the past does not always guarantee that we can know what will happen in the future. Firstly, it seems that recalls of the past seem to be represented very linearly. By that I mean, A did B, C did D, but because E then did F, we had a revenue loss. In the present we seem to rarely move uninformly and seemlessly from one activity to the next but our understanding of the past, and what may or may not have been relevant,  seems to be predicated on diligent pursuit along a steady and unwavering path. Secondly, if looking at the past could predict the future, then the global economic crisis, for example, should not have been surprise to anyone. Simply put, the past does not always provide adequate indication of the future and we should see this in RA – B and C don’t reconcile and we lost E; therefore F and G won’t reconcile so we will lose H. These sums rarely add up as expected and if they do it is probably more by chance than good modeling.

If a revenue assurance tool has been designed for revenue assurance, then by definition, its functionality must be built on a combination of historical knowledge of loss as well as prediction of where leakage will occur in the future. What many service providers are going through now is a period of radical change across their products and services, the infrastructure that supports them and the processes that are wrapped around them. The uniqueness of everyone’s operating environment means that new and unexpected (and so be definition “not predicted”)  issues are arising more, rather than less, frequently.

My contention is that what is needed from an RA tool is not one that necessarily predicts where loss is, but one that is prepared for loss. By this, I mean one that has the necessary agility to provide timely and insightful analysis into an operational area and to drive greater insight into what is happening. This is about flexibility in the ability to read all manner of data, configure the appropriate logic and provide a meaningful output. If we could predict where the future loss would be, we could address this before it happens, but our predictions are rarely accurate enough to enable correctly targeted, preventative action to be implemented. The tool that is required needs to find both the “we think something is wrong here” issues as well as the “we didn’t even think that when we did action A that action B would occur”.

To my original question – RA analysts do need a tool but a tool predicated only on assumptions of past loss will address only some of the issues; what is needed is a tool also ready to handle the next generation of new and unpredicted business problems.

Mike Willett
Mike Willett
Mike is a Partner at Ernst & Young, Australia. He is responsible for enterprise intelligence, helping clients to improve their management and use of data. He can be contacted at:

Mike was previously the Director for Fraud & Revenue Assurance at Telstra. He started his career at BellSouth (now Vodafone) in New Zealand and then moved to Praesidium Services in the UK. Mike graduated from the University of Auckland in New Zealand with degrees in psychology and marketing.

2 Comments on "Anyone want a Revenue Assurance tool?"

  1. While there is a place for tools within RA, I found that much of what we did could be managed through simple tools, such as Access, with the intelligence contained within the Analysts. By using simple tools, one is able to quickly move the tool across into different revenue straeams without requiring any major develoment. It also encourages the analysts to look at other possible uses for th data, which then expands their role into a much wider remit and provides better visibility to the business. A simple example, by looking at the traffic levels by destination code by carrier, RA was able to identify changes in levels well before Carriers would normally have visibility. The issue is not around missing CDRs, the issue is around other carriers migrating traffic away for commercial reasons and responding in a more timely manner to the threat of losing revenue – that to me is assuring the continuation of that revenue stream at the level required by the business.
    So simple tools, with the intelligence in the Analysts provides a better return, in my opinion.

  2. Avatar Mike Willett | 23 Apr 2009 at 11:47 am |

    Thanks Mark,

    Very valid point and articulates nicely the message I was trying to put across and takes it one step further. That being ensure whatever tool you use, make sure it is flexible in what you can do with the data you’re working with. This could be for those unexpected RA issues or for extension beyond core RA objectives.
    And I absolutely agree about the intelligence of the analysts being critical – after all a tool can only do what it’s told and that is up to people.

Comments are closed.