purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. Column Archive . Article Archive .

Column - 28 August 2004

Reducing the complexity and hence costs of Rating

Summary

A business may require complex billing, but it will come with operational costs that can grow at or faster than the business' transaction volumes. Each level of complexity requires the billing system to hold more data (possibly for the long-term), and reference it when performing rating. Billing system changes will be more difficult as new development must be introduced without upsetting the complex processes that already exist.

Billers who identify what their billing infrastructure can deliver with little or no development will be able to quickly deliver and bill for new products. The need for system development rather than configuration introduces implementation delay and cost. Billers utilising vendor software packages may have additional delays until new software releases include their desired changes. If their billing vendor declines to include a biller's requests in their core software offering, the biller may need to develop the changes themselves and risk losing their ongoing upgrade compatibility.

Actions

  • Identify what your existing billing infrastructure can deliver through configuration alone
  • Construct preferred billing models that your existing infrastructure can quickly and cheaply deliver
  • Publicise the preferred billing models internally to (customer) contract negotiators and new product developers
  • Require that use of the preferred models be attempted before considering alternate billing models that require billing development
  • Design some approval 'friction' to reduce the quantity of unnecessary development for new billing models

A biller's choice in rating

At its core, rating consists of structures that describe the recurring, non-recurring (one time) and usage charges for the products and services a biller offers. These basic charges can be combined to develop more complex charges that include several charge components (e.g. flagfall, surcharge), and/or charge along several dimensions within the one charge event (e.g. charging for connect time plus downloaded data).

How a business charges can be related to the variable supply cost structures of physical (e.g. water, gas) or virtual (e.g. interconnected phone networks) products and services with the external payments based on the quantities consumed. Other products and services may be produced and delivered by the biller without reference to external parties and the cost structures will be controlled by the biller themselves.

In each case, the biller's business has a choice about how their end customer will be billed, which is (can be) a different proposition to how the biller is charged by their suppliers.

Billing Software

Vendors provide software that includes the common methods through which billing is performed across their installed (or desired) customer base. The software represents how some billers (in local or overseas markets) have chosen to bill their customers. As such, the vendor's software represents the 'high-water' mark (or super-set) of the many methods possible. Depending on the sophistication of the vendor's software, few billers will use all of the billing methods and algorithms available.

As new billing methods are identified, the vendor will receive enhancement requests from their customer base (including some requests sourced from tender requests). Some, perhaps most, but probably not all, of these requests will be reflected into future versions of the vendor's software. Each request included in the core software will be available to the vendor's existing and future customers (i.e. billers), and can be used 'out of the box'.

The basic billing methods will be increasingly covered 'out of the box'. However, each biller is different and is likely to want to use alternative methods not covered by their existing billing software. These alternative methods may be deployed in future releases of their vendor's software (or the vendor may indicate that they will not be included). The biller must consider the importance of each alternative method and evaluate how (or if) it will be delivered.

Responses will include waiting until a future vendor release (with its attendant risk of non- or partial-delivery), developing the capability by modifying their existing vendor software (if the software and licence condition allow), developing custom software that delivers the required approach (but must be maintained by the biller), performing the billing manually (with issues of scale and accuracy), or doing without (using an approach that 'can' be delivered within the existing software's capability).

Complexity Costs in Rating (and Billing)

Complex rating (billing) 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 billing.
  • 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 rating / billing method, the configuration will need to be performed and tested carefully. More complex methods will take more time 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 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 that complicates the rating process (e.g. rate changes that require charges be re-rated). The risk is that the verification and correction costs will exceed the initial profit amount.
  • Modification: Once implemented, a complex rate method may be modified over time. The billing systems involved may also be modified, and this will need to be performed without disrupting any complex rating. During system changes, data flows can be altered, and this can cause situations requiring correction.

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

Product Development: Billing

Billers deploying new products and services can reduce their future operational costs by considering billing as part of product development. If a new product or service can use rating and billing capabilities already present in the biller's systems, the deployment is more likely to be faster, cheaper and more accurate. Where system development is required, the product launch may be delayed until the billing can be developed and deployed.

Billers can guide the billing design of the product development process by providing clear guidelines on how billing for new products should be performed. This will build or sustain a simple and lower cost billing environment rather than developing product specific complexities that build long-term cost into the biller's business. Complex rating methods, once implemented, will be harder to remove, and indeed may be extended to other product suites (an undesirable example of reuse).

Eventually the biller will require a new billing model that cannot be accommodated by their guideline billing models. In this case, the biller's management will need to understand how the proposed development costs of a new billing method are balanced by the perceived benefits that will be delivered (i.e. above the use of existing 'no-development' methods). By introducing a review step (by senior and/or experienced staff) into the development pipeline, product developers will be required to justify why a higher-cost billing approach is appropriate.

Tags: ,

[ Share with others ]

Post this page to a social bookmarking site:

delicious logo delicious diggit logo Digg it furl logo Furl google logo Google
reddit logo reddit stumbleupon logo StumbleUpon technorati logo Technorati yahoo myweb logo Yahoo MyWeb

 

Other 'purebill' columns

Previous column: Mediation's support of differentiated charging

Next column: Four algorithms that address most rating situations

All previous purebill columns can be found in the archive section.

Recent Updates

Sign up to receive a brief text email when a new purebill column is published.

JUMP TO TOP go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .