Note 10: Customer, Account, Service, Product, and Hierarchy Data Concepts

Posted: 24 December 2005

Customer

You, the reader, are a customer, as is the company you work for. The customer data concept helps billing differentiate between you, your company and other similar customers. Details stored against each customer entry enable a specific customer to be identified. For an individual these details might include their full name, date of birth and drivers licence number. For a business entity these details might include the business' registered corporate name, registration jurisdiction, company officer(s) and business registration number.

The customer concept associates customers' details across the biller's entire operations. Data extracts from the biller's different applications (including billing) can be brought together in one location (e.g. a data warehouse) and associated using a customer identifier to form a consolidated 'customer' view. To ensure the customer identifier is allocated consistently, the 'customer' database is often treated as a database of record.

Identifying customers is important to billers as it enables them to permit or deny access to their network's activities. For example, a biller may record information against a customer to highlight historical bad debt or an existing poor payment history. When such a customer seeks to connect a new or expensive network service, the biller may ask that the bad debt be repaid or request a security deposit is taken before the service is established. When corporate customers declare bankruptcy, the courts can require the biller determine their total financial exposure to the (now) bankrupt customer if the biller is to get the maximum possible distribution. The (corporate) customer's identifier allows the information from multiple billing systems to be extracted separately and aggregated to form a consolidated total. The customer can then be flagged as 'bankrupt' limiting their future activities within the biller, with any 'related' corporate entities placed on a watch-list for tighter monitoring.

Account

An account is the point to which a customer's purchases and / or liabilities are aggregated before being billed. A customer may have only one account or request that their charges are aggregated and billed across multiple accounts. For example, a residential customer may choose to have separate billing for their family home and their holiday house. All charges for the family home are formed up and sent via one bill aggregated against one account, and similar processing is done for the holiday house's charges against a second account. A separate account might also divide the billing incurred by a 'home office' from the billing associated with domestic 'personal use'. For a corporate customer, accounts can represent offices, regions or any other sub-groupings that supports the customer's business operations and/or accounting.

The account is also the entity against which debt is stored. Whilst customers may be held accountable for payments, all financial transactions including bill debt, payments and other adjustments are processed at the account level. Credit management of outstanding debts can be performed at the account level, or all the debt across a customer's collective accounts can be aggregated and used to perform customer-level credit management.

Depending on the biller and their industry, the customer and account entities may be treated as equivalent. This approach is more likely where customers within a network commonly have only one account. For example, governments that levy rates / taxes on property may find that relatively few customers own more than one property within their jurisdiction, and hence the government may make little distinction between the customer and account concepts.

Service

The service concept represents customers' network access within the billing domain. Since each network uses a different approach to describe access and network consumption, this data concept differs the most amongst industries. Examples of services on different networks include electronic tags attached to vehicles (tollways), meter numbers (utilities), phone numbers (telecommunications), and property references (governments). Aside from generic data fields, the characteristics of each network will influence which additional network-specific data fields are required against each service.

Unique identifiers specify each network service so that the consumption at or access to each service can be monitored, measured and controlled. Some networks support sub-divided access to a network service with each sub-division qualified, possibly using a separate identifier. For example, electricity meters may use separate 'service' identifiers aligned with separate physical measurements performed for 'peak' and 'off-peak' power consumption, or fixed-line phone networks may separate voice call charges from those charges incurred by DSL broadband operated across the same copper 'twisted pair' network connection.

This differentiated measurement of the network service allows each 'sub-division' to be charged for differently in billing. The separate qualifications used to identify services' sub-divisions must be included in the data passed from the network to the billing process to support the charging of different rates (e.g. indicators of peak / off-peak).

Some network infrastructure (e.g. fixed phone lines) can support a (logical) division of their services to generate offerings (and their associated billing arrangements) with multiple billers. For example, a phone service may be provided by two businesses with one a long-distance phone provider and the other operated by a local phone provider. A phone call's destination will determine which network it is carried upon, and how it will be billed. Similarly, a residential fixed line voice service may be delivered by one provider, with a DSL internet service, using the same physical infrastructure, provided by a separate ISP business.

Separate (pre-paid) financial balances can also be stored against a customer's services. This is used in pre-paid billing where a customer tops up / recharges a service's pre-paid balance to control spending or budget expenses. For example, a parent might limit their monthly outlay on their children's pre-paid mobile phones by providing regular but fixed amounts. When their children's pre-paid balances are consumed, the children will be unable to use their phones until their parent's next (pre-) 'payment'. The children can fund expenditure in excess of their parent's minimum outlay by pre-paying with their own money.

Product

Products are what customers purchase from a biller. The product data concept must support a biller's entire suite of market offerings, with product complexity varying by industry. For example, the telecommunications industry generates complex product entities that can combine multiple network types into bundled offerings, charging different amounts for network access and usage. A government entity generating rate notices employs a limited, simpler product suite that changes only slowly.

The product concept captures all recurring, one-time and network usage charges that a customer may purchase or incur, including all miscellaneous non-network charges, credits and adjustments. Product definitions must also include details about which transactions / access features to charge for, and the methods and rates to be used when calculating the product offering's price. For example, a phone service's recurring access charge can be charged at different levels and bundled with phone calls - bundles can offer cheaper phone calls with a higher network access charge, or vice versa, with each arrangement generating a separate instance of a billable 'product'. The same network connection and phone calls will be billed for different amounts depending on which 'product' offering the customer has purchased from the biller.

Products need to be distributed throughout a biller's operational systems to ensure they can be ordered, activated in the network, have their problems fixed, and generate appropriate financial postings. This need provides a distribution and synchronisation challenge to ensure that all operational systems are using the same product view. For this reason, the product database is best treated as a 'database of record'.

Hierarchy

Hierarchies are a relationship structure that associate customers, their accounts and related services. Their use in billing enables:

Whole-of-customer views: A consolidated view of different parts of a customer's billing can assist a biller's staff as they address customers' inquiries and purchase requests. A billing hierarchy allows views below the 'customer' level to be created.
Bill presentation: For more complex (business) customers, billers can use hierarchies to provide 'value add' presentation grouping of services on the customer's bill. Different levels of the billing hierarchy can represent levels of the customer's business translated through to the customer's bill presentation. For example, a customer's services can be grouped together into 'offices', which are then grouped into 'regions', and then 'states', before aggregating to a grand total at the 'corporate' level. Value-add sub-totalling at each level allows customers to assess their spending quickly at different levels of their business.
Pricing plans: Rather than specify each service's pricing plan, the biller can use a billing hierarchy to attach a single pricing plan at a 'high' point in the hierarchy and 'inherit' its pricing influence down through to the customer's services lower in the hierarchy. This can ensure pricing is applied consistently, and avoids the maintenance difficulties of aligning pricing plans across a hierarchy of hundreds or thousands of services.

In billing, the benefits that a complex hierarchy delivers must be balanced against the complexity, maintenance and processing costs it generates. Residential billing may use a simple customer hierarchy structure to associate a customer's few services together under a single account. A large corporate hierarchy may include thousands of services grouped in a customer-specified arrangement of variable hierarchy depth. A wholesale customer may be billed for tens of thousands of services structured in a 'shallow' and very wide hierarchy.

In these examples, the residential customer has little with which to form a hierarchy, the corporate hierarchy can offset its maintenance costs against pricing and bill presentation benefits, and the wholesale hierarchy is kept simple to minimise maintenance costs in a low margin customer relationship.

Tags: Billing, Customer, Account, Service, Product, Hierarchy, Data