Stephen Jones writing on Billing and Application Migration
The skeleton of the billing hierarchy associates three of the key billing data concepts (customer, account, service) together into a structure that different business / billing functions can attach additional processing parameters.
The billing hierarchy complicate the billing process, and the administration of customer data, and provides a reduced benefit for the smaller customer (e.g. mass residential market), whilst providing scope for additional benefit for the larger corporate and government customers the biller may have.
Aside from the three core concepts, additional 'intermediate' hierarchy points can be placed between the customer and account, and also between the account and service, and the core plus intermediate points are where additional processing and benefits can be obtained for larger customers with more sophisticated (complex) billing needs.
Billing hierarchies can exist for smaller residential or mass market customers, but are likely to be overkill given the simplicity of their billing hierarchy (e.g. a single network service). Larger customers are more complex and demand additional features, functions and support that a billing hierarchy can facilitate.
When performed at scale, a billing hierarchy supports three important functions:
Association The hierarchy links all the related billing accounts and network services into one structure. This can provide the biller with range of benefits including:
Whole of Customer View: The biller can obtain an overall spending picture of the customer. This association supports the end customer receiving the same level of customer service / pricing discount / problem prioritisation from the biller regardless of an individual billing account's contribution to the customer's overall spending with the biller.
Credit Management: If payments are slow to be received, or bills are remaining unpaid, the biller can use the billing hierarchy to understand the 'scope' of the problem and help ensure that high-value products are not sold (with a possibly increased risk of non-payment) in one area of a customer, whilst bills for the same customer go unpaid in another arm of the same hierarchy. The biller's account management staff can bring a consolidated picture of outstanding debt into their internal and customer discussions. If the customer goes bankrupt, the billing hierarchy provides a quick picture of where the biller must take action.
Inheritance The billing hierarchy provides a 'structure' where values can be inherited from points 'higher' in the structure to those 'lower' in the structure. The inheritance can be in the form of overriding 'default' values common to all points in the inheritance path, but such an inheritance can also set or tune specific parameters differently at lower points in the hierarchy influencing the billing process for that 'branch' of the hierarchy.
Points such as these can appear both between the customer and billing account data structures, and the billing account and network service structures.
Examples of inherited values influenced through the billing hierarchy are:
Rating (Pricing) Plans: Specific billing accounts may have different network usage profiles, and as a result a different pricing plan may have been negotiated by the customer. For example, specific billing accounts may collect the outbound call center services and be charged (under contract terms) a different call rate to that charged for outbound calls elsewhere in the customer's organisation.
Corporate Association: In spite of being related to the same 'customer', a customer may wish to distinguish between different corporate entities and mark related accounts through their inherited hierarchy relationship.
Authorised Representatives: Details of who within the customer may 'authorise' changes can be noted and inherited through the hierarchy. This can avoid the maintenance effort required to update accurately the representatives' details in many places.
Customer Service / Financial Accountability: Details internal to the biller that influence where a customer's inquiries are directed, and from a 'sales' perspective which organisation is credited with the customer's revenue (and debt). These internal characteristics can influence bill presentation by altering the (say) contact phone numbers that customers use when contacting the biller. Mass market customers will use a default number, but the biller's largest customers might contact dedicated support teams using their own specific phone numbers.
Due Dates / Billing Cycles: When calculating 'whole of customer' discounting, and/or 'consolidated (single)' billing, aligning the billing cycles and related due dates can reduce the processing complexities by all charges (especially recurring charges) having the same billing cycle / cutoff dates.
Bill Presentation: Specific bill formats may be used on (say high transaction volume) billing accounts, and details of these can be inherited and maintained using a billing hierarchy.
Presentation Grouping When formatting a customer's bill there may be a desire by the customer (or biller) to associate service together that would not otherwise fall naturally together. For example, it can be more natural for a (banking) customer to group each (bank) branch's phone numbers together, rather than order them on the bill by their numeric value.
Originally posted by
Download the FREE Book Sample
Stephen Jones is a consultant who has focused specifically on Billing and related processes for over twenty years. Recent work has included integrating a major telco's billing extracts with technical logs from call centres.
I contributed an essay on testing design assumptions in the O'Reilly book 97 Things Every Software Architect Should Know. This book was written in an 'open source' style with more than four dozen authors. The original essays of the axioms / koans / advice can be viewed on the project's wiki.
Enter your email address to follow changes and receive notifications of new posts by email.
You will be returned back to this page, and a confirmation email will be sent.