Key Dimensions of Scale in Billing

Summary

Businesses that bill range from the very small (local government) to the very large (country-wide, full-service telecommunication carriers). The processing required to support the small biller must necessarily differ from that required by the largest. The change of scale, as smaller business grow their customer-base, product range and geographic scope, can require the replacement of billing infrastructure that was once suitable at the smaller scale, but that is no longer capable of supporting the business' growing needs.

Even within an industry, the impact of scale can change quickly how billing is performed, especially when industry regulation (electricity metering moving to quarter hour interval metering) or customer preferences changes within a short period of time (transition from post-paid to prepaid).

Dimensions of size and complexity in a billing system?

Billing infrastructure dimensions that influence systems' scale can depend on seven key dimensions:

Customer: This is the measure of unique individuals and businesses that the biller maintains a relationship with. This dimension is often a weak indicator of change since in most mass-market billing there is a one-to-one correspondence between 'customer', 'billing account' and the 'service point'. But when corporate customers with many billing accounts receive processing based on their 'aggregate' spending, the number of and relationships between customers' billing accounts will drive any complex aggregation processing effort and their supporting systems.

Smaller businesses, such as local governments and smaller ISPs, have customer numbers measure in the thousands or tens of thousands. At this level, and depending on the other dimensions, the billing process can generally be performed on modest hardware, and with relatively small periods of peak processing.

Customers are not as useful a measure for wholesale billing environments which are in essence a B2B relationship whose core characteristic obscures retail complexity from the wholesale biller. A wholesale biller will often have a customer list measured in hundreds to perhaps a few thousand. Of these 'wholesale customers', a few are likely to be much 'larger' than the 'average' and account for a large percentage of services billed (hundreds of thousands) and transactions processed (e.g. a Zipf distribution of customer size).

Billing accounts: Billing accounts drive the number of bills or statements that must be produced and this, along with the billing/reporting frequency and transaction volumes, drives the size of the 'bill cycle' process that transforms billable events into a form that prompts the customer to pay.

The complement of 'bills produced' are the 'payments received' that reduce customers' outstanding debt. Financial processing must maintain each billing account's financial balances, receive payments / adjustments / disputes against bills, measure revenue by product (say) and perform financial reporting. The processing required for end-of-month financial reporting can be material since it often requires a full pass across all billed and unbilled transactions (to measure revenue and prepaid product liabilities) and account balances (to measure debt and cash liabilities).

Service points: Each billable service point (e.g. network connections, properties served, electronic tollway tag) provides a variable against which customers' preferences can be customised requiring differentiated processing. Each service point also provides locations at which billing disputes can be raised.

The aggregate number of service points can drive the quantity of customer support a retail biller is likely to need. Where services are provided on a wholesale basis, the level of support provided by the biller is reduced since initial levels of 'retail' customer support are provided by the retail biller purchasing the wholesale biller's services. The wholesale biller is interested in reducing their support costs below that of a retail relationship because the reduced margins available on wholesale sales do not support the same level of 'servicing costs'.

Transactions: The transactions performed per service point (e.g. calls on a phone network, car trips on a tollway) are a major influence on how 'large' a billing system must be. For example, billing a recurring charge once a year has a much simpler operational requirement than billing tens or hundreds of telephone calls per service on a monthly basis.

This particular dimension can change in a short time, and cause billers difficulties when their billing systems and related infrastructure cannot scale quickly to accommodate the new operational needs.

An example of such a change is the impact of interval metering on electrical utilities that must move from a single meter reading taken every 3 months to readings performed every 15 minutes (an increase of 8,640x). The orders of magnitude increase in transaction volumes that flow from this increased frequency are unlikely to be handled by existing infrastructure without changes or preprocessing at a best, and complete replacement at worst.

Product scope: A biller who sells only a few products (e.g. web hosting, cable TV) will have simpler billing needs than billers with a product catalog of thousands of products (e.g. content providers) that can be sold in isolation or customer chosen combinations. Price changes and availability can also introduce additional processing workload.

Pricing complexity: Complexity is a measure of the number of different pricing methods that are available, the level of complexity built from them, and the data that must be aggregated in one place to support the calculation. Bundles and contracts also increase complexity as they introduce conditional processing to products that would otherwise be offered at standard prices.

The more complex the pricing combinations, the greater the processing cost that must be incurred by every transaction 'in case' it is required, even if the complexity is not used on most transactions. Billing processes must allow for any transaction to use the greatest available complexity and operate with more complex data models and related reference information as a result. This is a circumstance where custom billing solutions that focus on just the functionality required can outperform generalised solutions.

Real-time versus asynchronous processing: Billing performed in real-time (e.g. prepaid mobile phone calls) must be available continuously (24x7) and able to address peak processing loads at any time. Billing performed asynchronously is often post-paid and its infrastructure can address peak and off-peak processing by dimensioning based on average expected processing loads.

This dimension can be an infrastructure multiplier for real-time processing since it necessitates infrastructure redundancy and increased processing performance (speed) to ensure a timely and reliable (billing) response. The sizings derived from other dimensions are increased depending on how responsive the processing must be.

Staffing

Businesses with a larger customer / account / service bases must develop systems that scale to address their expected volume of inquiries, disputes and other customer interactions. Some interactions can be automated and performed by customers via self-service portals, be captured from the customer using forms and addressed offline with slower timelines, or at worst require staff standing ready to address customer's immediate questions and support needs.

These support systems may be electronic and asynchronous (e.g. via email), or support real-time conversation through call-centers or internet chat sessions. The volume of customer interactions, hours of operation, and the sophistication of the interactions permitted will drive the systems that must be established and supported by the biller.

A smaller biller may provide reduced hours for customer inquiries from a central location with limited or no self-service, whilst a biller with a larger customer base may maintain 24x7 call centers and systems that ensure the same information is available at widely distributed support locations.

The biller's industry also drives the support requirements. Some billers will have limited or no internet access to billing (e.g. local government), whilst others will only support their billing electronically (e.g. email providers, web hosting, domain name registration).

Software

Product and pricing complexity will impact the sophistication required in billing related systems. Areas impacted can include:

Rate of product change: Content providers must load new content details on a regular basis (daily, weekly) and solutions must be found to accommodate these changes. Content can also change along the classification dimension, such that a song moves from 'New Entrant', to 'Top10', 'Top 40' before settling into 'One hit wonders' / 'Pop'.
Rate of pricing change: Pricing may vary regularly, and content provides another example of where changes can be dynamic. For example, the price charged for a song may vary as its classification changes, or special content (e.g. 'The Beatles') may be offered at different price points.
Adaptability: An industry may require only low levels of adaptability (e.g. local government), or require ongoing and repeated change as a core part of 'doing business' (e.g. content and mobile phone billing).
Upgradability: What options exist to move the software between systems as the billing load increases? What alternative platforms can be supported? How can additional hardware be employed to increase capacity as billing needs change?

Data

As a key business asset, a biller's data must be available for their own needs, as well as those of their customers:

Data Volumes: As the level of billing related data increases (customer, transactional, financial), the systems to manipulate, backup and recover the biller's data assets increases. The need by industry regulator or taxing jurisdiction can also increase the data that must be available for short- or long-term recovery.
Online availability: Customer's billing data (including unbilled transactions) may be made available to customers in real-time or after a short delay. This can necessitate timely initial processing with related system availability / redundancy.

Hardware (processing at scale)

Vendor selection: System infrastructure will change as the underlying hardware is updated over time to take advantage of performance improvements in server technologies, to ensure supportability from vendors, or to address the closure/replacement of vendors.
Parallel and concurrent processing: To achieve the necessary throughput, billing systems can utilise the fact that much of billing is 'embarrassingly parallel'. Servers and related software must address such changes, especially with the move to multi-core processors.
Redundancy: If systems must be available or throughput needs are important, then system redundancy will influence the billing systems' architecture and the additional processing put in place to support failures and recoveries. This will also influence whether the systems are ready at a moment's notice (hot) or must be brought up after a short delay (warm / cold).
Peak Load: When processing is performed synchronously (i.e. real-time), transaction intensities and volumes drive the quantity and types of hardware/software needed. Where average workloads can be used, an intense 8 hour workday can be averaged over a 24 hour period to reduce costs and/or hardware needs.
Upgradability: How will the system be upgraded as CPU technologies improve (speed, cores on a chip) and operating systems are upgraded? Since Moore's Law will continue to influence processing for many years to come, how will the hardware improvements be captured?

Tags: Scale, Dimensions, Billing, Data