Thursday, April 30, 2009

Customer records

The customer record should be independent of any Account record, as the customer may have multiple accounts. Older-style billing systems focused on the parcel or address (for property taxes) or the meter (for utility billing). Modern billing systems focus on the customer and the management of customer information. Among other things it means that when a customer moves to a new address all of the data already exists and does not have to be re-keyed. Because some data is non-standard, either between customers or between different cities or utilities, a number of user-defined fields should be available in the billing system to support this need.

From Customer Management Fact Sheet which can be found at Public Sector Billing.

Wednesday, April 29, 2009

CIS Billing

Billing systems are as often as not these days called “CIS Billing” - meaning Customer Information System. A CIS sytem will have customer records that keep a history of contact with a customer (calls, correspondence, e-mail), their credit data such as credit rating or deposits, and theft and tampering history (for utilities). Other data could be as extensive as preferred language, banking data for direct debit, even preferred bill format and preferred bill delivery method, such as via e-mail rather than standard mail. Corporate customers may have extensive data relating to headquarters and branch locations, linked accounts or premises, and company representatives.

A Customer is not necessarily a person or business who receives regular bills. They may be someone who is an irregular contact. Nevertheless the CIS Billing system should retain their data for use when required.

From Customer Management Fact Sheet which can be found at Public Sector Billing.

Tuesday, April 28, 2009

Account Enquiries

A well-designed summary enquiry screen makes the job of the call center operator easier and increases throughput. The summary screen should provide at-a-glance information that will answer 80% of standard call center enquiries such as the due date for the current bill, whether a payment has been received, the next date a bill will be sent (based on a meter reading or an installment), or (via a graph) the consumption pattern on a utility bill. It should also provide via drill-down access to supporting detail. Where values have changed over time (property value or metered consumption) an enquiry at the line level of the bill should show how the charge was calculated.

From the summary page a list of hot links should give the user access to their most common actions. That is, a list of common actions should be able to be tailored by each operator. As well their should be access to the knowledge base of answers to frequently asked questions.

From Account Enquiries Fact Sheet which can be found at Public Sector Billing.

Monday, April 27, 2009

Account Contacts

A Billing system should support Contacts who have multiple Accounts, both at the same time (ownership of multiple properties) and over time (as a person buys and sells properties as their place of residence). Each Contact may have multiple addresses – work, home, mailing – each with their own attributes. The contact's primary information (date of birth, driver's licence) does not change and so forms part of the central record, but address information is more variable over time and should be part of a series of effective-dated sub-records, linked to the central or main record.

It is important that a record is kept on each Account for Contacts other than the person(s) legally responsible for paying the Account. There may be a person practically responsible for paying the Account, such as a parent, child or legal guardian, who would also receive a copy of the Bill at their own address. Generally this is known as “third-party billing”. As circumstances vary between cities or utilities, the ideal Billing system should not be prescriptive as to classifying such people; it should support user-definable categories.

From Account Contacts Fact Sheet which can be found at Public Sector Billing.

Sunday, April 26, 2009

Account Relationships

"Some of the stand alone objects that are drawn into a relationship with the Account are the customer, the address or parcel (for property-based bills such as tax or utility bills), the services or valuations being billed on the address or parcel, the permits associated with the address (if property-based) or the customer, and the licences that customer holds or that have been granted for the business. Utility billing applications will also have information about the meter and its reading route and sequence."

From Account Relationships Fact Sheet which can be found at Public Sector Billing.

Saturday, April 25, 2009

Account Attributes

"A carefully thought-out Account structure is the key to effective revenue management information. While the Account is itself a business object, with its own numbering rules and attributes, it also draws on other stand alone business objects such as the address or parcel of land and customer names, also known as Contacts.

Three attributes belong to the Account alone – the Account number, the Account type and the industry code.

One mistake some utilties make is to have the meter reading route number embedded in the Account number. This does not make for flexible solutions and modern utility billing applications should be able to show an Account's route details without embedding the data in the number.

Account type is not always used. The most common of these is the “owner” Account and the “Tenant” Account.

Finally the Industry Code should be an Account attribute. These are generally known as Standard Industry Codes (SIC) and each country publishes their own standard list."

From Account Attributes Fact Sheet, which can be downloaded from Public Sector Billing

Friday, April 24, 2009

Move In functionality

"One of the most labor-intensive actions is Moving a customer in or out, or sometimes between two properties within the area served by the one city or utility. The process should be highly configurable and should also allow for common events such as a change in date or a cancellation. With a cancellation the Move In or Out may have already been carried out in the billing system and have to be “undone”; a good billing system should support these actions as automatically as possible. Where a customer is transferring between properties, all of their banking and security deposit data should follow them to the new address." From Move In & Move Out Functionality Fact Sheet, which can be downloaded from Public Sector Billing