Archive for July, 2010

Type the words ‘dale crossman revenue assurance’ into Google this morning, and you will find something you would not have found a few days ago. The top hit takes you to Wikipedia, which tells you that:

The term “Crossman Exposure” is named after a Revenue Assurance Consultant who had worked extensively in quantifying financial risk associated with Revenue Assurance within Telecommunication companies.

Oh, really? It is funny, then, that I have never heard of the “Crossman Exposure” before, or about Dale Crossman and the extensive work Dale has done. Indeed, the whole internet knows little about Dale. Dale Crossman’s only claim to entry in the Revenue Assurance Hall of Fame seems to be the Wikipedia article named after Dale Crossman. I guess that means Dale’s name will go down in the Hall of Shame instead.

Tut, tut. People of RA, we have been down this road before. No self-respecting profession would allow its Wikipedia page to become home for chancers who want to promote themselves by inventing spurious accolades, giving themselves titles or naming things after themselves. First it was cheapskate vendors who thought wedging their company’s name into Wikipedia articles was a respectable way to promote themselves. Then it was Papa Rob Mattison, the President of Global RA Spam. To be fair to him, at least he can claim to be successful in turning spam into a viable business model. Papa Rob used Wikipedia to announce he was the president of his global association of professionals even before it had a single member. In recognition of his breaking of Wikipedia’s rules, Papa Rob was booted off Wikipedia not once, but twice. Now we have Wikipedia spam about Dale Crossman’s contribution to revenue assurance… whoever Dale Crossman is.

Being an auditor at heart, I tried to find out as much as I could about Dale Crossman. We know the person who posted the Wikipedia article has an out of date copy of the TM Forum’s RA Guidebook; the Wikipedia article refers to the 2006 version. That probably means Dale’s company is not a member of the TMF and Dale only has a pirated copy of an old text… which is not a good start for someone wanting to promote their industry knowledge. Indeed, the only reason for the reference seems to be to mislead people into thinking that the “Crossman Exposure” is in the TMF’s guide, which it certainly is not. Beyond that, searching for the name Dale Crossman in the context of revenue assurance only comes up with blanks. So I looked to see what other pages had been edited by the people who had just spammed Wikipedia. Bizarrely, there was exactly one other page edited by the same user… the page about the town of Talbot, Victora in Australia. Might Dale be an Aussie? It seemed I was not getting far. Then I considered that internet users often adopt the same nicknames in different places on the web. Might the person who created this Wikipedia page – with username ‘epacdon’ – have the same username elsewhere? There is an epacdon on eBay in Australia… which is only weak corroboration. There is also an epacdon on an Australian webpage for sharing photos, though the real name of that user is Daniel McDonald, not Dale Crossman. I stepped back and tried a wider search and found that there is a Dale Crossman who works for Ericsson in Australia. He also lives in the same area of Australia as Daniel McDonald. However, the LinkedIn profile for that Dale Crossman makes no mention of revenue assurance. Furthermore, Ericsson is a member of the TMF… so that Dale Crossman could download the updated copy of the TMF’s RA guidebook whenever he liked.

So I give up. The trail is too cold and too tenuous for me to track down Dale Crossman, supposed hero of revenue assurance. If you know about Dale Crossman and his (self-) exposure, please share. After all, there is no point to promoting yourself with spam if afterwards you still remain so obscure that nobody knows who you are. And if you know Dale, be sure to let him know that the Wikipedia page on the “Crossman Exposure” has been flagged for speedy deletion… has been deleted!

Bookmark and Share

Regular readers of talkRA will know that I maintain an irregular series of posts about revenue assurance for businesses other than communications providers. That is because I find examples on an irregular basis. I find it useful to keep a ‘scrapbook’ of every example I find of RA in other sectors. Building up the scrapbooks helps to show how the ideas of revenue assurance, and also the phrase ‘revenue assurance’, can be adapted to serve other needs. So far, that irregular series has found some fascinating instances of revenue assurance outside of telecoms: oil production, airlines, government taxation, the hotel industry and many more. Another recurring but splintered theme in revenue assurance is what it will become next. Every so often, but with increasing regularity, I see whitepapers, interviews, press releases and other material where somebody or other is extending the idea of revenue assurance in a different direction. Who will guess right and both predict and shape the future of revenue assurance? Only time will tell. In the meantime, let me start collecting this new scrapbook of the alternative visions of where RA is going. To begin with, take a look at this paper from Victor Milligan of Martin Dawes Analytics. Without saying so explicitly, the paper suggests that ‘process analytics’ will be one direction for the future extension of revenue assurance. That might be a stretch of the imagination for some people in RA, but Victor’s arguments about the potential value of process analytics deserve some consideration.

Bookmark and Share

When advising people on what I am looking for in revenue assurance, sometimes I find it easiest to use metaphors. The right metaphor has the advantage of conveying an involved idea very succinctly, though as with any abstraction, a poor choice can be misleading. One of my favourite metaphors is to the metaphor of health. We want our patient, the telco, to be healthy, and RA plays the role of a doctor. A poor doctor treats symptoms – waits for leaks to occur and then tries to recover them. A good doctor treats the disease itself – the root causes of leakage – so there are no illnesses, and no symptoms, any more.

This excellent article in Connected Planet Online really impressed me, because it talks about where revenue assurance should really be headed. It talks about transforming businesses so services are delivered right first time, pleasing customers, saving costs, and spelling an end to the culture which says leakage is inevitable. As I read it, I was trying to think of the right way to sum it up, but it is so well written that it is hard to convey its many-layered message any more succinctly or elegantly than the article already does, without losing some of its flavour. So let me just use a metaphor. If good revenue assurance is about making a business healthy, then the article says that you need revenue assurance right in the bones of the business, and should not treat it as a cosmetic that you apply to the skin. We need to get inside our telcos, changing it from the inside out. Only then will revenue assurance have delivered the optimal benefit to the business.

Bookmark and Share

I must admit I have not spoken to people at Verizon Business or their software vendor, Something Digital, but I had to share this case study with you all. In short, it says Something Digital built a revenue assurance dashboard using Microsoft Silverlight as the front end, and Microsoft SharePoint as the back end. MS SharePoint as the back end to an RA system?!? If they had said SQL Server I would have understood. The question that comes to mind is: how does the SharePoint back end work? SharePoint is a platform for web collaboration and publishing – yet Something Digital says that users can drill down into the detail of where orders have not been processed, services are not billed, or billing is ‘improper':

Essentially, we designed and built a user interface that would make it easy to highlight exactly where revenue was being lost throughout the organization, for both operations personnel and executives. Once an item was flagged, indicated by a red light, users could drill down to the raw data illustrating the problem.

According to Wikipedia, SharePoint can be used for:

developing web sites, portals, intranets, content management systems, search engines, wikis, blogs, and other tools for business intelligence.

Is this a surprising extension of the BI capabilities of SharePoint, used to serve the goals of RA? Or is there another back end behind the ‘back end’ of Sharepoint?

Bookmark and Share

In Reno, Nevada and Beaumont, Texas, AT&T has run a trial to charge DSL customers $1 per every gigabyte they exceeded their plan’s usage cap. However, they recently announced that their cap and additional usage charges were no longer being implemented. This is the second trial of usage-based broadband charges in the US, and the second to be abandoned, leaving no ISPs pushing the idea of metered broadband services at this time. Time Warner Cable also ran a trial of capped and metered internet charging in Beaumont, but abandoned its plans to extend the trial to other cities after a strong backlash from campaigners and politicians.

You can read more about the story here and here.

The interesting thing about the trial is that AT&T dropped it back on April 1st, but without making any public announcement or even telling customers. This may indicate two things: that metering internet usage is unpopular in general, and that targeting extra charges at the ‘bandwidth hogs’ is not cost-effective. Why should people in revenue assurance care either way? Because the flatter charging is, the simpler it is, and the less likelihood of error. On recent evidence, customers are pushing harder than ever for simple flat-rate tariffs, especially where they are already accustomed to getting them. Simple unmetered tariffs will suit those who feel the first goal is to ensure accuracy and please customers by making it easy for them to understand what they pay for, but may not suit those in RA who secretly want complexity because that gives them more problems and issues to untangle and makes assurance harder to do.

Bookmark and Share