|
purebill.com Stephen Jones writing on billing and application migration |
![]() |
| . | Home | . | About | . | Archive | . | Links | . | Billing | . | Reference | . | Subscribe | . | Search | . | . |
Column - 28 August 2004 Reducing the complexity and hence costs of RatingSummaryA 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
A biller's choice in ratingAt 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 SoftwareVendors 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:
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: BillingBillers 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. [ Share with others ] Post this page to a social bookmarking site:
Other 'purebill' columnsPrevious 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
|
. |
| Comments welcome: stephenjones(at)purebill.com | Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap | . |