|
purebill.com Stephen Jones writing on billing and application migration |
![]() |
| . | Home | . | About | . | Archive | . | Links | . | Billing | . | Reference | . | Subscribe | . | Search | . | . |
Note 36: Key Steps of RatingPosted: 04 September 2007 Key StepsThe timing and physical implementation of rating can vary depending on whether the customer's service is prepaid or not, but broadly, rating generates a priced transaction by performing processing in the following areas: Transaction reformatting (optional): Transactions may be received suitably formatted for processing, but those transactions not pre-processed through mediation to the rating application's internally standard format will need reformatting (at a minimum). This reformatting, similar to that performed in mediation, reduces the level of exception processing required in rating. Transactions may be duplicated to address different charging approaches (e.g. both caller and recipient charged), with each transaction duplicate making its own path through rating and receiving a possibly different final price. Where transactions are sent to multiple billing systems, a standardised format may not be possible. Reformatting also helps to isolate rating from changes made in external networks and interface formats. Identification: Each transaction must be identified before the required processing can be determined. Files and transaction streams may contain multiple transaction types with each receiving different processing within rating. Transaction type can also be used as a determinant. Reformatting may be required to standardise field locations before they are used in identification. Validation: Transactions may have passed through earlier mediation steps that validated their format and performed basic field checking. This initial validation will have been applied without knowledge of the end customer. Upon reaching rating, detailed customer and marketing information becomes available allowing additional validation to be performed. More sophisticated transaction and billing-specific errors can be detected and addressed. For example, validation can be performed against a customer's active service list and pricing plans. Determine Ownership: Rating can vary based on a wide range of different criteria. Details of who transactions belong to can provide additional rating determinants as well as details of the specific pricing plans provisioned against the customer. Customer specific (negotiated) or market segment specific rates can then be applied based on this additional information. Rating can be performed without knowing a customer's details, but without the customer's details available to influence the final price, rating can only be performed generically. Obtaining more information about a customer also acts as a default validation step. If a transaction's service cannot be found in the billing database(s) then it will be errored. Generically-rated transactions may be discounted or re-rated during the billing cycle, but this approach is unsuitable for prepaid transactions which must accurately calculate the final price before deducting it from the customer's available balance. Price the transaction: Now in a consistent format, validated and with the customer's details known (including any special rates), the transaction's price can be determined. The appropriate criteria, algorithms and rates obtained from customer-specific or biller specified rating plans are applied. This is the most complex step in the rating process, and its complexity will vary by biller, industry and customer segment. Guiding: This step is related to ownership and who pays for transactions. Examples of elements that can influence this processing include 'reverse charging' of calls, toll free calls, transactions where both originator and recipient pay, and 'assumed' financial responsibility (e.g. child pays the bill for elderly parents, business pays for specific calls made by their employees when at home). The rated transactions are stored against the appropriate customer's service(s) until their extraction to the bill. With the appropriate infrastructure, transactions may be viewed by customers and the biller's staff, though the prices stored may not be the final amounts charged due to subsequent discounting and taxation. Prepaid RatingIn prepaid processing for variably priced charges, before the transaction (e.g. a phone call) can be approved a rating step must be performed to ensure the customer has sufficient available funds. Funds can be reserved and later confirmed at the transaction's completion. Different circumstances may need additional reservations for ongoing transactions (e.g. long phone calls), with transactions terminated when funds are exhausted. Prepaid processing, involving a real-time interface between the network and rating (billing), must perform these steps quickly. Reformatting and validation may be minimal based on a limited transaction set, and a defined transaction format. Once a transaction is finished, a record will be generated by the network. This record's details can be placed on a customer's activity statement (if provided). Other business functions can also use these records to drive their processing (e.g. fraud analysis, network load analysis, interconnect settlement). Not all prepaid billers generate an activity statement. For example, prepaid mobile networks may reduce their costs by avoiding the processing and handling required to generate a paper bill. Other billers may provide transaction details electronically online where they can be printed by customers. Networks can address prepaid balance recharging in different ways. Phone networks may prevent calls until the customer organises a top-up payment, whereas tollways may recharge the customer's balance (from a credit card or by direct debit from a bank account) when it falls below a lower limit (e.g. $5). Error ProcessingDuring rating's validation processing, errors may be discovered and these must be addressed. Error processing similar to that described for mediation is used to correct the (possibly) large number of transactions that may error. Similar issues arise as part of the rating function between when to perform individual versus mass error correction. Error correction in rating and that performed in mediation differ in two important respects. The first is that transactions processed in rating are likely to have already received some level of correction and validation (e.g. in mediation). Due to this, errors are less likely to be found in the format of the transaction and its values. The second is that the customer information available during rating can provide a richer context during error resolution. The validation rules that trigger an error can be assessed in the light of the customer's products and previous billing history. Validation errors found during mediation are likely to be systemic and due to network problems. Post-mediated transactions are more likely to error in rating for reasons of customer and product configuration rather than intra-transaction formatting errors. Timing misalignments between the ordering, provisioning and billing processes can also generate customer-related errors. Services can be provisioned in the network but not (yet) in billing. As a result, the network can generate (usage) transactions for which no customer can be found in billing. Rather than correction, the error processing for this error is automated transaction recycling until the customer's billing entries are established. If no entry is found after a period of recycling then a different and more severe error can be flagged for manual review. Some transactions may be passed for manual review due to unusual transaction characteristics (i.e. warnings). For example, extremely long phone calls or suddenly high electricity consumption may be due to system problems rather than customer behaviour. After review, these 'warnings' may be released for billing, and, to ensure they don't re-error, can be flagged against specific validations (other errors should still be identified). Tags: Billing, Transaction, Rating [ Share with others ] Post this page to a social bookmarking site:
Links to other NotesPrevious - Note 35: Transaction-level pricing (Rating) Next - Note 37: Rate Plans and Charging Recent Updates
Sign up to receive a brief text email when new purebill postings are published. JUMP TO TOP
|
. |
| Comments welcome: stephenjones(at)purebill.com | Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap | . |