Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics

Copyright

© Copyright 2012, 2013 by Stephen Jones

All Rights Reserved.

This material may not be reproduced, displayed, modified or distributed without the express prior written permission of the copyright holder.

Published by www.purebill.com (through which Stephen Jones can be contacted).

Book Version: Final (1.0 - September 2013)

ISBN:

978-0-9874350-0-2! (PDF) 978-0-9874350-1-9! (epub) 978-0-9874350-2-6! (mobi)

Billing for Business Networks ________________________________________________________________________

________________________________________________________________________ www.purebill.com - Final

http://www.purebill.com




Dedication

To my son Xander, who changed my life for the better





Table of ContentsChapter 1: What is Billing?! 10

Billing as a primary ‘Customer Contact’ point! 10

Billing Systems that are ‘Fit for Purpose’! 11

The Billing Process! 12

What is a Network ?! 13

Non-network Commercial Situations! 15

Chapter 2: Billing Within The Business ! 16

Ordering! 17

Provisioning! 18

Service Assurance! 19

Data Analysis! 20

Why Multiple Billing Platforms Are Used! 21

Chapter 3: The Key Functions of Billing! 26

Activation / Service Provisioning! 27

Transaction Collection / Mediation! 27

Transaction-level pricing (Rating)! 28

Bill Generation / Bill-level Pricing! 29

Bill Presentation / Distribution! 30

Downstream Reporting / Business Support! 30

Account Maintenance / Inquiries! 31

Chapter 4: The Core Data Concepts Of Billing! 33

Customer! 34

Account! 35





Service! 35

Product! 36

Hierarchy! 37

Chapter 5: Common Network Businesses ! 40

Utility Billing! 40

Tollway Billing! 41

Telecommunication Networks! 43

Government Rates / Taxes! 44

The Wholesale Model! 45

Chapter 6: Charge Types ! 47

Non-Recurring Charges! 48

Charges Billed By Installment! 48

Recurring Charges! 50

Charging for Network Usage / Consumption! 52

Common Billing Processing Protocols! 53

Chapter 7: Individual Charges ! 58

Differentiating Charges! 58

Moderating Pricing Complexity! 60

Recurring and Non-Recurring Charges! 61

Usage! 62

Building Charges From Their Parts! 63

Chapter 8: Bundled Charges! 65

What is a Bundle?! 65

Why Bundle Products?! 65

Constructing a Product Bundle! 67





Chapter 9: Contracts ! 70

Commitments Over Time! 70

Contract Examples! 71

Chapter 10: Service Provisioning / Activation! 74

Customer Orders! 74

Order Management! 75

Operational Structures for Billing! 76

Bundle Provisioning! 79

Automatic Network Activation! 81

Provisioning Latency! 82

Chapter 11: Transaction Collection / Mediation! 85

Historical Comparison: Fixed phone versus Utility! 85

Network Collection! 87

Collection: Operational Considerations! 89

Error Management! 90

Data Mediation! 91

Chapter 12: Transaction-level Pricing (Rating)! 96

How Much Does A Charge Cost?! 96

The Key Steps of Rating! 98

What are Rate Plans?! 102

Rating Algorithms! 105

Additional Rating Mechanisms! 111

Rating’s Operational Workload! 119

Chapter 13: Bill Generation / Bill-level Pricing! 122

Bill Generation! 122





Triggering the Billing Cycle! 124

Customer Details Extracted For Billing! 128

Bill-level Pricing! 133

Bill Format Options! 139

Bill Validation! 144

Chapter 14: Bill Distribution! 148

Distribution Channels! 148

Notification Channels! 152

Bills and Other Documents! 153

Distribution Operations! 154

Chapter 15: Customer Inquiry / Maintenance! 156

Customer Identification! 156

Wholesale Customers: Inquiries and Maintenance! 158

Contact Channels! 160

Maintenance Lifecycle! 165

Capturing Customer Details! 166

Chapter 16: Reporting / Business Support! 170

Auditing Reports! 170

Exception Reports! 171

Adhoc Reports! 172

Size, Timeliness, Distribution and Access! 173

Chapter 17: Customer! 177

What is a Customer?! 177

Customer Lifecycle! 178

Consolidating ‘Customer’ Databases! 180





Chapter 18: Accounts! 183

Account Lifecycle! 183

Structural Combinations! 184

Account Complexity by Customer Segment! 185

Account Information! 186

Financial Totals! 188

Chapter 19: Service ! 189

Network Services! 189

Non-Network Services! 190

Derived Services! 191

Service Segmentation! 192

Chapter 20: Product! 194

What is a Product?! 194

Building Up A Product Offering! 194

Product Catalogs! 197

Chapter 21: Hierarchy ! 200

What is a Billing Hierarchy?! 200

Benefits of Billing Hierarchies (at Scale)! 200

Hierarchy Complexity! 202

Chapter 22: Other Important Data Concepts ! 204

Bill Details! 204

Post Bill Disputes! 205

Billing Notes and Contact History! 206

Taxation Details! 207

Addresses! 208





Chapter 23: Aspects of Pricing! 210

Pricing Complexity! 210

Bundled Pricing! 215

Differential Pricing! 216

Chapter 24: Disputed Charges ! 220

The Dispute Lifecycle! 220

Operational Support! 227

Disputes: An Example of ‘Case Management’! 230

Chapter 25: Payments! 231

Forms of Payment (Payment Channels)! 231

Timeliness! 234

Chapter 26: Settlements! 236

Methods of Settlement Payments! 237

Chapter 27: Revenue Assurance! 239

What is Revenue Assurance (RA) ?! 239

Documentation and Data Discovery! 241

Iterative Testing! 242

About the Author! 244

About the Book! 245





Chapter 1: What is Billing?Looking through a pile of bills will reveal that more than one is from a network business. Many of the services we purchase are based on access to, and use of, networks that either provide the necessities of a comfortable environment (e.g. electricity and water) or allow us to communicate with others (e.g. telephone and internet).

Depending on where you live these network businesses may be publicly held corporations run for profit or arms of government providing services to residents - either way, the basics of the process by which you are billed is very similar.

Billing for Business Networks explores a network’s billing process by separating the act of billing from the multifaceted operations of that network. Networks are usually large complex creatures that are difficult to develop, and require considerable money, staff and ongoing focused effort to maintain. They can be limited to a specific locality or provided on a country-wide or international basis. In contrast, billing is usually provided in a centralised manner and is based upon what has been done upon the network (of whatever size or type). By separating the complexities of the ‘physical’ network and the billing for that network, the billing process can be understood.

This is not to say that all billing is the same or equivalent. Billing for a telecommunications company is considerably more difficult than the billing for basic water consumption. The telecommunications industry seems to delight in building highly complex networks and then reflecting them in its billing systems. The water and electricity industries have not (yet) developed this level of complexity, but this may happen in the future with the increasing focus on reducing water and energy consumption.

Billing for Business Networks will explain the billing process using examples familiar (or at least understandable) to most people based on the bills they receive in their everyday lives. Examples describe how telecommunications billing can be generalised from its complexity and explain how simple billing for water and electricity can be made customer specific (and more complex).

The similarities in the billing process across different industries are illustrated using examples taken from telecommunications, road tollways, utilities (gas, electricity, water), and local government (rates and garbage collection). Billing for Business Networks is not intended to be technology or industry specific, nor based around a specific billing vendor. Instead it is designed to enable readers to use what they will learn to evaluate and understand their own business’s systems, or those of a candidate billing vendor.

Billing as a primary ‘Customer Contact’ point

In today’s business environment with its focus on cost-effective customer contacts, there is a movement away from person-to-person communication and towards arms-length electronic processing. This means that there are fewer customer touchpoints aside from





when (say) a new service is connected for a telecommunications company, the utilities are connected when moving into a new house, or there is a problem with the biller’s services. This reduction of ‘customer contact’ between the network biller and its customers puts pressure on the primary point of contact - the bill.

Naturally this reduction is most applicable in the consumer mass market where customers number in the thousands or millions. Corporate customers are generally managed with a closer relationship since their needs are usually more complex, and their bills are generally worth more!

Thus, the bill a customer receives needs to perform many functions. These can include clearly articulating how the amount payable was arrived at (a core requirement not always achieved), highlighting details of future billing changes (e.g. price rises or specials), possibly marketing new offers to customers and, most importantly, informing them as to how they can pay their bill.

If the bill performs these services well, the customer is more likely to be positive about the biller’s network and its services and feel less need to call the biller’s customer service staff with questions, complaints or disputes (or change service providers). Importantly, the bill is more likely to be paid promptly.

Billing Systems that are ‘Fit for Purpose’

Billing for Business Networks highlights the billing similarities between different networks. Not all billers require the same sophistication to operate their business. Billers require systems that both meet present requirements, and are adaptable to future (perhaps unknown) needs. Some of the questions billers may ask themselves when thinking about their billing systems’ ‘fitness’ can include:

What is the complexity of my billing needs? If a business is primarily based on monthly recurring charges, its billing needs are less complex than those of a business having high-volume daily transactions with tailored rates for different customer segments.

What is the cost of the billing systems? Cost includes the purchase price of new systems, and the operational costs of existing and possible new environments. The system, business and human costs of any transition from an old to a new environment must be taken into account. Depending on the required complexity, the cost of a network operator’s billing can be material to its ‘cost of doing business’.

What is the cost of modifying the billing system? New features and transaction sets are often developed to enhance the biller’s market offerings. What are the system development or configuration costs required to deploy new transactions and interfaces?

How does the billing systems process information? This involves the speed and latency with which events and business updates are reflected into and through the billing systems. This processing speed impacts the functionality provided to a customer, and the speed with which network access and events can be converted into money.





How quickly can bills be modified to reflect new market offerings? A biller needs to be able to develop and bring new offerings to market quickly (lead time) and to anticipate or address a competitor’s offerings (responsiveness). Their bills must reflect these changes.

Are the billing systems transparent? Billing is not performed in isolation. The biller’s management and outside parties (e.g. regulators) often require access to billing information in a timely manner. Is the required information available in the required format within the required timeframe?

These questions highlight the many different and inter-related tradeoffs in billing between ‘complexity’ (with its benefits of adaptability), and the ‘cost’ of providing and supporting that complexity. The billing solution a biller selects must align with the functions to be performed today, provide suitable adaptability for the future (as the biller’s vision sees it) and operate within the biller’s available funding envelope (for development and ongoing support).

Transaction and customer volumes are a factor here, since increased size generates more complex product combinations, system scaling issues and exaggerates the impact of any billing problem or defect.

Once a biller has chosen a set of tradeoffs, they can move them over time as their network, operating environment and competitors (if any) change around them. Yesterday’s solutions may be inadequate today and obsolete tomorrow. But decisions must be made, and wise decisions will confer a competitive advantage, or at least lowered costs to a network.

The Billing Process

Once the network business has defined who its customers are, the services it is willing to provide to those customers, it needs systems to charge those same customers for the services rendered. The collection of the resulting charges and subsequent request for payment is what billing is all about.

Viewed as an end-to-end process, billing:

- Captures the billable events, i.e. the details of access and services provided- Calculates specific charges against the billable events- Aggregates the charges for a ‘customer’- Deducts charges against a pre-paid balance, or asks for payment- Determines the ongoing entitlement to network access

Captures billable events This is the touchpoint between the network and the billing process. The richness, timeliness and accuracy of the data captured here drives the subsequent billing processes. Billable events can include charges for access as well as for the actual consumption or use of the biller’s network.





Calculates specific charges Once the billable events have been captured, a financial value must be placed against them. The precise value can depend on the customer’s details (e.g. business, residential), special features of the event (e.g. a ‘reverse charge’ phone call), captured event details (e.g. call duration, call destination, quantity of electricity, gigabytes downloaded) - in short, all the information available about the specific customer, her demographic segment’s characteristics, and any special and standard pricing arrangements.

Aggregates the charges After charges have been given a financial value, they are periodically collected and formed into a bill. The bill may allow discounts on aggregate totals and taxes applicable to the nett charge. If charges are prepaid, the customer’s balance may be reduced by the charge’s total.

Seeks payment The (post-paid) bill, representing the consolidated, discounted and taxed charges, is sent to the customer for payment using the biller’s approved methods.

Determines the ongoing entitlement to network access A prepaid customer may have her access to the network terminated when the prepaid balance is consumed or her balance may be recharged via (say) a credit card to enable continuing access. For postpaid customers, if the requested payment is not made, ongoing access may be denied or financial penalties applied.

What is a Network ?

The establishment and maintenance of a network’s billing system can best be understood by first reviewing characteristics typically found in networks.

A ‘network’ typically has the following characteristics:

- A specific infrastructure or a finite geography across which the network business is conducted- The ability to permit or refuse access or service to customers based on pre-payment or a promise to pay- The ability to measure a customer’s access or consumption if required- An ongoing relationship across time with its customers- A charge is made for use of the network

Specific Infrastructure or Geography A network has a finite, though possibly large, boundary within which its business takes place. Examples include the national phone network, pipes of a water distribution network, roadway associated with a tollway, and the geographic limits of a city that levies rates for local government services and waste collection.

Permit or refuse access or service A threshold associated with ‘signing up’ to access or use the network is placed upon the customer. This can be quite low, as in the case of a prepaid calling card, or substantial, such as a requirement that the customer pass a credit





check. By signing up, the customer’s details becomes known to the business and access can be granted to the network. Even in the case of a pre-paid calling card, despite the customer remaining anonymous (whilst making phone calls), there is still some measure of ‘enabling’ the card before commencing its use.

Measure a customer’s access or consumption Complementing ‘permission of access’, measurement allows the network business to provide a specific quantity of access or service, or if not limited, measure the amount consumed and later bill for it. Examples include tollway journeys billed later or a preset number of domestic phone call minutes on a calling-card. Alternatively, a customer who purchases an all-day tollway pass is billed based on a measured period of access (time) rather than the quantity of journeys made (use).

An ongoing relationship Access and use of a network are associated to the same customer across a measure of time and can be ‘billed’ or ‘charged for’ collectively. Examples include calls deducted from a single (even if anonymous) calling card balance, and international calls collected and charged to a home phone bill.

A charge is made for use The charge drives the need for billing, but does not necessarily mean that a paper bill needs to be generated. Indeed, there is a definite trend away from paper-based billing towards online (internet) based presentation of the bill’s details.

The degree and manner to which each characteristic is employed in a particular network will be specific to each individual business, will be industry specific and will be influenced by the regulatory framework within which it operates.

For example, tollways usually cannot refuse access to specific vehicles (absent weight, etc. restrictions). However, the owner of a vehicle that uses a tollway without payment may be subject to fines and penalties.

Two additional points about network characteristics are worth noting:

Ownership of the network assets A network business need not own the network assets it uses. It can rent the assets of another business at one rate and on-sell to end users at a higher rate. For example in the telecommunication industry, the wires into the home are rented from the local incumbent, or in the power industry electricity may be purchased wholesale from a generation business, carried over the wires of a transmission business, and sold at retail into the home. In each of these cases the retail relationship with the end customer is separate from the ownership of the end-to-end network assets.

Networks need not be physical An example of a network asset that is not physical (in the sense of being able to touch it) is an electromagnetic spectrum (e.g. radio frequency). Access to a wireless network for phone or other services can be supplied by the spectrum owner in the same manner as access to a home’s phone line can be rented from an incumbent telecommunications company.





Non-network Commercial Situations

Not all commercial transactions need a sophisticated billing system. Some examples are:

Retail shops Here the purchased goods are totaled at the register and immediate payment is requested. There are usually few options to decline service, often the customer remains ‘anonymous’ and there is little or no ongoing relationship with the customers once they have left the shop.

A ‘billing’ requirement could be generated for shops where (say) there was a specialised ‘trade’ component to their sales. Examples include interior decoration shops with a professional decorator clientele alongside their retail sales, or a large plumbing store that sold products to professional plumbers as well as the weekend DIY population. In these cases the shops could perform anonymous retail sales, and ask for monthly payment of their ‘trade’ accounts based on special ‘trade’ pricing, with an expectation that non-payment would force these professionals to pay the same rates as the public.

Cash transport tickets Tickets are obtained from a station, retail shop or vending machine and used for anything from a single trip to (say) a week’s travel. There is little ongoing customer relationship, no differentiated charging and usually no scope to decline access. This, despite the transport being performed over a rail or bus network.

Transport tickets could generate a ‘billing’ requirement if a customer had an ongoing relationship via a ‘transport-pass’. The pass could allow details of the travel performed to be collected for later billing or deduction from a customer’s specific pre-paid balance. There could be bonus rebates / credits based on the traveler’s use of the transport network over time.

Tollways that only take cash payments Many tollways charge for their use only by collecting cash from their customers. Customers pay for each use of the tollway.

Some tollways use billing to great effect, by using electronic tags to capture details of trips taken. These trip details are then passed to the tollway’s billing systems.





Chapter 2: Billing Within The BusinessBusiness functions normally view their own activities as central to the entire business. While this viewpoint is always exaggerated, business functions are interdependent, and often, the failure of any one function can cripple an otherwise sound business. This is certainly true for billing, which interacts with nearly every business function. Yet, billing can do more than collect cash. Properly structured, it can provide support to forecasting, marketing, and sales efforts. Thus, it is entirely appropriate to treat billing as a central business function, the approach taken here.

Operationally, billing businesses are complex combinations of staff and information technology. In this book, business and billing ‘functions’ will describe ‘what’ is performed, ‘systems’ will be the collective combination of the manual and automated processes that support ‘how’ functions are performed, and ‘applications’ will be specific deployments of information technology.

An application may participate in one or more functions, be part of one or more processes, and can range in size from a large, comprehensive software package to a small, specific processing step. A business process supports one function and may utilise one or more applications as well as including manual steps. This book is a general discussion that includes talk of functions and systems, and discusses applications when the specifics of how to perform a task are important.

The functional landscape around billing

No two business networks are identical. Thus, the implementation of no two billing systems will be the same. This holds true even within a given industry where, the choices made by individual businesses will result in different billing arrangements.

Business functions (outlined in more detail below) that interact with billing include:

- Ordering: Captures the details of a customer’s purchase- Provisioning: Implements the customer’s order in the network and/or billing- Service Assurance: Network monitoring and problem resolution to ensure maximum service availability and customer satisfaction- Data analysis: An internally focused business examination of customer data- Fraud Detection: Identifying suspicious or fraudulent activities taking place upon the network- Marketing Support: Supporting the search for sales opportunities from new and existing customers- Other billing systems: Where multiple billing systems exists within a business, each billing system is likely to interact with the others to share customer, reference or transaction information.





Billers can use separate or consolidated applications to interact with each of these functions. Provisioning and service assurance, the functions that form the touchpoints between the IT infrastructure and the network infrastructure, will encounter the greatest variation in their processing. Each industry’s network will require different processes to support these functions, and the required applications will vary as a result.

Ordering

Each customer’s purchase is captured by an order. An order is the customer’s response to a biller’s offerings, and refines them to a specific sub-set for that customer with specific details (and potentially customised pricing).

The customer’s order can take several forms: by phone with the biller’s staff, by regular mail using a paper purchase order, electronically through the use of an agreed B2B interface, or perhaps executed by the customer themselves via an internet-based self-service portal. Orders can be generated internally by the biller (e.g. in credit management - disconnection of the customer for an unpaid invoice, by service assurance - credit rebates when the biller does not maintain contracted service levels).

Each order is unique and must be differentiated from similar orders from the same customer for the same products. Similar orders must have unique identifiers reflecting the different phone numbers, meter or internet connections against which they are to be applied. In subsequent processing, one of the order’s key validations is to confirm that the same order has not already been processed. Thus, it is essential that each order have, or be assigned, at the outset, a unique order number.

Orders may be simple and standardised, or exceedingly complex, customised requests. An order’s complexity is limited only by the ordering system’s ability to capture its details, and the biller’s other systems’ ability to process them. The likely complexity of an order will vary depending on the complexity of the network receiving the order. An order for a new tollway transponder is likely to be simpler than an order for modifications to an international telecommunications link.

Complex orders can take several days to define, and may require the biller to have or acquire detailed information on a customer’s preferences, specialised knowledge of the biller’s network, and service identifiers (e.g. phone or meter numbers) to ensure the billing and network arrangements are applied correctly.

To ensure that a biller can fill a customer’s order, new network connections may need to be pre-tested (qualified). This pre-testing may involve evaluation of the order’s details against a customer’s existing product sets and the network itself. For example, evaluation tests may include product eligibility based on the customer’s market segment, availability of network equipment at the customer’s location, and technical compatibility (sociability) between the intended and existing network configurations.

When a customer orders a new product or service, or modifies an existing one, she has an expectation that its bill details will align with what it ordered. The price, description and





date range of services provided must not vary, without an explanation, from what the customer ordered. Hidden from view, the network response supporting the customer’s order may be implemented in a variety of ways, but it must achieve the desired external effect. Absent such alignment the biller will, at a minimum, incur additional costs through responding to the customer’s inquiries and complaints. Optimally, the biller provides what was ordered without requiring the customer to understand how it was delivered.

Once an order’s details have been captured and validated, it is sent onward (as appropriate) to the network for provisioning, and then on to billing. An order that varies only a customer’s billing arrangements (e.g. billing address, pricing plan) is unlikely to require processing by the network. Any network change, however, should be passed to billing since it may change a customer’s billing arrangements or the basis upon which it is charged. e.g. a change in the speed of a communications line, or configuring ‘call waiting’ on a phone line.

A specialised form of ordering is referred to as churn. It is the process whereby a customer can move (often in an automated way) between retail network providers whilst retaining their existing service details. e.g. a customer may change phone providers and retain her existing phone number or change electricity retailers whilst remaining connected to and continuing to use the same meter.

Provisioning

Provisioning describes the range of network interfacing actions that add new network connections (e.g. connect a new phone), modify an existing network connection (e.g. change the allowed programs in a subscriber’s premium cable TV package), and disconnect connections (e.g. change a meter’s status as part of its final meter reading).

This function isolates the network’s intricacies from the central business functions and their IT applications. The specific technical details required for configuring, reading and otherwise communicating with a network can be effected within the provisioning function. This function is especially important where the network is a heterogeneous collection of vendors and equipment, and each has its own approach to performing common tasks. Ideally, provisioning interactions within a network are highly automated. This is especially important when network connections are numbered in the millions.

Complex orders, especially for high-end telecommunications, may require an expert design step that reserves equipment, implements and then tests the proposed solution. Standard, simple orders using existing infrastructure (e.g. water or phone connections) are unlikely to require a design step unless the customer’s premises had not previously been connected to the network (e.g. new housing) necessitating manual intervention. Otherwise the existing equipment would be (re)configured to reflect the order.

Complex installations or network modification may require ‘time and materials’ charges be applied. These charges, on an original or a subsequent order, are directed to billing for subsequent inclusion on the customer’s invoice. They may be reflected in the initial invoice, or held for inclusion on a subsequent invoice.





Order validation should be performed before processing to ensure that the network is not impacted by inappropriate requests. Validation will cause some orders to error and manual intervention will be required. Errored orders may be rejected outright, or modified to correct the problem and resubmitted.

Contractual or regulatory provisions may require orders to be filled within a certain time period (i.e. service level agreements (SLA)). To meet these requirements, the provisioning process should be actively monitored (jeopardy management) to identify those orders in danger of breaching their mandated service levels. Automated or human judgment can then be applied on whether they should have their priority raised to meet their SLAs.

Where shared infrastructure is used for different retail providers, churn may require provisioning alter network settings. The network settings can indicate which retail provider currently ‘owns’ the retail relationship, or provide data security to prevent unauthorised access to the network settings by a competing retail provider’s staff.

Service Assurance

Service assurance, like provisioning, is a network interfacing function. When network-related problems are identified, assurance sees that they are managed until fixed. Assurance should also include the proactive identification of otherwise unreported problems and their management on to resolution.

When problems occur, the biller’s staff capture the problem details provided by the customer. Problems are logged and prioritised based on the staff available and the expertise required. Once allocated to staff, a problem’s cause is identified and the appropriate fix applied. Some problems can be fixed remotely, whilst others may require the dispatch of network staff to the customer’s location.

Any shared use of network staff between provisioning and assurance requires that the competing priorities of new orders and network problems be carefully managed (work force management). The different skill levels between staff, and dedicated teams for specific tasks (e.g. new connections) can cause complications. New connections can be relatively standard; problem resolution usually requires more experienced staff. More complex network technologies (e.g. telecommunications) may require a detailed understanding of a range of technology platforms.

Different industries (based on their networks) will require different levels of assurance activities. Billing of government charges based on a residential address’s details may have assurance issues concerning the postal address for documents, who owns a property and its current value. These can be addressed from a central office location during business hours. Water networks will require registered plumbers with access to underground pipe information, equipment to replace faulty pipes, and details of where to turn the water off. These details must be available to a large, distributed workforce operating 24 hours a day from trucks and vans.





When multiple problems occur, assurance must identify whether there is a common cause. The identification of a common cause can sometimes reduce the overall resolution effort by targeting the underlying fault rather than each individual problem. However in other cases, each individual problem may still need to be tested and closed. Identifying an underlying fault can also identify the broader scope of an outage / issue and allow the identification of unreported impacts. Proactive resolution and notification can then provide a higher level of customer service.

Even more than ordering, assurance uses service level monitoring to identify when outstanding problems are in jeopardy of breaching service level agreements. The time allowed to resolve problems will normally be included in commercial contracts, or, in non-commercial circumstances, by minimum regulatory standards.

A premier level of ‘service restoration’ may be offered to customers as a ‘value-add’ product. Alternatively, essential service providers (e.g. hospital, doctor’s surgery or police station), or emergency situations may require a premier service. Additional information on such situations can be retrieved from the billing system so that it can influence the priority with which a specific problem is addressed.

When service levels are breached, rebates and contractual credits may apply. When a problem is a customer’s fault there may be ‘time and materials’ charges applied to recover the biller’s costs. These internally generated, non-network charges are forwarded to billing for inclusion on the customer’s bill.

Data Analysis

Data analysis combines data from different sources, validates its accuracy, transforms its format to one suitable for high-performance analysis processing (rather than transaction processing), and assembles it ready for use. For billers, data analysis can provide insights into customer, transaction and network information that are not easily obtained using regular database queries.

For example, data warehouses can consolidate information from across the biller’s systems to enable integrated dissection of the biller’s data. Queries can be performed by business staff to identify new sales opportunities, regional performance differences, clarify the effectiveness of different marketing campaigns and track long-term purchasing trends.

By analysing behaviour over a sufficiently long time period and for a large customer sample, a biller can construct predictive models of customers’ propensity to perform future activities. Examples include the customers’ likelihood to purchase (e.g. useful for sales and marketing), or change providers at the end of their contract period (i.e. churn). It can also be one of the data sources used in fraud detection.

Fraud Detection Fraud detection analyses data to identify fraudulent or suspicious behaviour. The specific methods used to perform this analysis are often restricted to a select group to ensure the ‘alarm’s tripwires’ remain hidden. Suspicious activity may or may not be criminal. A customer’s change of behaviour may be based on a change of





circumstances, and, just like a credit card company confirming an unusual purchase, once investigated can be dismissed from further consideration. The customer’s new circumstances may present sales opportunities that can be passed to other business functions.

For high-value transactions, fraud detection may need to be performed in near real-time in order to limit the biller’s financial exposure. Lower value transactions may be analysed after a brief delay using cheaper infrastructure than required for near real-time checking.

Marketing Support Billing can be an information source used to support the biller’s marketing initiatives. Billing’s core databases can include information such as contact details, market segmentation information, and details of recent purchases. Billing’s accurate information is important where regulator-mandated codes-of-conduct limit the frequency with which a customer can be contacted. Candidate targets for marketing campaigns may be identified by the data analysis function.

Why Multiple Billing Platforms Are Used

A network business may have multiple billing instances because of strategic policy decisions, corporate mergers, and/or separately conceived product or service development. Complex billing environments can use different billing platforms to support solutions and cost structures for different market segments. The causes of multiple billing instances include:

Time pressures New products or services introduced quickly are given a separate (new) billing instance where the use of an existing billing platform would delay introduction or subsequent modifications.

Product Maturity Mature products are likely to have stable billing requirements that can use a less sophisticated billing platform whilst new products and services may undergo frequent marketing changes and so will need a billing platform that can be changed quickly and easily.

Market segmentation Different market segments may need to be billed on separate billing platforms in order to support their different configurations and independent development needs. e.g. wholesale / retail, residential / small business / corporate

Product segmentation A business with different networks may have silo billing systems aligned with each network. e.g. internet / fixed phone / mobile phone, gas / electricity

Geography A business operating in different regions may operate regional billing instances. Foreign currency processing may also require separate billing.

Capacity The same billing platform may need to be replicated because of performance or size limitations.





Business Continuity The same billing platform may be replicated to maintain business continuity. This can be done by operating multiple live systems, or by having a ‘mirror’ site that can be brought online if required. Operating redundant systems can be expensive, but may be less expensive than the lack of a business continuity plan.

Regulation Regulators may require that product or market segments use separate billing systems.

Transition This can occur where an older billing system is migrating into a newer system, or several billing systems are being consolidated into one.

Capability Specific billing systems (or sub-systems) may be tuned or designed to operate for a limited function set. For example, such systems might be employed for real-time transaction pricing, high-volume batch rating, or pre-paid balance management.

Role Rather than having one billing system do everything, different billing systems may be tasked with different scope responsibilities. This approach can allow a biller to provide customised solutions for their hardware, software and service level agreements. e.g. content settlement, interconnect billing and reconciliation, retail billing.

Security Regulatory or marketing considerations may require a biller to provide separate billing repositories enabling data environments to be demonstrably ‘secure’ by being physically rather than logically isolated within the one database.

Buy versus Build Historically, many billing system were developed in-house, but may be replaced in the future by vendor software packages. A biller may choose to deploy a software package for new products whilst retaining its in-house billing system for existing products.

The most effective number of billing instances will, of course, vary from biller to biller, and depend on the biller’s historical position, available opportunities, and goals. The best billing solution will proceed from a clear statement of a biller’s strategic direction, rather than simply be a result of historical decisions.

From an operational point of view, it is essential to ensure that the chosen solution can do the jobs required of it. A reduction of billing instances based solely on financial considerations or an arbitrarily determined environment number can limit a biller’s ability to respond to market changes if the jobs that need doing can’t be supported. For complex networks, it is likely that several billing instances will be required, particularly where there are competing business priorities.

Nevertheless, multiple billing instances pose risks and issues that need to be addressed, such as:

Potentially increased costs Multiple billing environments can generate some dis-economies of scale with each environment requiring its own suite of staff, hardware,





software, and license fees. When separate instances operate the same software and/or hardware (operating environment), some costs can be reduced by resource sharing or negotiated volume discounts.

Staffing contention Separate billing environments with a development program reflecting new business initiatives may be limited in their ability to share their staffing expertise. Busy staff working at capacity may have limited scope to leverage their skills across other billing platforms. Separate, vendor-specific development teams operating at capacity may moderate cost arguments associated with separately staffed billing systems (since the same number of staff are busy doing the same volume of work).

Where billing platforms are provided by different software vendors, staff may be able to leverage functional knowledge but not vendor-specific implementation experiences. Billers with a wholesale division may be required by regulators to provide some separation between their wholesale and retail billing staff.

Internal environmental complexity Billing changes can require a more careful design when many separate applications are impacted. Whilst some initiatives may be specific to a market segment, corporate-wide initiatives may need to be developed and separately applied to each billing environment.

External environmental complexity External applications interfacing with billing must handle multiple billing systems to perform their job. e.g. corporate GL receiving feeds from different billing systems.

Speed of Change Where multiple systems must be updated to implement a change, the deployment rate may be reduced due to the coordination overhead. This can be moderated where changes are limited to one billing environment’s market segment.

Functional limitations Locating a customer’s products on many billing systems can restrict the billing options that a customer can be provided. e.g. when multiple systems are involved the biller may be unable to discount across the products’ billing silos.

Vendor Choice

The most complex networks generally have multiple billing systems provided, at least in part, by outside vendors. Billing systems from multiple vendors can reduce a biller’s business risk by avoiding a software monoculture, by providing competitive vendor choice, and by reducing the business impact of a defective system. Smaller networks or government agencies may be able to address their needs with a single system, often developed in-house.

A software monoculture generates business risk if the outside vendor is unable to meet the biller’s subsequent development needs. Without development alternatives, a biller’s ability to respond to market or regulatory change is dependent on the efforts of a single outside vendor, which may go out of business, or be acquired, leaving the purchased software unsupported. The use of (software) code escrow will only limit damage here.





Where a biller uses several vendors, competitive pressures are likely to produce better platforms at a lower cost. If different vendors construct the several billing platforms of a network, there will be integration issues. However, careful management can normally resolve these issues.

If a network’s single billing environment fails, the biller’s cash needs will be dependent on service restoration. With multiple billing environments, part of the biller’s network can continue to operate. Where multiple billing environments use different vendors, cross system comparisons over time can provide supporting data for the biller’s future platform choices.

There is no ‘correct’ solution for all billing situations. Each network must find its own balance of marketing, regulatory, performance, staffing, and financial requirements to achieve the best possible outcome. Practical considerations may place limitations on what is possible. Any future solution’s starting point will be the biller’s present systems, and this may limit what can be cost effectively achieved. As well, historical technical (e.g. preferred vendor), political (e.g. management political capital) and strategic business choices (e.g. billing consolidation) may be too entrenched to support some recommended ‘green field’ solutions.

‘Billing’ As A Marketable Offering

Once a network biller develops billing expertise it can offer to provide managed billing services to third parties. These services can be offered on a wholesale or retail basis.

A network biller offering its billing services on a wholesale basis (‘billing on behalf of...’) does so as a ‘value-added’ service (for a charge) avoiding the need for wholesale purchasers to develop their own capabilities. These purchasers are then free to focus on their own marketing and customer-facing tasks. Typically, the scope of the billing provided would be limited to the network biller’s products that the purchaser is reselling, but a more sophisticated wholesale purchaser may require that third party products also be included.

Billing can be a business’s core product offering. Such a ‘billing bureau’ processes and bills for the products and services of other parties, and provides an alternative to purchasing billing on a wholesale basis from a network provider.

Modern billing platforms can operate logically separate billing instances within one software and hardware platform without the need to deploy several physically separate billing systems. This approach allows the biller’s existing infrastructure to be leveraged (reused) without the need to deploy separate billing instances for each sale of ‘billing’ to a new customer.

Convergence

Traditionally, the billing function was performed by specialised, smaller applications that each delivered part of the billing solution, but with limited additional functionality. As





information technology has matured, software vendors have consolidated functionality and capabilities into their core software packages so that now fewer applications need to be deployed to achieve a more capable result.

Modern billing software can perform more of the end-to-end billing tasks (functional scope), operate across a biller’s more diverse market offerings (product scope), and process the larger and more complex billing required by today’s billers (performance). A biller can choose to operate multiple environments based on strategic criteria (e.g. by customer segment), rather than be forced into that situation to achieve sufficient coverage of their business requirements.

Billing is converging from many directions including:

Payment methods One platform offering pre-paid and post-paid billing for the same products using the same infrastructure. The same billing options can be offered consistently across the biller’s entire customer base. However the network requirement to terminate pre-paid access when the pre-paid balance is exhausted still remains.

Consolidated (single) invoice Historically, a customer received separate invoices for each product suite (e.g. fixed phone, mobile phone, internet). Billing platforms now provide the ability to consolidate all this information onto one customer invoice supporting a biller’s cost reduction and customer service goals.

Credit management The use of a single whole-of-customer debt balance, rather than multiple debt balances by product silo, supports consolidated credit management processing. The biller can use this better view of the customer’s debt and payment history to reduce their bad debt risk by identifying non-payment across all of a customer’s services, and supports the full disconnection of a customer for non-payment rather than isolated services.

Real-time versus batch This supports the biller’s ability to market the same rating and pricing plans across their entire product suite. Customers can be offered the same marketing message regardless of the underlying technology.

Cross product pricing Using one billing system that contains all of a customer’s product information enables pricing across products to be performed. Marketing can use this to support sales of new or less popular products, or use bundles to attract and retain more of a customer’s expenditure.





Chapter 3: The Key Functions of BillingFive Core Functions

Billing’s core functions activate the network for a customer, collect details of network transactions, determine the appropriate chargeable amounts, apply applicable discounts, format the bill, and send the bill to the customer. There are also supporting functions that transmit the billing details to the biller’s internal and external systems, and provide access and maintenance of customer details for resolution of customer issues.

These core functions also provide the raw data for secondary, though still important, billing functions. For example, a bill must have been generated and remain unpaid before credit management can act. Without the core billing processes that form and distribute the bill, there is no record of a debt to pursue. Of course, the credit management function is not involved in generating the bill. This chapter is intended to provide an initial context for those readers with little or no work history in billing.

Activation / Service Provisioning Interacts with the network to enable new customers, and modify details for existing customers. (Chapter 10)

Transaction Collection / Mediation Collects and standardised details of customers’s network activity. (Chapter 11)

Transaction-level pricing (Rating) Individually prices both network and non-network charges. (Chapter 12)

Bill Generation / Bill-level pricing Periodically collates a customer’s charges and prepares a bill, applying discounts based on the customer’s collective transaction volume, value or other criteria. (Chapter 13)

Bill Presentation / Distribution Prepares the raw bill information into customer friendly formats that can be sent on paper, viewed across the internet, or sent via file. (Chapter 14)

Two Supporting Functions

These two functions enable other parties, both internal and external, to access details of the billing process and the customer’s billing arrangements. The account maintenance function is an online, interactive function that enables staff (and possibly customers) to inquire and update details of individual customers and transactions. The reporting / business support function uses consolidated, batch interfaces to supply details for all customers.

Downstream Reporting / Business Support Supplies bill and customer details to financial and reporting systems (e.g. the corporate data warehouse) for further processing.





Account Maintenance / Inquiries Supports inquiries from customers and staff about a customer’s billing arrangements (e.g. orders, payments, bills). Customers may also be able to view their own information and self-serve themselves for a limited range of purchase / update transactions.

Activation / Service Provisioning

A customer order can be understood as a checklist that drives change in the network, which is later reflected in billing. This change may include the inventory reservation of specific equipment (e.g. telecommunication lines, electronic tollway tags) and its association with a specific customer. Such reservations ensure that future orders do not double-book the same piece of equipment.

It is almost always cost-effective to automate the network modification (activation) process. Automation will both reduce the staff required to maintain network connections (particularly as the network or customer base grows), and provide the customer with more prompt network connections and updates.

Despite validation in the ordering process, an order can error during network provisioning and require human intervention. Errors can be caused by a misalignment of validation processes between ordering and network provisioning, or can be due to a misalignment between the customer’s details activated on the network and those already held elsewhere (e.g. billing, ordering).

Some orders will not affect the network itself, but instead will change the customer’s billing arrangements. For example, a telecommunications customer may select a new pricing plan with cheaper long-distance phone calls but a higher monthly subscription. This update does not affect the customer’s network connection or where they can call, but when calls are made the new pricing plan will affect the amount the customer is charged. Orders not requiring network manipulation can be passed directly to the billing system for processing.

Due to the diversity of possible networks, Billing for Business Networks will focus on the billing impact of different provisioning approaches, rather than the networks themselves.

Transaction Collection / Mediation

Two important considerations drive this billing function. First, it is difficult to communicate with complex and diverse networks. Second, the raw information collected from a network may be insufficient (or unreadable) for billing and require manipulation before it becomes useable.

A large biller (especially in the telecommunications industry) may operate a network with different equipment vendors using various software programs across geographically diverse areas. To collect network information, the mismatches among the various network systems need to be systematically (and transparently) rationalised. The specific commands in one vendor’s program are likely to be unique to its hardware. Even the same





vendor may modify commands on new versions of its equipment’s software causing subtle, but important, changes in the network’s operations.

The collection process must address these differences and isolate them from the rest of the billing process. Downstream billing processes must receive transaction records without worrying about how they were obtained. By doing this, the integrity of the billing process is preserved, even when new network equipment is installed.

The raw information collected from the network may omit information required by billing. This can be because the network doesn’t need it to deliver network services. Also, some network information may be in error (e.g. transposed phone number digits), require enhancement (e.g. additional field values based on the transaction), or require modification (e.g. time zone standardisation) before it is passed to billing. Data mediation thus serves to isolate the idiosyncrasies of the network from the billing process.

The centralised transaction correction and standardisation performed in mediation reduces the maintenance effort expended downstream to pass existing transactions to billing, and the integration effort required when new transactions (and networks) are introduced. The standardised transaction format(s) generated by the collection / mediation function can be reused by other business functions. e.g. fraud detection, regulator reporting, network load analysis

Transaction-level pricing (Rating)

Rating performs the heavy lifting for billing. Rating combines network information, customer details and marketing (rate) information to determine the specific amount a customer is to be charged for a given transaction or transaction sets. The initial determination may be modified by later bill processing to reflect discounts and taxes.

Where a biller operates in a competitive market (assuming no changes in the network), it will reflect any (re)packaging of existing offerings in rating. Marketing imperatives may dictate frequent repackaging with short lead times. The speed with which changes can be made, and the versatility of the available rating methods determine the level of support billing can provide to marketing. A biller which does not compete for customers will still require accurate rating for its mass markets, and possibly customised offerings for its larger corporate customers.

The more detailed the information passed from the network, the more options there are for rating differentiation. For example, if a transaction’s date is known then day-of-week rating can be applied; a transaction’s time can support peak and off-peak price offerings.

Rating may be applied uniformly across a large customer segment (e.g. consumer), or be tailored for high-value customers (e.g. large corporates). Each transaction must have the appropriate rating approach determined. Different transactions for the same customer are likely to be charged differently. Subsequent transactions may be rated differently based on the totals of transactions to date. To enable timely transaction processing, billers with high-transaction volumes usually require substantial infrastructure (i.e. IT hardware).





Rating may be performed after the fact (e.g. charging for water) or in real-time (e.g. prepaid phone calls). There is a substantial difference in complexity between these two approaches. Achieving real-time processing requires high-availability, high-speed infrastructure to ensure that the correct price can be supplied quickly at all times. Rating for ‘after the fact’ transactions can be performed with some latitude as the rated price of (say) phone calls is not required to execute the network events (i.e. connect the phone calls).

Bill Generation / Bill-level Pricing

This function aggregates and forms bills to customers for transactions and/or activity performed within a given time period. The billing frequency may be at the customer’s choice, be driven by industry norms, or be based on negotiated terms. Interim bills may be prepared when a need to convert unbilled charges into debt is identified. Final billing may be performed when a customer’s network connection is terminated. Operationally, the bills for thousands of customers are usually prepared at the same time.

It is advisable to perform validation within a billing cycle to review the correctness and reasonableness of the customers’ bills. Validation asks whether bill totals are reasonable, taking into account a given customer’s market segment, and their historical activity.

Bills that fall outside of industry and business specific ‘correct and reasonable’ tests may be held for review by the biller’s staff before their release. Bills for sensitive or important customers may be held and reviewed to minimise the impact of any errors.

Bill-level discounting may be performed using the customer’s aggregated purchase information. This discounting provides a customer (marketing) benefit by rewarding high-spending. A deduction (discount) is made from the amount calculated in transaction-level pricing (rating) and the nett amount is presented on the customer’s bill.

Some bill-level discounts may require a repricing of individual transactions during the bill generation process. This generates a high and immediate processing load. Repricing performed during bill-generation is less common though the full range of pricing methods can be made available. The initial pricing performed in rating is performed gradually (through the month) and operates with a lower (average) peak load. The time-critical repricing performed within the bill generation process necessitates a more expensive infrastructure (i.e. IT hardware) to supply the additional processing capacity.

Once all charges for the period have been finalised, rounding is performed to transform high-precision amounts (four or more decimal places) into charges that can be presented to, and paid by, the customer in an understandable format (e.g. two decimal places). This can also include the rounding of the bill to support easy payment by the customer. For example, in Australia, due to the lack of one and two cent coins, bills may be rounded legally to the nearest five cent multiple. The rounded amount could also be carried forward and applied to the next bill.





At the completion of this step, the amounts to be charged have been calculated, and the information to be presented on the bill sourced (e.g. marketing messages, prior payment details). The next function formats these details for presentation to the customer.

Bill Presentation / Distribution

Bill presentation deals with the bill’s physical appearance. The charges, supporting information and any marketing messages, as determined in the preceding function, must be formed into an effective format for presentation to the customer. Distribution involves getting the bill to other parties, principally, but not only, the customer. Thus, distribution is concerned with both media and mechanisms.

A bill’s physical appearance is influenced by the biller’s marketing function. Beyond the need to present a request for payment, in a format that explains why the customer is charged the billed amounts, a bill can differentiate the biller from its competitors. Since the bill is a core communication channel to the customer, the clarity and breadth of the information must be carefully considered, and may include information unrelated to what has been billed. For example, energy companies may want to show customers the quantity of carbon released to the atmosphere. Other information may be required by regulation or tax law (i.e. due to the bill’s status as a financial document).

The bill’s details may be distributed through many different channels. Many of these channels are directed at the customer, but at least one of them will be for the biller’s internal staff. External channels include paper, email, internet based self-service portals, and optical media (e.g. DVDs). The channels used for different customer segments will depend on cost and usability trade-offs. Paper is relatively expensive compared to delivery via the internet, and does not support the data analysis desired by corporate customers. On the other hand, the usability of paper and internet-delivered consumer bills for mass-market customers is high, but corporate bills composed of thousands of pages and delivered by courier truck are more of a challenge.

The same bill information may be delivered to multiple destinations. For example a summarised format may be delivered to a corporate customer’s head office on paper, while a detailed statement may be delivered by DVD to the customer’s data analysis department, and location specific reports may be manually downloaded from an internet portal by the customer’s regional offices. In this case the same information is utilised, but the views are tailored for different needs within the customer’s business functions.

A bill not only requests payment from a customer, but also provides support for the revenue the biller receives. Bills invariably need to be retained for a variety of legal, tax and regulatory reasons, and therefore effective storage and retrieval mechanisms are required to address these concerns.

Downstream Reporting / Business Support

Billing generates a high-volume of information that can be used, or is required, by a biller’s other business applications. The needs of some of these recipients will be more urgent





than others. For example, the identification of possible fraud will require prompt delivery (and indeed may require specific information directly from the network), whilst a profitability analysis of the biller’s business can perhaps be addressed with a short delay.

Large corporate customer, industry regulators, and other outside parties may also receive billing reports. In these circumstance, strict segmentation of the report information is required to avoid exposure of private customer details and competitive intelligence.

Some downstream functions, such as financial postings, will require most of the billing detail. Each bill must be traceable to a summarised financial posting, and each summarised financial posting must be related to its constituent sources. Other reporting will be performed on an exception basis. That is, criteria will be applied to identify a small subset of transactions, customers or situations that need individual review.

The information provided by billing to other functions may be raw data that is subjected to further processing. For example, the prices charged to customers for the music they download can be supplied to a biller’s content settlement system (Chapter 26). The specific settlement arrangements between the biller and each music provider are then combined with the ‘billed’ details to determine the individual financial settlements to be paid.

Account Maintenance / Inquiries

When databases are maintained and stored in multiple locations (copies), one of those locations must be nominated as being the point-of-truth (i.e. the database of record). When two locations disagree on a database entry, the value held by the database of record is deemed to be correct. This role as the data ‘master’ means that the maintenance, replication and back-up processes for the database of record must have integrity.

A billing system contains many databases of record. These hold details of the customer and their billing arrangements captured during the ordering and provisioning processes, and bill and financial transactions generated by billing. Some reference information (e.g. rates) may also be mastered from the billing system.

Some billers may choose to ‘master’ their customers’ details in other functional areas (e.g. a CRM platform). In these cases, the data is supplied to the billing systems by either replication between databases as it is maintained, or only as and when required for the billing process.

Whichever database of record approach a biller takes, the data within the billing systems must be accessible to address internal staff and customer inquiries. Some data maintenance will also be required to update customer details and reflect changes performed by staff (e.g. notes against a customer’s account). Historically, batch orders were processed daily. This approach is still performed, but increasingly the direction taken is to perform maintenance in real-time, or near real-time (i.e. with a delay of minutes). This allows any errors to be addressed immediately with the customer rather than the next day.





Customers ringing the biller with an inquiry will be assisted by the biller’s staff using an online system that retrieves and updates information held on the billing databases. The online system may be a billing-only interface, or a specialised CRM package that aggregates non-billing details in order to provide richer information about the customer. Where provided, customers can use a self-service portal using internet technologies to examine their own account details, possibly performing limited updates (e.g. purchases) without the intervention of the biller’s staff. The biller’s staff may use a version of the same internet portal with additional maintenance and inquiry functionality enabled. This additional functionality would perform internal functions not suitable or desirable for customers to operate (e.g. dispute resolution, credit checking).

By volume, most maintenance of the customer database will be sourced from the ordering systems (e.g. CRM application). However, there will be some complex maintenance that is best done manually to allow immediate validation of the correctness of actions performed. For example, if a corporate customer wishes to modify their large organisational hierarchy, manipulation using a GUI screen with its immediate feedback is likely to generate a more accurate result than a batch maintenance order submitted overnight.





Chapter 4: The Core Data Concepts Of BillingFive Core Data Concepts

The billing process operates on data collected from customers, networks, marketing and other sources. Billing applications contain a range of customer, network and marketing concepts, but a core set forms the basic framework that anchors bill processing. This basic framework is then supplemented by vendor, industry and biller specific extensions.

A data concept is implemented as a structured grouping of related fields into one or more related ‘databases’ that billing processes can reference during bill processing. A customer’s database entries will be updated over time reflecting their ongoing interaction with the biller and its network(s).

Core data concepts are often shared across different functional areas within the biller, but each functional area focuses on the specifics relevant to its local operational needs. For example, a network function (e.g. activation) will focus on the network-specific data (fields) representing a telephone service whilst billing will focus on different billing-centric data (fields).

In this example, the data concept of a network ‘telephone service’ is ‘shared’ across functional domains through the use of a common and unique identifier, the telephone number. Identifiers such as these allow databases to be reconciled and other cross-domain processing to be performed without the forcing the replication, and much worse, maintenance of all data fields across a biller’s entire operational environment.

These five core data concepts will be explained later in more detail. This chapter provides an initial context for those readers without a work history in billing.

- Customer identifies each external person or business entity involved in or responsible for billing or subsequent bill payment. (Chapter 17)- Accounts are the structural entity at which the billable charges incurred against a customer’s network services are aggregated to form bills, and the entity against which (pre-paid) credit / (post-paid) debt amounts are often stored. (Chapter 18)- Service entities differ the most between industries and network technologies as they represent the network delivery point for the biller’s market offerings. (Chapter 19)- Products represent what the biller sells to its customers including network (e.g. consumption) and non-network (e.g. pricing plans) offerings. (Chapter 20)- Billing Hierarchies are a relationship structure that associates customers, their accounts and related services. In more complex (corporate) billing, hierarchies can link network services into sub-groupings for use in bill presentation and pricing. (Chapter 21)

Important second-level data concepts are either generated by the billing act, or extend / support the billing relationship and include:





- Taxation- Address- Contact History- Notes- Bill Details- Disputes- Financial Postings

Databases of Record

The core data concepts listed above represent key information that must be shared accurately and consistently across multiple functional domains within the biller (e.g. products), and therefore the databases that hold these concepts are often classified as databases of record. Databases of record (DBoR) are the referential ‘points-of-truth’ used when determining an accurate and definitive value for a data value or record.

DBoRs are updated in one ‘location’ using a consistent update process, even when copies of the database are stored in multiple locations around the biller. The ‘primary’ or ‘master’ database is deemed to be the ‘truth’, with all databases being ‘secondary’ or ‘slave’ copies of this information. Additional processing costs and complexity may be incurred associated with database replication and alignment to maintain the ‘primary’ database’s status as a DBoR reference point.

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 license number. For a business entity these details might include the business’s registered corporate name, registration jurisdiction, company officer(s) and business registration number.

The customer concept associates customer’s 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 customer’s 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 service’s 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 customer’s 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 subtotaling 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 the maintenance costs in a low margin customer relationship.

Seven Important Second-level Data Concepts

Aside from the data captured and stored for the core data concepts, billers will also capture customer data generated by billing operations, interactions with customers, and





external reference repositories subsequently used in billing. These important second level data concepts include:

Taxation These details describe the relationship between a biller’s products, tax jurisdictions, and the methods used to calculate the correct tax amounts. Taxation details are required in multiple places within the biller’s organisation including front-of-house sales (providing the correct ‘total’ price), revenue assurance (validating system processing), and billing. Billing systems are an important user of tax information since calculations are usually based on the actual (final) amounts billed to customers. The financial and corporate consequences of miscalculating tax means that details are often maintained centrally and monitored closely as a corporate database of record.

Address Accurate descriptions of ‘location’ are important in billing, not just for creating a bill. Different address types are employed depending on the situation. For example, addresses can indicate the service location for a utility meter, the mailing address for bills, website addresses (e.g. IP numbers, URL) may be used to calculate charges, or the latitude and longitude may describe the location of equipment (e.g. pipes, communication cables, electricity poles). Addresses are complex and often prone to inaccuracies when entered manually by staff or customers.

Contact History Each time a customer and biller make contact, details of their interaction can be stored to assist the biller in future contacts. Capturing details of historical contacts avoids the need for customers to restate their problem / inquiry, and reduces the chances of inconsistent messages supplied by the biller to the customer. The types and frequencies of customer contacts can be analysed for patterns and trends that may indicate problems (e.g. customers can’t understand their bill), and opportunities (e.g. proactively contact customers if they are unhappy and at risk of changing providers).

Notes Notes complement the contact history and provide detailed information for subsequent staff interactions with the customer. They can be generated internally by staff during problem investigation, or automatically by billing processes. Details captured in notes might include credit management activities (service suspension, disconnection), special customer details (disability (deafness, blindness), doctor / hospital, relatives of the CEO), internal contacts within the biller (sales representatives, account managers) and customer-specific details (authorised representatives, restrictions on communication to address identified stalkers).

Bill Details Whilst the debt and due date of a bill can be stored easily, to address all customer inquiries additional information must be stored. These details can be used by staff and customers alike to (re)view bills, and support follow-on processing such as disputes.

Disputes Disputes are the formal recognition of bill details challenged by customers. Dispute details drive the investigation of a customer’s challenge, but can also identify systemic problems when excessive disputes are raised against (say) specific call destinations, charges levied on a specific day or product families. By capturing details of a customer’s disputes and holding them against a customer’s bill details, the generation of





duplicate disputes and subsequent financial adjustments against the same charges can be avoided.

Financial Postings After bills have been generated, billers must store accurate financial postings that reflect the charges levied against each customer. Individually, these postings reflect the revenue, debt and payments attributable to each customer. In aggregate, the postings form the foundation of a biller’s corporate financial ledger (e.g. revenue and debt). Revenue analysis can be performed against customer’s purchases using additional segmentation dimensions (e.g. market segment, geographical location, business unit, product ‘family’). Customers must step through their bills, payments, dispute credits and other miscellaneous financial postings and agree that their billed and outstanding amounts are accurate. The biller’s auditors must do the same across all bills to sign-off the biller’s corporate ‘books’.





Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics

Business

Transcript of Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics