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 . Provisioning Latency .

Note 29: Provisioning Latency

Posted: 26 April 2007

Network maintenance cycles with an extended elapsed time can impact the billing process adversely. Once network provisioning is performed, network usage may be received by billing and not be processable due to the lack of a billing arrangement, or may be processed incorrectly due to an outdated billing arrangement (i.e. not yet modified).

Billing must be updated 'in time' for future charges to reflect the maintenance. Three examples can illustrate a range of appropriate timelines that can apply depending on the context:

  • A residential customer establishes a new electricity connection. The customer's billing arrangements can be maintained with an elapsed time measured in days. This is because their next usage (charge) event will be a meter reading taken in a month or two. Whilst the customer's initial meter reading may be delayed in this way, the biller may want to process the customer's final reading more promptly. This is both to provide prompt customer service and reduce the credit risk of a relocating customer.
  • Once requested, a new calling card's details can be processed in billing (and the network) overnight (within a day) to align with the card's mailing timeline. Since phone calls can't be made on the network until the customer receives their card, these maintenance delays are acceptable. This timeline would be drastically shortened if the biller allowed customers to self-provision their calling card on the internet and use an interim identifier until the card arrived. In this case, network and billing changes would need to be performed with a great deal more speed to capture the revenue opportunity of a customer who makes calls immediately.
  • A customer purchasing a new mobile phone expects the connection and billing details to be applied in minutes. The customer may be waiting in the retailer's shop whilst the order is processed, and calls as they leave the shop will be received by billing in minutes or hours. All updates must be completed if the mobile phone is prepaid since the customer's outstanding (credit) balance will be checked and the call will be rated (in billing) before any call can be connected.

Real-time, asynchronous and batch

The speed with which changes are made will be based on whether changes are applied in real-time, asynchronously or in batch.

  • Real-time is the fastest method of performing changes, but comes with a higher system cost to provide the necessary operational readiness. All the required network and billing systems must be available when the order is taken and applied. If any required system is unavailable the order cannot be completed. Since all processing is performed in the one step, the elapsed time of a complex transaction may be undesirably long and impact a customer's perception if they are waiting on the phone or in a shop. A person-to-person phone call is an example of a real-time transaction - if the recipient is unavailable the call cannot be completed.
  • Asynchronous processing can be performed at a similar speed to real-time, but it is more tolerant of unavailable systems and high processing loads. Asynchronous transactions are processed as the necessary systems are available with the processing capacity to complete them. Often asynchronous processing has a (low) latency similar to real-time transactions, but asynchronous transactions can be captured and initiated in less than ideal circumstances. If a required system is unavailable, asynchronous transactions wait (i.e. are delayed) until the required system is available. Processing is then resumed. Email is an asynchronous system that allows messages to be exchanged without requiring the recipient be present when a message is sent.
  • Batch processing has the highest latency because transactions are only processed periodically. Individual transactions are collected (batched) before being periodically processed. 'Periodically' may mean anything from every hour to once a week. A transaction that just misses one batch must wait until the next batch is processed. Batched transactions may be passed to billing from other applications. Regular (physical) mail is an example of a batched system that picks up and delivers letters in small batches. A letter that misses a mail run must wait until the mailbox is next cleared.

All three of these approaches can be used to automate the network provisioning and billing maintenance processes. Such automation can both reduce the staff required to maintain network connections (particularly as the network or customer base grows), and provide the customer with faster network connections and updates.

Aligning network and billing updates

The dual update of both the network and billing presents the dilemma that both must be updated, but only one should mark the 'true' record of a change. Is the change official when applied in the network, or when the billing system reflects the change in the billing arrangements? The answer to this question must be decided by each biller and may be driven by their systems' ability to correctly support the decision. A new biller may have a choice on which reflects the 'true record', but an existing biller may have their answer predetermined by previous design or policy decisions.

If changes are marked when the network is updated, billing needs to be updated with the results and date effectiveness of the network change. In this situation, if billing is updated before the network, delays to the network change may require additional maintenance in billing to reflect the network update's actual result.

Accommodating provisioning delays in billing

Networks can be placed into three categories:

  • Continuously connected networks (e.g. water utilities) where connecting a customer is a 'virtual' rather than physical step (aside from perhaps an initial physical meter reading).
  • Disconnected networks that must be connected for the customer to benefit from their use. The connection can be physical or virtual, but until the connection is performed there is no way that the customer can use the network. e.g. music distribution (Apple iTunes store), internet service provider (ISP), premium email service provider (e.g. fastmail)
  • Networks, covered by the two earlier categories, where the customer must wait for a network 'identification token' before using their network connection.

In the third category, if billing can support temporary 'tokens' that allow immediate network access, customers can connect and begin using the network whilst the long term 'token' is delivered. Customers are authorised to access the network. The issue is the token used by the network (or billing) to validate or identify their access or use.

An example of an 'identification token' is a tollway's 'electronic transponder'. The customer must wait until the transponder is received in the mail before using the tollway's network. The customer may want to use the network immediately, but can't. An interim solution in billing can allow customers to use the tollway immediately rather than with a few days delay.

Tollway billers use the electronic transponder, or a combination of the vehicle licence plate and electronic transponder, to validate and bill for tollway journeys. Under this approach, the customer cannot use the tollway until their transponder is delivered. An alternative is to allow new customers to use the tollway for a few days without the transponder, and utilise their licence plate as a 'temporary identifier'.

New customers taking this approach would have their licence plates identified from the photos of 'unauthorised vehicles' (i.e. journeys without transponders), and be charged as if the journeys were legitimate. Tollways that can use licence plate recognition for all journeys (e.g. CityLink in Melbourne, Australia) could implement this process programmatically. In such cases, the billing system could waive any penalty fees usually applied to customers using the tollway without their transponder.

This approach would only work for vehicles that use a single transponder. Vehicles such as taxis that use multiple transponders (i.e. one per driver) cannot use the vehicle's licence plate as a temporary and unique substitute.

This approach allows the customer the benefit of using the network immediately, generating additional revenue and goodwill. The solution is temporary and only given in a way that avoids financial risk to the biller (i.e. the car registration is not easily falsified).

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 28: Bundle Provisioning

Next - Note 30: Transaction Collection / Mediation

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 .