Three locations for billing's customer databases

Summary

Billers hold different views of their customer across multiple applications' data repositories. These repositories form the collective reference data from which billing, network operations and other customer facing functions (e.g. customer care) are performed.

Three locations from which customers' data can be mastered include:

Core billing applications
Customer Care / FOH applications
A separate data repository held separate from all applications

Often architecture solutions master customer data in the customer care or billing applications. A separate repository isolates the customer data from vendors' data models and minimises the data migration effort required when migrating to new applications.

The approach chosen will be guided by previous decisions on application design, the political strength of the 'data architecture' group within a business, and the inclination of management (CEO, CIO) to buy packaged 'vendor solutions' over bespoke, customised or standalone designs.

Customer maintenance is performed in many locations

For a network business, the act of customer maintenance may necessitate changes to the network, updates to billing arrangements to adjust the amounts to be collected, and updates to the customer's purchase inventory so that future customer inquiries can be accurately answered.

Each functional domain updates both data elements unique to its function (e.g. billing, network) and reflects identifiers common across functions (e.g. customer number, network service identifier, account number). The accurate population and maintenance of common identifiers ensures related processing is performed accurately across domains. Examples of processing that depends on accurate data includes authorised access (inquiry and maintenance), product availability (e.g. residential versus commercial), and allowed compatibility (i.e. the product combinations allowed by marketing for different market segments).

Functional domains are less interested in details generated and better mastered elsewhere. For example, the network should have no interest in storing the specific details of customers' bills, and billing should be less interested in the specific settings of the network elements. Reconciliation processing, such as that used in revenue assurance, must be able to reconcile network processing to the bill, but the specific details can remain elsewhere (e.g. within their functional domains) where they are best understood and more accurately maintained.

Who holds the master customer database?

Core billing, network and customer-care processing must know which 'application' is the data 'master' or primary copy (database of record / DBOR) of the biller's customer data, and by implication which (other) applications are subsidiary to that master application. When a discrepancy arises between applications or during a problem investigation, the master database's field values are held to be 'correct', with other databases changed to reflect the 'correct' field values (...after appropriate analysis confirms it is not the master database corrupting the customer fields!).

Billing and customer care / front-of-house (FOH) applications are prime candidates for holding customer details because those same details are required to perform these applications' core task of interfacing with customers. Their functional domain are also sufficiently general that different customer types can be accommodated, and network specifics are less influential.

Network facing applications are an alternative location that could also master customer data, but these applications represent data at too low a level to hold customer / billing relationships easily. Network facing applications also tend to be closely tied to a network's specific technology infrastructure. Where multiple networks exist they are often managed by separate network-facing applications making a consolidated view of customer / billing relationships difficult. This consolidated view is increasingly important to support a single point of contact between customers and their network biller.

Network applications reflect data mastered elsewhere, often in billing or customer care (FOH) applications. New networks can be added and removed without drastically changing how high-level customer data is represented. When billing and customer-care applications are changed, the representation of customer data is often changed to reflect the data model of the chosen vendor's application. The old applications' data models are remapped to the new platform's data model and old data is migrated across during the transition.

Mapping actions performed on customer data across functional domains

When customer data is held within one functional domain, it must be mapped when used in the processing of nearby applications. Examples of mapping actions include:

Decomposition: Once a customer has made their purchase, the high level representation of the sale must be broken down into its constituent parts and passed to relevant applications. The changes in the network must be implemented, and the billing (if any) for the sale must be established. The inventory of the customer's purchases must be updated for future reference. These changes are also performed when existing network / billing / customer arrangements are changed, or the customer's relationship with the biller is terminated.

Meaning: A product offering may be represented one way to the customer (Gold: 'All you can eat broadband'), be translated into the necessary network representations (e.g. add a new ADSL broadband connection, with a symmetric speed of 1Mb/s and unlimited data access, shaped to a speed of 64Kb/s after the monthly data quota of '20Gb' has been uploaded / downloaded), and established in billing for charging (installation of $X, recurring charge of $Y per month and a 12 month contract with a penalty fee of $Z). The mapping between each (functional) application's internal codes and the master customer database requires a deterministic and consistent path between the code values involved in each application.

Coordination: One application may play a role in directing the actions in the network, billing and related applications. This process may be handed-off from the core applications to a separate processing layer that will decompose a customer purchase or change to the customer's data ensuring the necessary actions are all performed, in the correct order, employing the correct codes, and raising alarms to staff when errors occur.

This processing is mission-critical for complex, time-dependent networks (e.g. telecommunications) where customers can use network services immediately, and where they may be waiting on the phone or accessing a self-service internet portal. During its processing, the coordination process is ideally hidden and unseen when it works, though it can be disabling when it breaks and prevents all maintenance activity. Even though the biller may be unable to perform any customer maintenance, existing network services will continue to operate since they are operationally separate to the maintenance of customer data.

Reconciliation: This is a reverse example of the decomposition process. Whichever application is the data master must be reconciled with data stored elsewhere. This ensures customers receive the bills and network services they expect. Such reconciliations are core processes in Revenue Assurance.

An alternative model of a separate customer data repository

Rather than embedding customer data in one functional domain or another, an alternative model places customer data in a repository separate from all functional processing:

When billing is performed, customer details are extracted from the repository and passed to billing for processing. After bill processing, billing results are reflected back into the repository with little (or ideally no) customer data held within billing itself. Rating, bill production and credit management become functions applied against data extracted from and / or passed to this central repository.
When a customer calls the biller's staff on the phone, or makes an inquiry using a web-based customer care portal, the necessary customer details are sourced from the repository and displayed. Customer data maintenance in the central repository is performed through possibly multiple access channels, with the results available to all subsequent accesses.
Network changes, when reflected in the repository, can be made available to other functions without the need to access the specific network-facing application. e.g the status of a network service: active, suspended or terminated
Existing peripheral applications would extract their data from the central, separate repository rather than the relevant vendor application(s) as they currently do.

This approach requires a detailed investigation of data relationships (especially for customer and product related data), and the initial population of the repository from the data's current locations. Functional domains need to be modified to extract the data they need for processing, and reply with updates once processing is complete.

When technology architectures, hardware or connectivity fashions change, the customer data repository can be replatformed separately, independent of the vendor applications that will also change over time.

Functional applications are turned into 'processing engines' that can be interchanged with little (or at least less) data migration since the core data repository is less involved than with vendor packages. This architecture allows multiple applications to access and maintain customer data without binding the biller into the data model of one specific vendor's current software, or anointing one application vendor's data model over all others.

Tags: Billing, Data, Software, Customer, Network