Revenue Assurance Software as a Service

In the revenue assurance market, why does nobody sell Software as a Service (SaaS)?

As soon as I write the question, lots of reasonable answers spring to mind. But for every hurdle I think of, there is also a way to overcome that hurdle… apart from one.

Software needs to be tailored for each customer and each revenue assurance problem

Perhaps. But if that is so, why are software vendors already offering what they describe as COTS solutions with pricing models based on the volume of transactions assured? Why not instead charge for the real challenge, which is the tailoring and integration? Of course, the fact that software vendors use a SaaS-compatible pricing model does not mean their software is SaaS-ready. Probably a transaction-based pricing model is just better for getting the initial sale and earning higher fees in the long term. But tailoring software to integrate with the needs of each client just means that the software needs to be further developed to make it more readily configurable. The problem is not insurmountable; the same data analysis engine is ultimately being used for each telco and each kind of error. Expensive, slow, manually-intensive writing of new code, or the use of specific programs to extract and parse data ready for analysis could just be made more efficient. A powerful solution would accept any dump of a telco’s data, so long as adequate mappings had been constructed to permit the relevant fields to be checked appropriately. Creating the mappings is just a combination of brain-work and knowledge: someone has to do that anyhow, whether it is the vendor or the customer. Making the mappings part of a repeatable configuration process, as relevant to SaaS, should also have benefits in making it more efficient and easier to update. So, the challenge is really just that the software vendors find ways to move their solutions up the SaaS maturity model, as described in this paper from Microsoft. And that will be driven by a combination of how forward-thinking the vendor is, and how demanding the customer is.

No capability to bill for revenue assurance SaaS

How pathetic an excuse would this be? A software company analyses a telco’s revenues, but cannot find a mechanism to bill it in line with the level of work performed? Probably it is not something that the average vendor has had to consider, but in terms of technical know-how you would have to question the competence of a business that claimed to be able to analyse billing defects but could not calculate a bill based on SaaS usage. If nothing else, it would be possible for any software vendor to partner with another business that already has a SaaS metering and billing solution, like that offered by LeCayla Technologies.

No market for revenue assurance SaaS

You could argue that there are no telcos interested in a SaaS-style approach to getting revenue assurance software. The “long tail” theory tells us that this should not be true; there should be smaller players where buying the software outright is not economical but who would pay to use the software as and when needed. In fact, the attraction should be very clear: paying based on use would allow the telco to buy as much as they needed. It would take much of the risk out of traditional procurement. The telco would simply try the product, see if it suits their needs, and keep on consuming it if it meets their needs. If anything, the downside for the vendor is that they might stop using it if it does not meet the telco’s needs. But it would make it much quicker and easier for a telco to extend its capabilities on either an ad hoc or ongoing basis, or to switch suppliers if not happy with their current revenue assurance software. And whilst some smaller players are being gobbled up in telco consolidation, the market should actually be growing as other businesses, like content providers, enter the market and look for solutions more suitable for their current scale.

Network reliability

Unreliable networks are a major obstacle that has slowed the roll-out of SaaS. The risk of Interruptions in network service may well be a good reason not to implement a software solution that depends on network quality. But hang on, what kinds of businesses are we talking about buying the SaaS? Telcos! There has to be something wrong with a world where telcos do not buy SaaS because they do not trust the networks to be reliable…

Security and privacy of data

Regular readers will know I get worked up about the security and privacy of data. So sending data backwards and forwards would be a justifiable concern. However, this obstacle gets surmounted (or ignored) easily enough most of the time. And there would have to be a degree of hypocrisy involved (and not for the first time) if a telco is happy enough to allow customer data to be sent to other businesses for all sorts of commercial and cost-related reasons, but not happy to do so when the data is being used to check if they have made errors…

Buying human brains, not software

The one hurdle that is not easily surmounted takes us right back to the first point I made: that getting the software to do a useful job is as much about human brains as it is about software. Software businesses often find themselves selling human brains rather than the software. Sometimes they sell the brains as an expensive addition to the software project. Margins on telling people how to use their software are often better than the margins on selling the software itself. On the other hand, software is somehow more tangible and easier to get approval for. I have seen more than one software vendor give a presentation explaining how their software project generated huge amounts of value, but where most of that value obviously came from one or two issues that were identified by a person, not by the software, early on in the project. So the source of the value is human brains, not software, although it is easier to sell the software than the brains. Which crucially brings us to the last hurdle – the people in the telco who have a job depending on the software. Some jobs depend on interfacing with the software each day, some on tweaking and developing it, some on managing and purchasing it. SaaS could be a threat to any and all of these jobs, depending on how the business currently manages revenue assurance. In particular, good, quick and effective use of SaaS solutions may serve to highlight previous inadequacies in the thought processes behind revenue assurance.

Footnote

I should really do my research before I begin writing a blog entry. My footnote is that my original premise, that nobody sells revenue assurance SaaS, is seemingly wrong. A quick search of the internet highlighted one vendor that does claim to provide revenue assurance SaaS: Primal Solutions and their “Voice Profitability” offering. I cannot vouch for it, because I have never used it. However, it does raise a new question: if they can offer revenue assurance SaaS, why are their rivals not doing the same?