I’ve recently returned from attending Beacon Event’s 10^th annual Asia Pacific Billing and Revenue Assurance conference in Bangkok. While I’d planned and hoped to provide a daily update, that proved too difficult with an unstable hotel WiFi connection (missed revenue opportunity?) and so this comes to you a day later and 7500 kms away from the conference.

Tony Poulos provided a timely reminder within 10 minutes of the conference start when he spoke of the multi thousand person Billing events that used to be staged at Earl’s Court in London in the last 90’s and early 00’s. Of course these incorporated fraud and revenue assurance as well but while those days are long gone, there was a healthy 150 or so people in attendance.

If the agenda reflects what people want to hear and know about, then these are things for us to be aware of:

- why not simplify pricing constructs to minimise the likelihood of revenue loss but also better manage customer experience and prevent bill shock?

- What role should RA have in transformation projects? Everyone, not surprisingly, agreed RA should be involved but its ability to halt a transformation activity if KPIs are not being met was more contentious

- Where should call senders sit in an overall RA strategy?

- Where should RA sit in an organisation and should it be integrated with other functions including fraud, credit management, marketing, product management or extend its remit to business assurance and revenue protection?

- How can RA and billing cooperate more with the traditional enemy of Marketing?

- The increasing importance of analytical support for RA.

- What unique challenges exist for multi play operators, and is the risk of loss from bundling and discounting greater than the risk on a single product line alone?

- What does preventative RA or proactive RA actually look like?

- What does it mean when the customer service group has a lower tolerance for leakage than the RA group?

- Why is prepaid fraud so often overlooked and neglected, despite the significant amount of money sitting on the platform?

Some of these may resonate with you and some may not and, in large part, that comes down to the unique operating environment in which everyone works.

Firstly happy new year to everyone - I hope 2010 is a successful one.

Reflecting on some recent posts, both on talkRA and more broadly, I found myself asking the above question.

My rationale was that much of the discussion around RA seems to centre on what the next step of evolution for RA should be. It is almost as if finding and preventing leakage is not enough to sustain an RA function and that more needs to be added to the RA portfolio for it to continue to be seen to be adding value. I wonder if the logic for this is an assumption that, with a well-established RA function, either leakage will fall away or more likely the costs of finding and fixing it outweigh the benefits it will bring.

In many ways this makes sense. The TMF maturity model advocates greater decentralisation of the “RA” mindset and capability across an organisation. Now in many organisations this is not practically possible to achieve but it is possible to move further along the continuum. And this would imply that the RA managers who do the right thing for their organisation by spreading the thinking of RA may find their role reduces as resource moves out to operational areas as the perceived value of RA moves from tangible detected loss to less tangible prevented.

So is it the case that RA done well means that the RA manager must look to extend their remit to hold their status in their organisation? Is RA alone not “noble” enough to provide a sustainable career path? Now, I don’t have the answers to this but as I have recently moved from an operator to being an independent consultant, this question is also relevant for me personally.

Surely though this challenge for RA is not that different to other risk management disciplines – primarily I am thinking of fraud and security but this could also apply to other risks such as legal, regulatory etc. When RA is new in an organisation then opportunity for attention arise as the leakages are found and fixed but at some stage a steady state will be met. Must RA extend itself to continue to have influence and attention at the CxO level…and if not will it find its position becomes less relevant? I don’t have the answer to this question and I suspect it will actually evolve and change anyway over time but it is something every RA manager driving their company along the maturity curve should consider.

Reading the recent news on talkRA of the merger of EcTel and cVidya, and financial results for Subex got me thinking. Add to that when I was on an internal call last week, I was asked why we need to use the RA tool to perform a reconciliation, and not just use SAS.

Is it the case that the RA tool, as a specialised piece of software, that can command a premium price, is going the way of the dinosaur? On the phone call, I was able to argue that the configuration work had already been done so it was pointless to repeat it, but would I have an easy as response as this, if the work had not yet been started?

I have recently been thinking again about the TMF’s RA maturity model. What I am sure on is that the benefits from an RA investment (be that time, people or tool), will not be more than the lowest individual dimension of maturity. So if 4 of the 5 dimensions of the TMF maturity are high, but the “people” dimension (for example) is low; then only low benefits will be realised (don’t ask me to define low vs. high benefit).

And so the RA manager’s role must be to align each dimension to deliver and sustain the next level of maturity. Delivering this though requires thought, based on an honest appreciation of where capability is currently at, and strategic leadership to see how to move in the next level.

To bring this back to why I was thinking about this originally, there seems a disconnect between the seemingly unflattering business performance of RA vendors, and the apparent growing need for RA work. It raises the question that, in general, are RA tools and software more mature than the people and processes, or is it the other way around? And depending on that answer, is this recognised by the RA software vendors, and if so what could, or must, they do to lift their own profit?

I started writing a comment to Ashwin’s blog but as it was getting too long, I thought I should just start a blog.

From my perspective, there is little doubt that detailed analytics are essential to be undertaken by RA teams and should be the primary activity. Dashboards serve some value in identifying trends but I suggest that any movements upwards or downwards in trend lines (such as the 0.3511% in Ashwin’s email) become almost impossible to justify as leakage. Let me explain my views:

First - what is the right baseline value to begin a dashboard with? Assume every day for the last 3 years, 100 calls come into a mediation device and 70 come out. So you set a baseline at 70 and if this drops to 65 then you decide to follow up with the mediation people. Great theory, but who says 70 is correct in the first place? It may well be that there is a leakage in the 70 and in fact it should have been 80 all this time. The only way to know where to set a possible baseline then is by doing a detailed analytic. So let’s now assume we did that and we know it should have been 80, we’ve fixed the mediation device and we start seeing 80 go through every day. Great stuff: we found 10 lost calls, fixed that issue (hopefully got a pat on the back), and are now monitoring every day just in case, this drops back to 75 in which case we will be on the phone and get that problem fixed as well. Two weeks later, and the volumes hit 70 and they stay there for the next few days. You’re on the phone saying something is wrong, no-one believes you and ask you for the call detail to prove it. You do the analytic again and find that 70 is the right volume as new products have been introduced and the mediation device treats them differently, or there was more of a particular call type in that time period due to a marketing promotion, or…etc etc. My point is that the reasons could be endless and setting a good baseline dashboard value would only be possible in a stagnant, never changing, environment - not really well suited to telco then. And if, every time you called out “leakage !!!” when there was some other change you would be 1) busy tryng to prove this and 2) lose your reputation for integrity and the time of the people who you keep raising alarms to.

Second - many revenue leakages reside in the less than 1% bracket. Sure, there are some massive ones and these are the ones that we talk about at conferences or hear of in training but the normal reality is that most are so small, relative to the revenue pool that a dashboard would find impossible to discern from other activity (similar to my point above). But if you have a $100M product, then finding $1M is a good result but to find it is likely going to need detailed analytics.

Third - only with some detailed data can you go back to the business area and tell them what specifically to consider addressing. Analysis may even also know what to fix specifically. Analysis can also tell you the extent of the issue, making a quantification of the total impact, more easily achieved and this can help drive prioritisation of resources to address this, relative to all the many other competing demands across the company for money and people’s time.

Lastly (for now anyway) - the cost and effort to maintain a RA dashboard that adapts for all the business rules and changes that go on in a business would be very high. In fact, I would contend that it would be almost as high as putting in the operational system changes that it is meant to monitor. Why? to keep it current of all network and IT changes going on would not be insignificant, add in all pricing changes, campaigns, what the competition is doing and how to account for the behaviour of people is practically impossible to model. To make a point, how many times have I heard stories of RA managers raising alarms at a 50% drop in traffic over a 2 hour period, only to later realise that this was due to the nation being absored by a football match (and the RA manager probably was watching on TV as well).

Do I think there is value in RA dashboards then? Well, yes but they have to have some key attributes:
1) data presented has to be summarised correctly from accurate underlying data (avoid garbage in - garbage out)
2) “alerts” have to drive an action (e.g. do analytic, phone billing)
3) more true positive alerts are generated than false alerts (the challenge of our fraud system friends as well)
4) data needs to be delivered in a timely manner (no point finding a leajage after everyone else has)

Putting that into play though requires time, thought and effort. And that effort could be spent on doing a detailed analytic. Getting the balance right is the challenge !!!

Much is often made of the need and benefit of training to enhance the knowledge and skill of revenue assurance practitioners. The claims made of the benefits certainly vary considerably and, in recent times, there also seems an increased focused on accreditation or certification to prove that the student has the necessary skills. My blog is not about the content of varying and competing courses but some considerations that I recommend be thought of when evaluating different training options.

Firstly, technical training on how to use RA software tools is essential. There is little value in spending money on a tool that no one can use, or as is often the case, is not used to its full capability. No need for anything more on that.

We all know that it is people that use tools and need to apply their thought processes on the best way to achieve the outcomes that are expected of them.

Training in revenue assurance often seems centred around ensuring that the students have an adequate understanding of how a telecoms operator is “put together”. By this, I mean ensuring that the underlying technology and platforms are understood. This is certainly valuable but I suggest any RA training you undertake needs to go beyond this and if it is too weighted in this area, then it is more telco 101 than RA training.

RA training often discusses known leakage points and what to look for. It’s great to hear that operator ABC lost millions by $ by a wrong configuration but there’s a reasonable chance that the configuration is specific to that operator and not so relevant to you. Case studies are always of interest but for anyone other than absolute RA novices, we know how leakage can occur. Simply, we lose call/event records, we misalign services provisioned to those billed and/or we charge the wrong amount. Most leakages seem to be some variation of these. What you want training to do is improve your efficiency and effectiveness at finding revenue leakage.

So how can this be done? I don’t have all the answers but here’s some thoughts:

• ensure that the training encourages you to think about you own operational situation, as opposed to a generic model of a typical telco. For example, calls can be lost but what are the relevant systems in your organisation, what are they meant to do and what might go wrong. With that knowledge, you already have the start of a scoping document for some work.
• model what good RA work looks like -  how long should it take, how will precision be ensured, how is the programme managed, how are updates communicated, how are outputs prepared, what will be done to fix any identified leakages etc. This includes understanding what the challenges are to undertaking RA work, and highlight, very specifically, how these can be overcome.
• how do you define a programme to prioritise your efforts. We all know our companies are large and we could look everywhere but, depending on your priorities, where should we invest our time? For example, if you are chasing revenue, then generally, complexity and/or manual processes lead to the largest losses. Training should ensure you understand some of these principles and apply them to your situation - what is complexity to you (in the design, the build, in the implementation, in what CSRs are meant to do)?

To summarise, when you look at training options, be wary of training purporting to be RA when it may be on other subjects and seek out training that defines better how you can specifically improve the quality and quantity of your RA output.

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.