Note 44: Rating: Operational Considerations

Posted: 07 February 2008

Operational Workload

Rating (billing) systems have four areas of processing load that must be addressed:

Inquiries and Maintenance: This processing is generated by customers and internal staff and is usually performed in real-time requiring a prompt response. A biller located in one country or region is likely to find that the peak processing load is during the day (especially weekdays). Billers addressing a global marketplace (i.e. via the internet) may find that they have multiple peaks per 24 hour period.
Bill cycles: Periodically, monthly or quarterly (say), post-paid customer will have their transactions collated into a bill. To ensure that details are current when they reach the customer, this processing is performed quickly (e.g. in less than 24 hours) generating a high peak load requirement. Physical statements supplied for prepaid services can be performed with more timing latitude since the transactions are all complete and the monies have been received. The lower prepaid workload in statement production is balanced against a higher peak workload requirement for real-time rating.

Rating: Rating's workload will depend on the network business being billed. Billers with a monthly subscription business will have smaller processing loads. Billers with high network transaction volumes (e.g. phone calls) will need to perform processing continuously (over the month), with some parts of the day and week busier than others. Prepaid rating will require a higher peak workload capability than batched post-paid rating to address transaction peaks easily without failing.
Housekeeping (Other): Most processing in housekeeping is inconsequential in comparison with the other areas listed above, and is without critical timing dependencies. End-of-month (financial) processing is the exception that can produce a considerable peak processing requirement when all transactions are processed for revenue postings.

Depending on the industry and biller, the price of recurring and non-recurring charges can depend on the level of network usage (e.g. increased network usage reduces the monthly access charge). This means that the appropriate prices for these non-network charges cannot be determined until all network usage for the bill has been processed. To address this, the early steps in the billing cycle can become the location for pricing (rating) these non-network charges. (A biller who processes network transactions will find that non-network transactions are a small percentage of the total transactions they rate.)

To minimise the infrastructure required to address the biller's peak processing load transactions should be rated as soon as they are received. By doing this, each month's total processing for rating is spread out over the month. If (post-paid) transactions were only rated at billing time, (relatively) substantial infrastructure would be required to compress each customer's rating into a few seconds or minutes of processing. Such infrastructure would sit underutilised until the next billing cycle. This processing issue is especially important when customers (and their transactions) number in the hundreds of thousands or millions.

Cost of Complexity

Complex rating generates operational costs that increase with the complexity level involved. Examples of these complexity costs include:

Data Collection: The data to support a specific rating method must be obtainable, actually be collected for processing (if it is not already), and stored where it can be accessed and used. This may involve changes in upstream systems to pass data from its source to rating.
Data Storage: Storing collected data for all customers (when many) or specific customers (when large) can materially increase the storage costs of persistent and working databases / files.
Calculation: Complex rating methods may consume more system resources (e.g. CPU) and require a better provisioned infrastructure (e.g. hardware) to deliver the required result.
Configuration: Where the billing software can accommodate the complex rating method, the configuration will need to be performed and tested carefully. More complex rating methods will take longer to implement.
Explanation and Training: Customers (and staff) will require more time and documentation to understand how the rating method operates.
Verification: Once implemented, complex methods are harder to verify. If a customer challenges the amount billed, the biller will have to decide whether to perform a commercial settlement, or perform the detailed verification required to justify their rating / billing calculation.
Correction: If a complex rating method is in error, the manual and automated processing required to fix it can be costly. The billing error may be caused by configuration errors, reference data misalignment, software defects, or provisioning mistakes. Regulators can also provide a source of undesired external change by declaring rate changes that necessitate rerating. The risk is that the verification and correction costs will exceed the initial profit.
Modification: Once implemented, a complex rate method may be modified over time. The billing systems involved may also be modified. Each modification will need to be performed without disruption to the other. During system changes, data flows can be altered or delayed, and this can result in situations that require correction.

As the revenue per billable event (e.g. phone call, SMS, content item) decreases, the costs associated with the rating (billing) process become an increasingly material component of a biller's operational costs. Operational costs will be reduced or minimised by using simpler rating methods.

Tags: Billing, Rating, Complexity, Operational, System Load