B/OSS Insider Blog
![]() |
Revenue Assurance: Why One Size Fits None
By David West
Fellow B/OSS blogger Dan Baker was telling me the other day how the B/OSS software business got started. He traces it back to the early ‘90s when "commercial-off-the-shelf" or COTS software first appeared from firms like Kenan Systems and MetaSolv. It makes sense, since that was when wireless really began to take off. Plus, shortly thereafter, deregulation opened up the local exchange which sparked the CLEC explosion.
With two big emerging markets in their sites, large vendors invested heavily in R&D to develop off-the shelf applications for these startups. So the stage was set for some economies of scale since carriers wisely decided to not reinvent the wheel in billing, ASR ordering, or provisioning. After all, the needs of any two CLECs or any two wireless carriers were almost identical.
My company, Equinox Information Systems, began life as a custom software shop in 1986 focusing on the competitive LD market. Though we weren’t part of this first wave of off-the-shelf B/OSS software, by the late ‘90s our custom development had coalesced into two off-the-shelf offerings – a fraud management system, and a platform for mediation and reporting – with more than 100 carriers between the two.
By 2005 we were firmly established as a shrink-wrapped “COTS" vendor and figured our days as a custom development shop were long behind us – until we started looking at revenue assurance (RA).
The Funny Thing about Revenue Assurance
Around that time, there was an increasing amount of talk about “Revenue Assurance" and I started asking everyone I could “What exactly is RA?" The funny thing is – everyone I spoke to had a different answer. I have often joked that in telecom it's nice to have a “standard" we can disagree about – and RA was proving the rule. It seems like, as an industry, we latch onto these lofty, overarching terms and people start talking about them intelligently, but underneath there's no common definition.
With each person I talked to, I refined my RA definition. What I ultimately settled on was a definition that centers around billing accuracy. Here it is:
Revenue Assurance is making sure that everything that can get billed, gets billed, and gets billed correctly – whether it's bills you send out or bills you pay.
Perfect, right? It’s simple, broad, and short enough to fit on one PowerPoint slide.
One problem, however – my seemingly “complete" definition really doesn’t say much – it’s TOO simple, broad, and short. What does it mean to “bill correctly"? It means addressing a number of potential problems: bad orders, services not being provisioned, CDRs lost at the switch, rating errors, incorrectly applied discounts, badly calculated interconnect bills … the list goes on.
What I finally realized about revenue assurance is that it's a different beast from other B/OSS areas such as billing or provisioning. Those areas are rather well-defined, so they're ideal for an all-purpose, off-the-shelf software solution. Revenue assurance on the other hand is all over the map – it is really a process of addressing a wide spectrum of B/OSS system and process troubles that result in billing quality problems.
There's an analogy here to the game of chess. In chess, the pieces – bishop, pawn, knight, rook, etc. – all attack the opponent in different ways. Those pieces are analogous to the many software tools you can use to play the revenue assurance game – including usage mediation, SS7 traffic analysis, network reporting, jurisdiction calculators, rating engines and many more. RA then is not one tool, it's a family of tools and it's unrealistic to expect one tool to do it all. Just as you cannot move a rook diagonally, you can’t validate vendor usage invoices with a circuit inventory.
The other issue with revenue assurance is that every carrier seems to face its own unique RA pain points. Some carriers are more concerned about their expense side, others the revenue side. If you have a LEC business, then you’re probably concerned about access billing.
Given the variety of pain points and different approaches to addressing them, it’s nearly impossible for a single product or single vendor to address them all. Even if a single vendor could provide a comprehensive solution, it would likely be cost-prohibitive for all but the largest carriers. Furthermore, most carriers lack the resources to address multiple areas of RA at the same time. Any investment in software features that can't be used is wasted if the RA team doesn’t have time to manage the process.
For a large, tier 1 carrier, a comprehensive suite of RA tools may be the best way to go. But for most tier 2 or 3 carriers, a large suite of RA tools is more than they need or can afford.
The better decision, we think, is to buy from the á la carte side of the menu — allowing you to solve the specific RA issue at hand. Then later on, as priorities and budget permit, you can bolt on enhancements to the base platform.
David West is executive vice president of Equinox Information Systems, responsible for developing and implementing the company’s long-term strategic plan, including product design and marketing. West works directly with the company’s hundreds of customer sites across the United States, Europe, and Asia.
- Comments
