Revenue assurance (RA) has come a long way since it first appeared in the telecoms world. Initially, back in the early 2000s it was little more than an audit stream that checked that all revenue that could be collected was being collected. It quickly became a priority as the telecoms world hit the worst recession in its lifetime. The ‘land grab’ was over and the focus on market share moved to a company’s bottom line.
Since then the ‘RA market’ has been maturing. The recent TM Forum survey illustrates this well. Most of the respondents believe there have been improvements in the last year and their RA practice is maturing. Now an ‘RA attitude’ is gradually seeping through the silos of even the most wind-swept of telecoms company.
The world, though, is changing again, and fast. We are entering the age – nervously – of real-time responsiveness and offers based on customer knowledge. Analytics and business intelligence are now the focus of both the business and conference circuit. Revenue assurance has no budget and is increasingly struggling to justify its ‘post paid’ persona. The big harvest of RA discoveries have long ago been reaped. And there is a realisation that ‘post paid’ just is not good enough any more.
Revenue assurance needs to assure the revenue that is about to be generated, whether from a ‘real-time contextual offer’ or a planned campaign. It is already at the product design and management table, in some cases with a veto if a product cannot be billed. The real-time world is the next big challenge for RA.
And the solution looks a lot like the business intelligence domain. The question then becomes ‘should these two disciplines combine forces?’ Business intelligence is in the business of supplying customer based data to the business. In many cases it acts as a brake on the business’ wilder ideas, and brings those ideas up against the ‘privacy laws say no’ barrier more often than you would think. Revenue assurance does the same with products and marketing ideas, ensuring, to the best of its ability, that products that are launched can be charged for.
A combination of the two, and new ways of identifying the cost of a digital product, would be a powerful tool indeed. The real question is whether the politics of the average telecoms business would allow such a transformation, specifically, who would own it. It has been tried before, with only sporadic success. RA and fraud prevention worked from basically the same data sets and some companies tried combining the teams. In some cases this worked well, in others it did not. The culture and outlook of the two teams were too different – one team was looking for criminals and the other was looking for unintended leakage.
It is an interesting idea and one that will be discussed in the coming weeks, particularly at the forthcoming ETIS Business Intelligence group meeting in Brussels next week.
Great article, Alex! Since RA always had access to the same underlying data source, you’re spot-on that it’s natural to consider its relation to BI.
Thee thoughts:
1) We need to go beyond BI, which is today- and backwards-facing (or at best uses historical patterns to predict the future) to predict future revenue losses. That’s DI, on top of BI, and needs machine learning. Like Netflix or Google, there’s an untapped potential for full automation.
2) Like a good fraud practice, RA does need human-in-the-loop capability. Making the right decisions when the computer matches a RA leakage pattern is analogous to the fraud problem. Here, again, we need good models of the cost and benefits of different next-based-actions. Not every leak is cost-effective to fix.
3) RA, of course, should not be done in isolation, but should include cost/margin as well. Another driver for more sophisticated models.
See http://bit.ly/1zc04S3
Thank you Lorien, definitely a debate worth having. The biggest frustration of RA professionals has always been that the more they succeed the less attention – and thus funding – that they get. As RA people say, “it is only worth chasing down leaks as long as it is economical to do so.”