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 . Operational Considerations .

Note 32: Collection: Operational Considerations

Posted: 10 May 2007

Operational impacts on processing

Operational aspects affecting collection processing include:

  • Transaction storage: The network, collection and mediation are transitory functions that retain transaction information for only a short time before passing it downstream. To address peak-load periods, the network, collection and mediation systems need to provide sufficient local storage to hold sustained bursts of high transaction volumes.
  • Availability: Some networks will process all transactions through to the billing repository in real-time, but this requires a more expensive high-availability infrastructure. The trend in telecommunications is to perform more processing in real-time, but this needs to be balanced against its more expensive infrastructure.
  • Throughput: If the system capacity of the collection and mediation function is limited, or is operating at near capacity, transaction backlogs may form. For example, a tollway's collection system may generate a backlog during 'peak hour' that is cleared in the following hours, or a phone network may need to catch-up the workload generated around midnight of New Years Eve.
  • Collection redundancy: To reduce congestion, a daily fee is charged for vehicular access to the London CBD. Fixed cameras capture details of vehicles' access on the CBD's entrance roads. Portable vans are also used as replacements for the fixed cameras to cover maintenance periods or equipment failure.
  • Implementation: When existing tollways with toll plazas implement electronic billing, they often reserve a few lanes for customers with electronic tags. The faster processing in the tag lanes encourages customers to sign-up. Once any implementation issues are addressed, all toll plazas can be configured to read the electronic tags which are (now) more prevalent across the customer population.
  • Coordination: Transactions between different networks (e.g. fixed and mobile phones) may need to be exchanged with different collection and mediation platforms to correlate all a cross-network transaction's pieces.

Error Management

Transaction errors need proactive management to reduce the length of any revenue delays, and the level of unbillable revenue (leakage). Errors not fixed quickly will not appear on the customer's invoice, delaying the customer's corresponding payment. Errors that cannot be fixed represent money the biller cannot collect.

In networks with high transaction volumes, a single network problem can result in a substantial number of errored transactions. Proactive identification and escalation of errors minimises the duration of their impact, reduces the cost and effort of their correction, and where the errored transactions cannot be corrected reduces the amount of lost revenue. If an unrecoverable error is systemic (rather than episodic), the longer it takes to fix the error's root cause, the more money will be lost by the biller.

As they are detected, errors can be classified and grouped for more efficient resolution. Criteria can include the date, error type, transaction type and source network. This allows the biller to identify large error groups and detect when a large number occur all at once. Reporting and analysis can be used to identify trends caused by network failures and fraud. The criteria provide a segmentation basis that can be used to focus on specific transaction groups when errors are corrected.

Some billers need to pay other businesses for transactions that use the other businesses' networks or other services (e.g. content). Depending on the agreed settlement basis, a biller may need to pay these other businesses regardless of the biller's ability to collect money from its customers. This makes it important to actively manage errors that involve settlement payments to external parties.

Error Correction

Errored transactions can be addressed individually or in bulk. Unusual or low volume errors are usually addressed individually due to the setup effort to apply bulk corrections. Where a network event (or a systemic error) generates a high volumes of errored transactions, the more cost effective manner of addressing errors is in bulk. The extra cost and effort spent in configuring the bulk mechanisms is repaid by the higher transaction volumes that can be addressed.

Collection and mediation systems will have different error management capabilities. Their ability to manipulate errored transactions will vary and may rely on third-party products or custom developed interfaces.

Ideally, individual errors can be modified using an online screen that presents the transaction in question, highlights the fields in error, identifies what the errors are, and allows the fields to be updated. To improve the accuracy and productivity of staff, context-sensitive error explanations can be offered with suggestions on how to fix the error. For common errors, this assists new staff. For unusual errors, these suggestions assist all staff including the most experienced. Once updated, transactions can be revalidated to ensure the modifications performed have addressed the identified errors completely without introducing any new ones. Bulk correction mechanisms use similar processing, but systematise its application. Transactions may be automatically corrected or resubmitted for validation, with those still in error escalated for human review.

The criteria by which errors have been classified can help prioritise their correction order. Even though no financial value has yet been placed on these transactions, those transaction types known to be of high value can be examined and corrected first. For productivity reasons, errors of one type can all be worked upon at once. Alternatively, the oldest errors can be worked upon to reduce customers' inconvenience, and ensure historical errors are closed in a timely manner.

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 31: Network Collection

Next - Note 33: Data 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 .