|
purebill.com Stephen Jones writing on billing and application migration |
![]() |
| . | Home | . | About | . | Archive | . | Links | . | Billing | . | Reference | . | Subscribe | . | Search | . | . |
Note 28: Bundle ProvisioningPosted: 08 April 2007 Difference between three provisioning modelsBundles can include connections on multiple networks. Energy (gas and electricity), phone (mobile and fixed), and cable (broadband and TV) bundles can generate multiple activations from one order. To support such bundles, each provisioning configuration will need to perform different processing. The differences between each configuration exists in where the work is performed. The same (or similar) work must take place, but its location can make the work easier to perform and build future flexibility when changes are required. Billing via network processing (Configuration 1): The order (with bundle) will need to be sent to each relevant network (or perhaps all networks if the relevant ones were not easily identified). Each network will need to identify the applicable elements of the order. An additional processing step is required in, or just before, billing to receive and recombine each network's provisioning results. The recombination step is needed to ensure that all order results have been received from the appropriate networks, and that the results are error-free. Once recombined, either the billing changes can then be performed and/or the provisioning errors can be addressed. Network processing via billing (Configuration 2): Billing can receive and apply the bundle from the ordering application, but will need to understand how to call the appropriate networks. This requires a network interfacing process (including appropriate order disaggregation), and the recombination processing outlined for Configuration 1. Since the billing arrangements will have been updated already, any network errors may require reversal processing in billing. Separate billing and network processing (Configuration 3): This approach supports the easiest billing interface since the interface can remain (largely) independent of any network processing. The order management process interacts with the appropriate networks, interprets the provisioning results (including any errors), and passes the order directly to billing where any bundles can be established directly. The need for a recombination step in billing (as per the other two approaches) is avoided because the order management function performs this work. When new networks are added, the order management process can be extended without either billing or the existing networks needing to understand the new network's interface or processing specifics. An errored order's billing impactDespite the validation and care taken in the ordering process, orders will error during network provisioning or billing and require human intervention. Errors can be caused by misaligned validation processes between ordering, network provisioning and billing, or can be due to a misalignment between the customer information activated on the network and the details held in billing and ordering. Error processing is likely to be addressed in the network, ordering or order management applications depending on the system configuration and the biller's design preferences. The impact to billing when an order errors include:
Ideally, the error correction process, whether in the network, billing, or order manager, needs to provide the biller's staff with the details of the order and the list of (preferably all) errors. Suggestions on common causes of the errors and the likely methods to correct them can also be provided. Any updates to errored orders must be tracked providing an audit trail. This trail can be used to identify where changes were made in error (or fraudulently) during correction. Automatic Network ActivationNormally, a customer establishes her billing arrangements before she begins to use the network. Her use of the network is then governed by what she ordered. This approach allows the biller to accurately identify customers and perform any pre-qualifying checks. e.g. a credit check. Customers are denied access to the biller's network until they can demonstrate they are a reasonable credit risk, and the biller can identify the customer if the relationship turns bad. A less common approach is where the customer's use of the network is used to drive the establishment of the billing arrangement. Billing details are only captured 'after' the customer has made use of the network. To avoid free-loading, this approach relies on two criteria being satisfied: customers can be identified clearly from another (accurate) source, and the credit risk to the biller is low. The two examples outlined below, for a tollway and telephone call override, fulfill these criteria. In each case, the customer consciously uses a network with which they have no existing billing arrangement, the biller sources the customer's details from an outside source that holds accurate customer details, and the customer is then billed for their network use along with any other appropriate charges. The first example is a tollway network (which cannot easily deny access to customers' vehicles). Usually, customers pay their tollway fee with each journey, or pre-provision a billing arrangement metered using their vehicle's registration plate, or an electronic transponder. The alternative of automatic provisioning obtains the customer's details using the trigger of the customer's first tollway use. The government's vehicle registration authority can serve as the accurate source of a customer's details since the authority is required to maintain an accurate register of vehicle ownership. Since vehicles are locked against casual use, the presence of the vehicle on the tollway explicitly authorises the vehicle's journey and the establishment of a new billing arrangement. The second criteria (of credit risk) is met by the threat of a disproportionately large fine. A large fine (when compared to the tollway fee) can be levied against the vehicle's owner if payment for the tollway's use is not forthcoming. The second example is where a customer using a fixed telephone line performs a long-distance call override to obtain a better call rate. The call override (e.g. a prefix of four or five digits) identifies a retail phone provider different to the customer's preselected (default) provider. When the customer has not used this override provider before, the override provider contacts the customer's preselected provider, probably electronically, and obtains the customer's details. The provider then uses these details to build a new customer billing arrangement. The customer is then billed (by the override provider) for the call. The first criteria is satisfied by leveraging the incumbent provider's existing identification of the customer. The second criteria can be satisfied by placing the overridden call on the incumbent operators invoice thereby creating a threat of disconnection for non-payment, or by escalating non-payment of the override provider's debt until it appears on the customer's credit record. Placing the call on the preselected operator's invoice can be cost effective when the customer is likely to incur only a small number of low value charges. Tags: Billing, Bundle, Provisioning [ Share with others ] Post this page to a social bookmarking site:
Links to other NotesPrevious - Note 27: Operational Billing / Provisioning Models Next - Note 29: Provisioning Latency 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 | . |