Note 61: Transaction Sources and Types

Posted: 26 February 2009

Transaction Sources

The need to perform inquiries on, and maintenance against, a customer's details will come from different business functions within the business, each with a different focus.

External Customers: By volume, inquiries and maintenance requests from customers will form the majority of the workload performed. The larger number of customers relative to the biller's staff ensures that most transactions will be triggered by customer contacts.

Internal Inquiries: In addition to the staff who address customers' inquiries, specialist business groups within the biller will use the billing details to perform their work. Their target customers may be identified by automated or customised (one-time) reports.

Problem resolution: Identified errors in the biller's IT systems or processes will be investigated to identify their scope. The investigation may be performed by the IT support staff using technical tools, or through the billing system's inquiry screens.
Dispute investigation: Customers querying the charges on their bill may have their dispute answered immediately, or additional investigation may be required. Disputes against large numbers of transactions or for large amounts are likely to be investigated more closely to confirm the dispute's validity and rule out wider systemic problems.
Market analysis: Investigations of the biller's customer and transaction details to confirm the details of identified trends and marketing opportunities. Findings may be passed to other internal groups if system errors or fraud are suspected.
Fraud: This group may identify customers likely to generate uncollectable debt, misuse the biller's systems, and/or perform criminal acts on the biller's network. Details may be collected from the billing system and forwarded to police. Areas of interest can include:

Customers who break conditions of use: The biller may sell products and services with restrictions included in the terms and conditions. Customers contravening these conditions may be contacted by the biller to stop or modify their contravening behaviour.
Presentation of invalid identity documents: False identity documents may be presented by customers suggesting an intent to defraud the biller.
Patterns of behaviour suggesting an intent to avoid payment: Based on historical data and experience, billers may investigate customers who exhibit spending patterns or behaviours associated with past fraud. Customers may be contacted, their purchases monitored or credit limited to reduce the impact of fraud or bad debt.

Revenue Assurance: As part of the revenue assurance process, a customer's bills can be used to compare the actual billing of transactions against the biller's intended result. Bill details can be used to confirm that charges were levied, for the correct amount, and with the correct presentation.

Transaction Types

From the biller's perspective, all aspects of the customer's data must be open to inquiry, and most should be maintainable. If fields are hidden or can't be updated, bill processing may occur without the ability to change it. Customer data considered 'historical' should remain unchanged to preserve an audit trail of the customer's details. Absent systems errors, customer data translates into customer bills which form part of the biller's financial documentation. Unfettered changes to historical customer data by the biller's staff will cause data misalignment with historical customer bills and make it difficult to isolate system problems from subsequent maintenance.

Internally, the biller may choose to limit which staff have access to customer data, and who may change which data. Different roles may have differing needs for data access and maintenance rights, but overall, all data must be accessible to support the biller's business functions. This does not mean that all data will be accessed equally. A small number of items (i.e. bill and service details) will be accessed more frequently than esoteric fields used in special circumstances or by a select customer population.

Where customers access their own billing details, perhaps via an internet portal, the scope of the details available and the updates allowed may be restricted. This approach reduces the complexity of the customer interface, reduces the learning required of customers to perform inquiries and other interface tasks, and keeps details of the biller's internal data confidential. e.g. credit assessments and internal customer notes.

Search

Inquiries are easily done when a unique identifier such as a phone or account number is available. When such details are unavailable, the biller's staff must perform a search of their customer databases to identify a customer before further actions (inquiries, maintenance) can be performed. Suitable pre-indexing of searchable information can greatly improve the retrieval speed, ease of use and success rate.

Two key details often available from a customer are their address and name. Addresses can be structured to facilitate their search and retrieval using street names, suburbs/cities and postal codes. Unless the biller's geographic scope is global, there is likely to be a finite choice of addresses. Successive refinement, using additional details of the address, can reduce the number of customer choices to a limited list from which the customer in question can be selected.

Names are more complex due to the prevalence of certain surnames (e.g. Jones) and the likelihood of misspellings. The customer will be able to articulate their own name, but the name in the biller's database may have been stored in a different format (e.g. 'Jones, Stephen', 'Stephen Jones', 'Mr. S. Jones') or with a different spelling (e.g. Stephen, Steven). For uncommon names, the list returned may be small, but more common names may require additional qualification to reduce the retrieved list's size. For example geographical information such as postal code, state or suburb can be introduced to refine the search.

Search capabilities can also be beneficial for other customer data, such as bill details. A large bill containing many services, different charge types and charge details can be difficult to navigate. If the biller's staff (and customers) can search using different criteria to find a specific charge, or get close to where a charge is presented on the bill, their productivity will be improved.

Effective Dated Inquiries

By preserving historical customer data and capturing the date when maintenance is performed, the biller's staff may review the customer 'as of' a date in the past. This can assist staff performing problem resolution by revealing the customer details in force when a transaction was performed, rather than the current values. The ability to provide such a historical view of the customer will depend on the capabilities of the billing system.

Whole Of Customer View

Rather than viewing customer data at the detailed level, an alternative is to generate an overall picture for the customer using an aggregated view of related data. The biller may apply such a 'whole of customer view' to customers of any size, but the benefits will be more material for larger customers that cannot be assessed easily from detailed data displayed on a screen-by-screen basis.

Achieving a 'whole of customer view' requires two elements be present. Firstly, a customer structure, such as a billing hierarchy, is required to associate related accounts and / or services. This associative mechanism defines what 'whole of customer' means. The second element is the data that will be aggregated into the 'view'. Examples of possible data include outstanding debt (credit), billed revenue totals, details of unbilled transactions, counts of provisioned products, and network usage (minutes, dollars, type). A consolidated view can be constructed for customers with thousands of services and multiple accounts billed at different times.

The customer data aggregated into a view may be stored on separate systems (including multiple billing systems), and may need to be retrieved centrally prior to its aggregation and presentation. This approach allows a 'virtual' view to be constructed without necessitating data be stored 'physically' in one application or database. Data can remain where it makes the most sense from an application or operational viewpoint and still be available for use in a whole-of-customer view. The customer's structure may be reused to aggregate and present a variety of data sources using different retrieval and aggregation mechanisms.

Tags: Billing, Customer, Customer View, Inquiry, Internal, External, Search