This chapter discusses:
Account management.
The account framework.
Account hierarchies.
Billing management.
Dispute creation.
Accounts are created through the order management business process . When a new customer places an order for services, account-related information is captured. Once the order has been saved, a CRM account is created by the business project associated with the transaction.
One of the phases in the order-capture business project sends a message to the billing application to have a billing account created. Once that billing account is created, a message is sent back to PeopleSoft CRM , and the CRM account is updated with the billing account number.
Customer service representatives (CSRs) and customers (using self-service) can view and update account-related information, including services associated with the account, associated bills, bill-related disputes, and account relationships.
Bills; bill items, such as local calls or taxes; bill item details, such as all calls made in the time period; and bill images can be viewed through the bill management functionality.
Accounts provide a framework to manage the services and products that have been purchased or subscribed to by the customer of a communication service provider (CSP). Invoices, which are typically generated by industry-specific billing applications, are generated at an account level. All requests and orders, whether for new services or changes to existing services, are managed at the account level. Accounts dictate billing information such as bill payment type, invoice frequency, and bill payment information, including credit card numbers. Accounts are generally created and mastered by the billing system. Account setup and management in PeopleSoft CRM industries is generally driven by the requirements of a specific billing application. PeopleSoft CRM industries integrates with any standard billing system, including PeopleSoft billing.
The accounts framework enables the CSP to:
Capture essential information for account creation (primary contact, payment type, payment details, and so on) during new order capture.
Create accounts as part of a business project associated with new order capture.
Associate an account with a single user or multiple users.
A particular service can be used by more than one user. For example, a DSL service for a residential customer may have four family members who access the service. Each family member has an individual email ID. Out of these four, the head of the household is the primary contact and is authorized to make changes to payment details, to add, modify, or delete services, and so on. The bills for the DSL service go to the head of household. The other three members of the family can view account details.
When you assign multiple users to a single account, you select from different roles that determine user privileges. Roles include:
Account owner.
The account owner is the person responsible for the bills associated with the account. The account owner may or may not have associated primary contact or users.
Primary contact.
This relationship record is automatically created when a contact is designated on the account main information form.
Users.
Users do not have any responsibility for the account. For example, if a household has a single telephone line, the head of the household is the primary contact and account owner, and other members are users.
Corporate customers.
These are usually organizations that own a particular account and have a designated primary contact.
Associate either single or multiple products and services with an account.
You can associate multiple products and services with one account. For example, an account can have both basic telephone service and wireless service.
Define account types and account associations.
Associate accounts with a bill and maintain billing history.
Associate accounts and addresses.
Modify account details, which includes adding or removing account users, changing payment details, and changing address information.
Appropriate EIPs reflect these changes in the billing system.
Integrate accounts as part of the 360-degree view of the customer and part of the Interactions page.
This is configurable.
Enable CSRs and administrators to change payment and associated details.
Business accounts are supported through account hierarchies, with a parent/child relationship between accounts.
Subordinate accounts do not receive a bill, although the usage is tracked to the individual account. For example, ABC Company provides cell phones for employees. ABC Company receives an aggregate bill that tracks the usage of each employee. Individual employees, the subordinate accounts, do not receive bills.
In nonsubordinate accounts, the child account is responsible for bill payment. For example, ABC Company sponsors a corporate credit card. The parent account belongs to the ABC Company, and the child accounts belong to the employees to whom cards have been issued and for whom separate accounts have been defined. The employees are responsible for paying the accounts.
Sponsored Accounts and Sponsoring Accounts
Sponsor accounts are responsible for sponsored rates. For example, a company may sponsor the subscription (monthly cycle fees) for a mobile phone service for its employees. However, the employee is responsible for any additional usage fees. Therefore, the bill item associated with the subscription fee is associated with the sponsor bill, and not with the employee bill.
These accounts are owned by individual customers, and the primary account holder is responsible for associated billing.
Note. These hierarchies, as well as bill consolidation, take place in the billing application.
PeopleSoft Enterprise CRM provides a robust billing framework, which enables CSPs to tightly integrate billing applications with the CRM system and offers front-end application functionality needed for CSRs to support a range of customer interactions.
Note. Billing information comes from external third-party applications to PeopleSoft Enterprise CRM through integration.
CSRs can view a customer’s entire billing information profile in different levels through one single desktop application. Customers can look at account and billing information using the self-service application.
The billing framework offers a complete, multidimensional view of customer billing information all in CRM application for CSRs to handle billing inquires. During customer interaction, CSRs can look at billing information (bill and bill items) in summary and detailed views and view bill images in HTML format, which enables the CSRs to quickly and effectively address customer inquiries.
The billing framework provides front-end billing functionality through the implementation of enterprise integration points (EIPs). For example, the Bill Dispute and Adjustment EIP enables CSRs to create disputes on account balance, account usage, bill item, and bill event. Administrators can set up application rules to decide whether a dispute needs to be routed to the Billing department or can be adjusted in the customer’s account instantaneously (if the disputable amount does not exceed the threshold value).
The CRM system uses cases to handle disputes. When customer logs a complaint with CSR regarding a bill dispute, the system captures the dispute information and creates a bill dispute case. If the dispute can be adjusted (determined by configurable application rules) instantaneously, the disputable amount is credited back to the account in the CRM system and a credit transaction is sent to the billing system for account update. The dispute case is closed. However, if the dispute needs further investigation from the billing side, a message is published to the billing system to begin the process. Then the case remains open until the dispute is resolved. Bill dispute effects on account balances or billing information are updated and reflected in the CRM system accordingly.
All transactions taking place in Interaction Manager between CSRs and customers regarding billing inquiries and disputes are captured as interactions.
Bills are associated with accounts. A bill (for example, cellular phone bill) is a collection of bill items (monthly service charge, federal tax, and so on), and each of these items is linked to one or multiple bill events (for example, call details).
The CRM system captures and passes the following data elements to the billing system in a dispute:
Data Elements |
Description |
CASE_ID |
The dispute case ID. |
BUSINESS_UNIT |
The business unit for which the case is opened. |
RBTBILLID |
The bill identification number internal to the CRM system. |
RBTACCTID |
The account ID internal to the CRM system. |
RBTBILLSYSACCTID |
The corresponding account ID internal to the billing system. |
RBTBILLSYSTEM |
The external billing system name. |
RBTBILLSYSID |
The bill ID internal to the billing system. |
RBTBILLITEMID |
The bill item ID internal to the CRM system. |
RBTBILLSYSITEMID |
The bill item ID internal to the billing system. |
RBTEVENTID |
The bill event ID internal to the CRM system. |
RBTBILLSYSEVENTID |
The bill event ID internal to the billing system. |
RBTDISPTYPE |
The dispute type. Valid values are Balance, Usage, Event, and Item Dispute. |
RBTADJTYPE |
The dispute adjustment type. Valid values are Credit or Debit. |
RBTAMTADJ |
The adjusted amount. |
RBTRESOURCETYPE |
The type of resource adjusted. Valid values are Dollars or Minutes. |
RBTDISPREASON |
The reason for the dispute. |
RBTDISPUTEAMT |
The disputed amount. |
RBTDISPSTATUS |
The status of the dispute. Valid values are Approved, Denied, Hold, or Pending. |
DESR254 |
The dispute note. |
Note. The same logic applies to all disputes. The only difference is that in each type of dispute, the use of configuration threshold values is different.