purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. Column Archive . Article Archive .

Column - 19 February 2006

Operational support levels differentiated by billing system needs

Summary

Whilst contemporary billing software can support the consolidation of multiple billing systems onto one platform, raising the support level of all transactions to that of the most demanding can greatly increase ongoing operational costs.

Real-time billing must operate with high availability systems, but there can be less demand for wholesale billing (with its lower margins) to receive the same level of support. Support levels depend on an industry's business models, and vary between billers in the same industry based on the perceived benefits, in both financial and marketing terms, that different service levels offer.

Billing systems within a business

There are many reasons why a biller may operate multiple billing systems, but seven billing system types that a biller may operate include:

  • Prepaid billing: This processing terminates customers' network access (including in-progress transactions) when funds are exhausted, and processing must support 24x7 real-time balance management of customers to ensure they have sufficient credit when transactions start and as they continue. Transactions must be fully priced in real-time (including all taxes) and deducted either once for fixed price transactions, or on an ongoing basis where charges vary by continuing use.
  • Post-paid billing: This processing type is based around a batched processing model with these platforms collecting transactions from (possibly) many networks and periodically collating them into customer bills. Interim counts and financial balances may be held, but will reflect only the batch files processed to date. Additional charges may have been incurred by customers, but until the corresponding files are processed, their details will not be available to staff and customers alike.
  • Wholesale billing: Related to the processing on retail platforms that supports prepaid and post-paid billing, these platforms cater for a small number of (generally) very large customers who resell a network operator's products to their own retail customers. Whilst 'retail' (corporate) accounts may be 'large' containing thousands to tens of thousands of services on one bill, wholesale customers may bill hundreds of thousands of services on one bill (including any embedded corporate accounts!), necessitating systems tuned to address the 'lumpier' account sizes involved.
  • Content Settlement: Revenue billed to / collected from customers is shared with the content owner based on negotiated settlement agreements. The settlement frequency and operational access to interim data can be points of negotiation, with wide variations possible on what data is made available and when it is supplied.
  • Interconnect Billing: Separate from billing for wholesale network resale, billing must be performed for inter-network transaction termination and network transit. These billing processes do not participate in completing transactions (prepaid), nor will individual transactions be closely examined by end customers (post-paid), but instead high-volumes of low margin charges must be processed to form a highly aggregated bill for a network operator's network partners (customers).
  • Standalone rating engines: Billers may retain existing billing infrastructure and add a contemporary rating engine to deliver advanced pricing and bundling. The rating platform(s) can operate with different (e.g. higher) support levels to the existing billing infrastructure, and can provide updated capability to the existing billing system over the long-term, or be an interim solution until the existing billing platform is replaced.
  • Billing on Behalf Of (BOBO): Billers (or a bureau) may offer to perform the billing function 'on behalf' of another retailer. Network operators who resell their network may offer this to their wholesale customers as a 'value add' to generate additional revenue from their billing expertise and systems, and to bind the wholesale customer to the operator (since leaving means also finding a billing platform).

Different supports levels within billing

Whilst no outage or system failure is welcome, billers can customise each billing platform based on its transactions, payment model and customer group, aligning the business risks and margins of each platform with its support costs.

Real-time billing - Controlling customers' access to the network, these billing systems are often tightly integrated with the biller's network, and must support high availability and low response times to return prompt and consistent responses to the end customer. When real-time billing systems are unavailable, customers cannot commence / complete transactions and the biller cannot collect the resulting revenue. More expensive billing environments are deployed to ensure billing continues to operate when minor failures occur, and that major failures can be recovered from quickly.

Billers who provide equivalent products to their prepaid and post-paid network services may need to perform real-time processing across all services since any service may bill products under either payment model. Billing all network services using this approach will increase the biller's operating and system costs over operating separate prepaid and post-paid systems.

Retail / Wholesale billing - Since these billing systems do not participate in completing transactions, they can tolerate minor unavailability. When failures occur, transactions will be cached in upstream applications until the billing system is available and processing can recommence. Customers and staff will be unable to access billing data whilst these systems are unavailable.

The natural patterns of customer and staff availability mean that support level needs will be highest during the day from Monday to Friday. Outside of these hours the biller staff may be unavailable, or existing scheduled outages may make data access difficult already. The biller can decide to differentiate the support levels between that required during high demand periods, and that required out of hours and on weekends.

The support required for large (retail) corporate customers and wholesale customers can also affect support levels. The introduction of a biller's wholesale / reseller parters into the support equation complicates the availability questions since the reseller's retail systems may be integrated with the network operator's wholesale systems. Availability equivalent to the biller's own retail operating unit may be acceptable, especially where industry regulators seek comparable non-price terms and conditions.

Content Settlement - Settlement frequency and access to pre-settlement data drive the support levels required by content settlement systems. Less frequent settlement allows the peak-processing demand to be shared over a wider period of time (days) rather than processed in near-real-time (minutes / hours), and provides scope for small system outages to be tolerated.

Where required, access to pre-settlement data 'as of' of the previous day will be less expensive to support than a requirement to deliver real-time or 'last hour' totals. Content parters may wish to access sales data to monitor the popularity of content items and their pricing.

Interconnect billing - The billing for network transit and termination can operate with lower support levels than other billing since the processing is disconnected from the network and retail billing, there are a relatively low number of customers (i.e. connected networks), and customers and staff are less likely to need immediate access for inquiries on individual transactions. Since the margins are low, being able to specify a lower availability measure and longer response times when failures occur allows operational costs to be minimised.

Like content settlement's monitoring of content popularity and pricing, interconnect transactions may be monitored to support Least Cost Routing (LCR) decisions. To minimise operational costs, access to interconnect transaction totals for LCR may be supported at levels equivalent to that of the interconnect billing platform, rather than force an increase in the support level of the interconnect billing platform as a whole.

Billing on Behalf Of (BOBO) - The level of support provided to BOBO will depend on the contracts negotiated with an operator's retail partners. The BOBO billing platform can operate at higher (or lower) support levels where BOBO is performed on a separate retail platform to the network operator's own retail billing (e.g. for reasons of security or functionality).

A billing example requiring high availability

Google Adsense / Adwords provides an example of 'real-time' billing (Adwords) teamed with near real-time content settlement (Adsense). Advertisers have their prepaid balances decremented by the amount charged for each 'click' performed by web surfers, and where the advertisements are present on a non-Google website (publishers with Adsense) a percentage is shared (settled) with the website's owner. An Adwords advertiser's account balance ('network' service) may be accessed (decremented due to a 'click' / incremented by additional funds) at any time, and website owners (user / customer) may check their balances (revenue share) at any time.

Website owners expect that the revenue share / settlement amount Google presents is accurate and represents the amount they will receive 'in the mail'. Google must ensure that advertisers' balances are reduced consistently to reflect 'clicks' on advertisements, and to avoid lost revenue when advertisements are clicked upon but cannot be charged for.

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

 

Other 'purebill' columns

Previous column: Interconnect Billing and Reconciliation

Next column: Archiving billing data for the long-term

All previous purebill columns can be found in the archive section.

Recent Updates

Sign up to receive a brief text email when a new purebill column is published.

JUMP TO TOP go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .