purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. The Billing Notes Index . Bundle Provisioning .

Note 28: Bundle Provisioning

Posted: 08 April 2007

Difference between three provisioning models

Bundles 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 impact

Despite 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:

  • A negative impact to cash flow caused by delays in initiating the billing for new services, charges and connections.
  • Depending on the network, customers may be unable to use the network until their billing details are established. e.g. a prepaid mobile phone with a credit balance delayed in billing, an internet store that allows music to be downloaded waiting on the (increased) number of tracks included in a customer's (new) bundle
  • A new service connected in the network may generate usage charges. Without a billing arrangement in place, billing will be unable to guide these calls to a customer's account causing processing delays. Delays in usage events may generate frustration (e.g. calls charges are not visible on an invoice (yet!), prevent the customer claiming charges from their employer, delay calls causing them to appear all at once and generate a large customer invoice, or delay calls so long that the biller is unable to charge for them (e.g. based on an industry's billing 'code of practice')
  • Some orders (e.g. churn) may cause charges to change their 'ownership' between retail service providers or their customers. A delayed order can mean charges have already been billed by the time the order is finally processed. Although the charges can be backed out from the incorrect invoice, the biller may no longer have sufficient charge information available to bill the correct customer. Any industry metrics for the elapsed time of 'churn completion' must also be considered.
  • Customers can be upset and frustrated when delayed orders place (old) charges on subsequent invoices. Many customers expect that their charges are presented on an invoice in a timely manner. To support this, government regulators may mandate age limits for older charges.

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 Activation

Normally, 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: , ,

[ 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

 

Links to other Notes

Previous - 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 go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .