Revenue assurance

Overview

"Revenue assurance" is a broad umbrella term. It is used both to describe an activity performed within telecommunications service providers, and is a common name for a small business unit associated with that activity. Revenue assurance is a practical response to perceived or actual issues with operational under performance, most commonly relating to billing and collection of revenue. Some of the procedures associated with identifying, remedying or preventing errors may be undertaken by a dedicated Revenue Assurance department, though responsibility for revenue assurance is often diffuse and varies greatly with the organizational structure of the provider. Assuming a provider with a typical organizational split, responsibilities for revenue assurance primarily sit between the Finance and Technology directorates, however, revenue assurance initiatives are often started in a business unit or marketing group.

The relevance to Finance rests with the responsibility for financial control, audit and reporting, while the subject matter would be network and IS systems as implemented or operated by the Technology side of the business. Marketing groups and / or business units (e.g. wholesale or retail business lines) will often embark on revenue assurance projects in an effort to improve product line margins. Furthermore, marketing and business units are pivotal in providing input into the "should be" state of customer bills and products.

The sphere of influence described by revenue assurance varies greatly between telecommunications service providers, but is usually closely related to back office functions where small errors may have a disproportionately large impact on revenues or costs. The processing of transaction data in modern telecommunications providers exhibits many attributes akin to a complex system. However, there is significant disagreement about the ultimate aims and legitimate scope of revenue assurance teams. This is in part caused by:

(1) the cross-functional nature of the activity and the consequent need for a variety of skills from IT, marketing, finance, et al.;

(2) the difficulty of generalizing across businesses with different objectives and business models;

(3) political infighting within each telco about responsibility for revenue leakages and assurance; and

(4) the difficulty in reliably measuring the value added by revenue assurance as separable from underlying performance.

There is high-level agreement between practitioners about the goals and methods of revenue assurance, though reaching a consensus on defining the boundaries of revenue assurance has proved elusive so far. The goals relate to improving the financial performance by eliminating mistakes in the processing of transaction data. Some take a more encompassing view of what counts as a mistake, which may extend as far as questioning the policy set by executives even when this has been executed correctly. Others take a more open-ended view of the data that is the subject matter. For example, in decreasing order of frequency, revenue assurance may cover:

(1) revenues from retail and corporate sales;

(2) revenues and costs from interconnect and wholesale contracts; and

(3) margins and profitability of investment in networks and information systems.

Other markets have different or more refined priorities. For example, in the U.S.A. management of wholesale contracts has often been the first objective because of the complexity of the domestic market resulting from the Federal Communications Commission's regulatory framework. In contrast, telcos in developing countries may prioritize management of international interconnect arrangements because of the risks posed by fraud and arbitrage. A cable supplier or internet service provider that predominantly offers retail customers flat monthly charges and no limits on usage may be most interested in assuring the profitability of network investments.

Revenue assurance is often regarded by practitioners as a low-cost mechanism to generate significant financial returns for telecommunications service providers. However, the returns are unpredictable as well as being hard to measure, which encourages many executives to take a sceptical view of its worth. Comparable revenue assurance activities do occur in other industries, such as with billing of utilities or with the licensing of software, and there are many parallels with financial and operational control activities undertaken by most large businesses. The rationale for why revenue assurance has come to be considered particularly important in telecommunications, unlike other industries, is disputed. Reasonable conjectures are that:

(1) the fast pace of change and intense commercial competition increase the likelihood of mistakes;

(2) there is significant complexity in determining the combined effect of interacting systems and processes; and

(3) the high-volume, low-value nature of transactions amplifies the financial implications of "small" errors.

Another conjecture is that revenue assurance is a response to changing market conditions. The thinking is that as markets reach saturation and growth potential falls off, so the value of maximizing returns from existing sales increases. This observation has some merit but does not explain the increasing popularity of revenue assurance in telcos serving growth markets. It also in part contradicts the assumption of a compelling costs versus benefits argument for revenue assurance, which would be enhanced in businesses undergoing rapid change. It is also important to recognize that there is a long history of revenue assurance activities in some telcos that predates the coining of the term "revenue assurance".

The revenue assurance techniques applied in practice cover a broad spectrum, from analysis and implementation of business controls to automated data interrogation. At one end of the spectrum, revenue assurance can appear very similar to the kinds of review and process mapping techniques applied for other financial controlling objectives like accounting integrity, as exemplified by those derived from clause 404 of the Sarbanes-Oxley Act. This form of revenue assurance is most commonly promoted by consultancies. The size of such consultancies covers the entire range; the Big 4 all offer some form of revenue assurance consulting, but there are also niche specialist consultancies. At the other end of the spectrum, revenue assurance is treated as a form of reactive automated data interrogation, seeking to find anomalies in transaction data that may indicate errors and potential revenue loss. This form of revenue assurance is most commonly promoted by software houses that aim to provide databases and configurable tools to extract and interrogate a telco's source data. A less popular form of reactive automated assurance involves using both software and specialised hardware as a means of extracting additional data on transactions, for example by creating actual network events or interfacing directly with network elements to replicate dummy events. As with consultancies, IT-oriented revenue assurance solutions are offered by both large vendors like providers of billing and mediation software, and by specialized niche providers.

There is some debate about the relative merits of the different techniques that can be employed in revenue assurance.

As yet, there is no professional body, no qualifications, and no academic research that would help to drive consensus about the purpose or methods of revenue assurance. In part this is addressed by individuals working in the sector through membership and qualification in related fields such as accountancy and information systems audit. Some scientific research in other fields is also applicable to revenue assurance, though most revenue assurance "facts" rely heavily on anecdotes and oft-repeated truisms. Some of the most helpful and progressive initiatives in addressing the problem of consensus and scientific basis are listed below.

The value of revenue assurance

Revenue assurance is usually understood as a means to identify and remedy, and perhaps also to prevent, problems that result in financial under performance without seeking to generate additional sales. The most common metaphor is that of leaking water from a pipe, where water stands in place of revenues or cash flows, and the leaks represent waste. The value of revenue assurance is hence determined by the size of the leaks "plugged", and possibly also those leaks prevented before they occur, although estimating the value of the latter is very problematic. The value added also includes the recovery of "lost" revenues or costs (through issuing additional bills, chasing uncollected payments, renegotiating with suppliers a refund of costs etc.) after the fact. This last form of reactive revenue assurance is the easiest to put a value to, but is in many ways the least efficient form of revenue assurance; effort is directed towards repeatedly addressing the consequences of known flaws, and not on addressing the flaws themselves. This can lead to a parasitical relationship between a Revenue Assurance department or vendor and the wider business, where the department/vendor finds it easiest to justify its ongoing existence/contract by repeatedly fixing symptoms and not the root causes.

The TM Forum conducted a benchmark survey in 2008 that concluded average leakage, not including losses due to fraud, was 1% of the gross revenues for those telcos that took part. The number of participating telcos was relatively small compared to some other surveys, but the survey technique was more demanding than any comparable survey to date. The survey used the most detailed and prescriptive definition of how to calculate leakage of any survey of its type. The definition was taken from the TM Forum's own standard on how to calculate revenue assurance metrics [2]. To increase confidence that participants calculated their leakages correctly, the TM Forum's benchmark program independently reviewed the results and corroborated them with representatives of the participating companies. The survey's average of 1% leakage of gross revenue, whilst still significant, is notably lower than many other quoted estimates and reported survey findings about average leakage. This may be because the survey used a very strict definition of leakage. The survey measured only actual under-billed and unbilled amounts discovered by the participants; it excluded other types of leakages such as cost leakages and loss of opportunity leakages, and it excluded projected leakage estimations that are commonly used (i.e., what would have been the amount of leakage, if the leakage would not been discovered by revenue assurance activities). It may also reflect a reduction in bias or exaggeration in reported leakages, or at least the exclusion of guesswork. Respondents were given authoritative instructions on how to quantify leakage based on actual data and were instructed to avoid making suppositions in the absence of such data.

The best known estimates of "typical" revenue leakage come from a series of annual surveys conducted by the Analysys consultancy and research business. In these surveys, leakage was commonly estimated as being worth between 5% and 15% of the total revenue of the business. Similar research by other businesses has generated results in the same range, with none concluding leakage of less than 1% of gross revenue, and some suggesting leakage of 20% or more was not uncommon. Reasons to doubt these estimates are as follows:

(1) All the estimates of leakage were derived from the subjective opinions of staff working in service providers;

(2) All the research was conducted by businesses wishing to promote their revenue assurance products;

(3) Increased annual spend on revenue assurance has not resulted in a clear downward trend in estimates;

(4) The estimates were broadly similar even when the criteria for what losses to include varied greatly; and

(5) Genuine losses of this scale should be a severe corporate governance issue in any publicly listed business.

What can be said with some confidence is that revenue assurance practitioners are able to provide a vast number of consistent anecdotes relating to the causes of leakage and means to resolve them. Though there is little objective evidence relating to actual leakages approaching this scale in the public domain as this information per se is highly confidential, there are some indirect measures of data integrity that help give a sense of potential leakage. For example, in reconciling interconnect costs and revenues between telcos, a 5% variance is the common practice to accept before a disputed invoice can lead one party to withhold payment, and a 0.5% variance would be considered industry-leading practice according to best practice advice issued by the UK Revenue Assurance Group.

Revenue Assurance in Telecom

Although Revenue Assurance has always been present in the telecom parlance it has recently been brought at the forefront of the top management. This is due to several factors including

Profit: Increasing cost pressures and decreasing margins. The high profit days for most telcos are over. They all need to find alternative means to squeeze higher margins by effectively tracking their revenue.

Regulatory: New regulatory structure and compliance requirements which force the telecom operators to report their revenue accurately.

Technology Innovation: Ensuring new technologies and products are performing as per perceived plans. Keeping up with release of new technologies along with co-existing of legacy systems.

Mergers and Acquisitions: With increase in the number of telco mergers and acquisitions, organizations are finding it very difficult handle multiple BSS systems including Billing, Mediation and Rating together etc.

Revenue Assurance has been a problem for the telecom companies since the very early stages. Tracking of pulses, minutes, counts, bytes etc. has never been more difficult. One would think these would be easy for the tech-savvy telco companies. However, the truth has been just the opposite. In a hurry to release new technologies in the market, the Revenue Assurance systems are always lagging behind. Revenue Assurance in a telco environment covers a wide range of technical and business aspects. An RA operator needs to be aware of both OSS & BSS processes and internal dependencies to accurately decipher the revenue code.

What causes the problem

A telecom organization's revenue chain is usually a very complex set of inter-related technologies and processes providing a seamless set of services to the end consumer. As the set of technologies and business processes grows bigger and more complex, the chance of failure increases in each of its connections. A revenue leakage is typically attributed to when a telco organization is unable to bill correctly for a given service or to receive the correct payment. As the organization grows the probability of revenue leakage only increases.

Where is the problem

The most debated part of revenue assurance is where to start checking, i.e. at the network side, the rating side, the billing side, the interconnect side, the CRM side, etc. However, most surveys and reports state that the maximum leakage happens during the flow of Call Detail Records (CDRs) or Event Detail Records (EDRs) from the Switch to the respective rating / billing engines. Some of the common problem areas are :

Network

* Signaling problems * CDRs in Switch not sent to Mediation * CDRs in Mediation not send downstream * CDRs rejected by rating / billing system * Wrong duration on the CDRs * Wrong TON value populated in the CDRs * Incorrect Business rules * Subscriber provisioning * Incorrect Routing

Rating & Billing

* Incorrect Rejection Logic * Duplicate CDRs resulting in double charging * Incorrect tariff plans * Rating & Billing accuracy errors * Late rating / billing * Incorrect configurations – rating minutes instead of seconds * Incorrect Disconnection

Revenue assurance discipline

Among the disciplines in revenue assurance are:

1. The CORE functions of a revenue assurance group: Monitoring, Baselining, Auditing, Synchronizing, Investigating and Compliance.
2. Decomposing an organization's revenue assurance scope (The Revenue Management Chain).
3. Assessing and minimizing revenue loss risk.

Maturity of Revenue Assurance

There is no formal maturity model for Revenue Assurance which is universally accepted. However the Revenue Assurance processes can be pegged against a generic five stage maturity model. The five stages are listed below and are described in terms of a Revenue Assurance Strategy, People, Process and technological advances.

Initial: At this level that they are (typically) un-documented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the Revenue Assurance processes. At this stage there is no formalized Revenue Assurance strategy in place. Teams run adhoc queries on various systems. It depends entirely on personal ideas & initiatives. It encompasses substantial manual effort. There are undocumented repeat processes.

Repeatable: At this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be precise. This is where the Revenue Assurance functions starts to take some shape in defined procedures and outputs. However they still don’t cover the entire revenue spectrum of the telecommunications company nor do they cover all aspects of a specific revenue stream. People are still learning the skill set of revenue assurance. There are specific measurement and analysis outcomes received at this stage.

Defined: At this level that there are sets of defined and documented standard Revenue Assurance processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. There are specific tools for Revenue Assurance identified and implemented. There is clear sense of what revenue chain coverage does, what the Revenue Assurance department cover and road maps are in place for the future. All major revenue streams are covered by now. There is a formalized and approved Revenue Assurance charter and strategy in place. There is a specific year on year budget for the department.

Managed: At this level with the use of process metrics, management can effectively control the Revenue Assurance AS-IS process (e.g., for Issue Detection, Root Cause Analysis, Closure). There is a formalized strategy and long term road map for people, process and technology for the revenue assurance department. In particular, management can identify ways to adjust and adapt the process to particular Revenue Streams without measurable losses of quality or deviations from specifications. Process Capability is established from this level. The people have the right skill set to execute daily operations and have subject matter expertise.

Optimizing: At this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. A risk based strategy is in place to evaluate the coverage of Revenue Assurance at specific intervals of time. Controls reach a maturity where Revenue Assurance only acts as an improvement agency for other process areas including product development, product deployment, customer retention, billing, collections, dunning etc. At this stage the RA processes are concerned with addressing statistical common causes of process variation and changing the process to improve process performance.

RA Process Categories

The Revenue Assurance processes in many ways can be regarded as an auditing process. The objective is to ensure that policies of the organization are well implemented and that no or minimal revenue leakage is occurring. The RA processes have the capability to cover all departments and service lines in a telecommunications organization. There are many ways in which RA processes can be classified, however in view of an audit function; the RA processes can be categorized into Detective, Corrective and Preventive activities, controls or processes. Let's understand the difference with the help of an example. Supposing the objective is to ensure trunk groups correctly entered in the MSCs. The detective control would be to monitor Trunk Groups appearing in CDRs are harmonized with the master list and any deviations are reported. The corrective control would be to initiative a process and confirm with the Network / Wholesale team of all deviations found. The preventive control would be to set up a process with the Network / Wholesale team where all new trunk groups are first informed to the RA, Mediation, Wholesale and other essential departments and then made live on the Network.

Detective Processes

Revenue Assurance Detection is the process of spotting a change in value of a dimension relative to its movement from System A to System B or within a given systems itself. The change in the value is relative to a dimension is question. Detection in RA can be achieved by both manual and automated means. Typical detection activities include monitoring, summarization, investigation and auditing.

Monitoring: Typically monitoring activities in Revenue Assurance refers to observing data, system or a process for any changes which may occur over a period of time. With the use of automated tools one can typically achieve constant monitoring which can notify the user or administrator (via email, SMS or other alarms) in case of any changes. The various processes which typically are monitored by a Revenue Assurance department include daily network usage, profile and configuration changes, mediation, rating, billing, settlement, roaming, collections and dunning related processes.

Summarization: When dealing with large volumes of information like network usage, it may not be practical to go through CDR by CDR and compare the same between 2 systems. In such cases summarization will help in quickly examining and finding out the preliminary problems areas. For example, one could first summarize information on the basis of few dimensions like events ( voice, sms, data), customer type (postpaid, prepaid, in roamer, out roamer), operator (self, local, national, international) etc. and compare the measures like count and duration of these dimensions between 2 systems. Such rapid assessments help in identifying the problem areas or dimensions quickly and a further detailed investigation can be carried out for those dimensions identified. Summarization greatly reduces the manual effort in identifying problem areas within a large data stream.

Auditing: A revenue assurance audit is a set of activities carried out to ensure that the organization is taking necessary steps to remain compliant to the evolving changes of organizational policies, regulations and market conditions. Every Revenue Assurance audit has a list of specific objectives which may come from management, regulations or industry standards. The actual tasks of the audit can differ based on the information, system or departmental processes being audited. Some sample RA audit objectives could be like ensuring billing accuracy up to 0.01%, no configuration variances on the Network, rating & invoicing process assurance etc. Each RA audit can span into different departments, each with its own specialized technical requirements.

Investigation: Investigation is the act of detecting something new, or something "old" that had been unknown. Investigation leads to discovery which is the observation of new actions, or new events and providing new reasoning to explain the knowledge gathered. An RA investigation is a series of processes or procedures carried out to identify the Root Cause of an anomaly. This is also known as Root Causes Analysis (RCA) procedures or activities. Root Cause Analysis (RCA) is a method of problem solving that tries to identify the root causes of faults or problems that cause operating events. An investigation would try to identify and correct the root causes of events, as opposed to simply addressing their symptoms. By focusing on correction of root causes, revenue assurance problem recurrence can be prevented.

Corrective Processes

Correction is the set of activities and processes related around getting the process structures correct in order to minimize the changes identified as per the detection techniques. Correction itself is the act or method of correcting a discrepancy. Typically some information, configuration, amount or quantity needs to be added, edited or removed from a system, process or procedure in order to correct the anomaly. In Revenue Assurance activities, the process of correction of a root cause could involve correction of information, processes, technology or people.

Information Correction: This refers to the process of correcting or updating a value for a configuration element or a reference table. This is typically the result of a missing data set in a particular given table or system file. For example, a particular number series may be missing in the Switch and hence not getting connected or updating a missing tariff plan in rating engine leading to unrated CDRs etc.

Process Correction: Process correction refers to the modification of an activity by adding, modifying or removing an activity step which will prevent a miss-configuration or revenue leakage in the process. Typically process correction is required to have a pro-active revenue assurance step to provide better governance across the operations. For example, the pre-bill verification process may be required to be modified when a new service line or product is introduced into the market. The new service line may be required to be included within the pre-bill process.

People Correction: People correction is required when skills of the resources are in question. Revenue Assurance is a niche business process with limited people present with the right amount of Telecom Network, Mediation, Billing, IT and Business related experience. This leads to many Revenue Assurance teams with inexperienced people on operational departments. Owing to this, most Revenue Assurance operations end up being only re-active rather than moving into a proactive foundation.

Technology Correction: The very nature of the telecom business changes frequently. There are 2 aspects to Technology correction i) The technology on the Network side ii) Technologies in use by the RA department themselves.

Telecom Network technologies evolve at a rapid pace. Sometimes technologies need to be balanced in the Network. For example, having multiple vendors on the Network side could lead to a requirement of having time synchronizer equipment installed just to have CDRs showing consistent time and date related information. Any current implementation of Revenue Assurance becomes obsolete rapidly. As technologies evolve revenue assurance tools and coverage of the tools also need to evolve. This essentially means technology corrections need to be performed either on the hardware side or on the tool / application side. Technology corrections are rare and need to be performed with due diligence as technology corrections can be very expensive to an organization.

Preventive Processes

Prevention is the process of performing an activity in order to avoid a high risk situation. It is essentially an action carried out to de-risk a threat. For example, if there is risk that a tariff plan is not correctly implemented, then the preventive action could be to simulate calls on test SIMs on the new tariff plans prior to launch and confirm the tariffs coming in the test CDRs against the marketing or advertising department rates. Preventive activities lead to effective risk management around Revenue Assurance.

Synchronization - A set of activities which ensure that 2 data sets are synchronized over a period of time. For example, a set of Revenue Assurance activities would ensure that all prepaid customers on the CRM systems are represented in the IN - SDP (Intelligent Network) and vice versa. Similarly all trunk groups between the whole sale departments are in sync with the trunk groups mentioned in the MSCs. Another example could be to ensure all B number tables between the MSCs are same.

Integrity Checks - These are individual activities carried out to ensure the integrity of the system or process. This is an effective check in gaining insight into an individual process and to assess whether it has anything in their immediate background that may be a cause for concern. For example, performing a sample based credit check for postpaid customers prior to generation of a bill. Another example could be subscriber checks with sanction lists watch lists for involvement in/association with fraud, money laundering & related illegal activities.

Pre Process Checks - Any checks performed on the input parameters of a process to ensure that the right data is fed into the process. Pre Process checks are necessary for complex processes like rating and billing which involve multiple sub processes and consume a lot of time for each run. Some sample preprocess checks could include validation of CDR sequence number before rating, file count confirmation before rating, subscriber pre check before billing, duplicate CDR check, report all postpaid customers that do not have the correct bill cycle etc.

Post Process Checks - Post process checks are required to verify the reliability on the outputs of a given process. Some processes of Revenue Assurance can produce multiple co-related outputs which need to be verified before being released to the consumer either internally or externally. Some examples of post process checks are formats checking on the target outputs like TAP 3 files, cross reference subscribers on the bill cycle with pre bill list, numbers terminated directly on OSS systems and not via CRM / BSS systems etc.

Tool for Revenue Assurance

Since Revenue Assurance is a very niche area in the telecommunications environment, there are some specific products and solutions supporting this subject. There are various vendors in the market which address either the complete suite of Revenue Assurance requirements or specialize in the specific domains. This section describes the basic features of a generic Revenue Assurance tool.

One must keep in mind that software RA solutions can only help in pointing toward the error locations or problem areas. When one addresses the question of developing an RA solution they need to consider the magnitude, scope and capacity of the systems available along with the intellect, skills, and the number of people accessible. Finally it is the people, their skills and knowledge that make a complete RA solution. An organization should be careful when automating revenue assurance as it may end up with an expensive and inflexible solution which no one can manage effectively. There are a variety of specialized RA products which have different characteristics including probing, RA add on modules on respective OSS / BSS elements. However the most common tool adopted by most Telecommunication companies is one which can simulate the natural process of the CDR flow from Network generation to Invoicing. Given below are some of the requirements (not exhaustive) of such a Revenue Assurance product.

Extract, Transform and Load

Telecommunications is an environment where there are many heterogeneous systems creating a multitude of data. Typically a single day’s information runs into many Giga Bytes or in some cases Tera Bytes also. This creates a need to have very proficient and rigorous extraction, transformation and loading tool for a Revenue Assurance application. Some of the common features of this tool are:

It should be able to import data in all common formats of data (ASCII, ASN, BCD, Binary etc.)

It should be able import data directly from common databases

It should have the ability to receive data feeds from various data sources of the Network, Operational and Business support systems

It should have an extensive audit log to track files and records status - received, processing, duplicate, loading, error etc.

The solution must provide an integrated environment to perform data integrity checks

It should be configurable using a user friendly GUI.

It should provide the ability to normalize, enrich and transform business rules as applicable into a data model

It should be able to look up large tables or files for reference information

It should enable the creation of new data fields by manipulating and calculating values based on other fields

It should provide the capability to monitor the progress and success of the whole ETL process from start to end

It should handle unexpected errors and continue processing and maintain the appropriate audit logs

It should support full automation of the ETL procedure from file pick up to record entry in the DB or file system.

It should have the ability to store historical summary and detail information for a period of time configurable by the user

It should be able to summarize information on the fly based on configurable dimensions

It should have the ability to configure ETL level alarms and thresholds on data and notify relevant users of any exceptions

The solution must be highly scalable so that the data processing platform can be sized to accommodate current and projected, with business growth, traffic volumes & audit points.

Reconciliations

One of the primary focus areas of a Revenue Assurance tool is to compare CDRs or XDRs from 2 different sources and checking if all the records from the first system have transferred properly to the second system keeping the appropriate business rules in consideration. This is achieved via comparative analysis of the records between the 2 systems either at the details record level or summary level by evaluating the common dimensions between the 2 data sets. Given below are some of the requirements (not exhaustive) which a Revenue Assurance Reconciliation side of the product should provide.

It should have a graphical user interface to enable the RA analysts to create/update reconciliation and business rules

It should support various reconciliation and controls rules types e.g. missing records, unmatched records, problems in source file (duplicates, invalid values)

It should be able to filter the data prior to the rule executing to ensure efficient system operation

It should be able to set effective start and end date from which a newer business rule will be applied and valid for.

It should be to define rules using a naturalized user friendly language or a “drag and drop” GUI.

It should be able to associate monetary values with discrepancies identified based on predefined business rules

It should support the creation of a hierarchy of rules, when the results of a rule can become a source for further rules definition.

Analysis and KPIs

Once all the information has been received into the Revenue Assurance systems it time to crunch numbers and generate reports. The critical part is the analytical capabilities of the tool. The tool needs to have the ability to make sense of the problems in the vast set of data that it has gathered. This can only be done by a high performance analytical engine which should be capable of the following activities (non exhaustive):

It should have the capability to create measures based on the output of selected reconciliation and control rules and/or other user-definable criteria e.g. Customer Account Number, Product Code

This tool should be able to create alerts based on the application of thresholds to measures and dynamically change the thresholds based on business logic

It should be able to create KPIs based on various measures (such as count, sum, average, etc..) and multiple dimensions.

It should be able to showcase trends based on KPI values over the period of time and raise alarms when thresholds are crossed (for example alarms could be raised on a) Zero duration CDRs; b) Short duration calls; c) Long duration calls; d)Duration discrepancies; e) Invalid structure code/call types etc.)

It should be able to forecast information based on past records and raise alarms or reports

Users should be able to set thresholds of KPIs on the total value as well as on the value per specified dimension, e.g. the system should be able to alert on the situations when the threshold per a specific attribute is violated.

It should be able to categorize alerts and alarms based on priorities (e.g. critical, major, minor)

It should enable users to create new, and update and delete existing, KPIs and measures at any time through a simple graphical user interface. This should include full KPIs definition – calculation, dimensions, thresholds, calculation frequency.

The solution must have the ability to support detection, investigation, validation and correction of discrepancies resulting from audit comparisons

It should be able to co-relate gaps in the reconciliations with missing profile information or missing reference information or other system errors and prepare a consolidated report.

Dash boarding

A Revenue Assurance dashboard is an easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization’s Key Performance Indicators (KPIs) to enable instantaneous and informed decisions to be made at a glance. For example, a prepaid dashboard may show KPIs related to prepaid CDRs reconciliation, prepaid user profile reconciliation, balance reconciliations and voucher reconciliations carried out in real time or near real time.

It should be able to provide a fully personalized dashboard screen to present concise summary and/or detailed information

It should be composed of ‘building blocks’ or ‘sections’, each containing valuable information for the user e.g. summary of all currently defined dimensions & measures

It should allow different building blocks to display the information of different types (e.g. grid tables, trend graphs, bar graphs, line graphs, pie charts, gauges, URLs, Maps etc..).

It should enable each block or section to be linked on a functional level e.g. once a user selected a specific gauge, for example, in one building block, a specific relevant pre-defined table or graph in other building block(s), is being refreshed accordingly, to reflect the selection of the user

It should provide information on each source on the dashboard with drill down capabilities to investigate detailed information related to the building block whether presented with textual of graphical means

It should provide a designer module with full flexibility in defining data sources based on any information type stored in the RA database as well as the ability to use external information sources

It should enable users to search on a predefined set of fields within the source data for records using a complex combination of logical operators e.g. “=”, ”<”, ”>”, including wildcards

It should provide drill down capabilities from the list of records resultant from a search into specific record details.

Case Management

A case management capability in Revenue Assurance should be able to provide a 360 degree view of a given case. The tool should be able to track and resolve the identified discrepancies. The tool should handle each “case” in the system from the point where the system detected it, and manage follow up through the correction and reclamation processes, until the case is resolved. Based on a discrepancy in one given area, It should be able connect relevant information from various sources. For example, if a CDRs reconciliation has a problem, the case tool should be able to co-relate with respective user profiles, non-usage information, credits risks, network configurations etc. The case management component may have some of the following non exhaustive capabilities:

Ability to create a unique case identification reference for each discrepancy (or group of discrepancies) where user-defined criteria are met

It should enable users to manage and track cases by updating different case’s attributes such as: Status, Value, Priority, Assignee, Description, etc.

The user should have a full case history mechanism associated with cases and the case details. The history should be kept throughout the case life cycle including when the case is reopened by the system

It should be completely user-definable with content based on any data field available in the RA database by a simple drag and drop mechanism

It should enable users to include in case details all case related information and also any additional information (not necessarily case related) that can help in case analysis

It should enable users to create new fields in the case that will include either the automatically calculated value or will be opened for the user update. These fields should retain their value throughout the case life cycle

It should support case report output manipulation including sorting, multi-level grouping and filtering based on any one of the displayed attributes

It should have the ability to “multi-assign” cases (such as changing the assignee or closing a large number of cases) to one another

It should enable users to print the displayed discrepancies and export them to Excel, Word, Csv and PDF etc. files with restrict user access so that they can only see and update only the cases that are assigned to them