Understanding Call Center Prompt Tables
This topic discusses:
Call center prompt tables.
Delivered values in call center prompt tables.
This topic explains the different types of prompt tables that you must set up for all core call center application prompt tables.
Prompt Tables for All Cases
To get your PeopleSoft CRM call center application up and running, define values for these fields:
Case Status (required)
Case Type
Impact
Priority
Urgency
Severity
Source
Category, Specialty Type, and Details
Problem Type
Quick Code
Each quick code may be associated with values from one to up to over twenty different case fields. Values referenced by a currently active quick code cannot be deleted. When an agent enters a quick code on the Case page, the system automatically enters all of the related data. It does not save the quick code to the case.
Problem types are defined by the product for which a case is being created. Use problem types to associate products with the competencies that one needs to resolve a problem. Because Problem Type is a child of Product, the Problem Type field on the Case page derives its values from Product. The Product must be set up before Problem Type. Competencies for Problem Type are not restricted, however.
Problem Codes for PeopleSoft Support Material Returns
This section is specific to PeopleSoft Support.
Problem codes identify why a customer is returning stock on return material authorizations (RMAs) created in PeopleSoft Support. If your PeopleSoft Support system is integrated with PeopleSoft Inventory, the problem codes that you select on RMAs must match reason codes defined in PeopleSoft Inventory. In addition, the matching reason codes in PeopleSoft Inventory must be defined with a reason type of Return Material Authorization. When the RMA is staged in PeopleSoft Inventory, the problem code is used as the reason code. If the reason code on the RMA form does not exist in PeopleSoft Inventory, the system logs an error when the RMA EIP (return material authorization enterprise integration point) application message is processed.
Reason Codes
Enter reason codes to define reasons for various actions. Reason types are associated with a reason code and include:
Reasons why a person has been associated with a case as an interested party.
Reasons why a self-service user is closing a case.
Reasons why a self-service user is reopening a case.
Reasons for billing adjustments. (Used with billing contract integration.)
Case Relationship Types
Cases can be related to each other for many reasons. Here are some examples:
A global case affects many people, but one resolution solves the problem for everybody.
Suppose that your website is down because of a problem with the web server. Many people are reporting the same problem. You only need to fix the problem once to resolve everyone's problem. Create a global case for the problematic web server and child cases (sometimes called tickets) where each person is reporting the problem. Maintain a parent-child relationship between the global case and all of the tickets. Based on this relationship, you can close all of the child tickets once the global case is closed.
A common case affects many people, but each affected person requires a separate resolution.
Suppose that a software bug is causing problems. Again, many people are reporting the problem, but this time each individual must apply a software patch. Create a common case to track the problem and create child cases for each individual reporting the problem. Based on this relationship, you can track the effect of the problem across your organization. This common-case parent-child relationship differs from the web server global case because you do not want to close the child cases when the common case is closed.
A similar case helps an agent to resolve another case.
Suppose that two people have reported problems with their desktop computers. The problems sound similar, and each assigned agent wants to monitor activity on the other case. Similar cases are functionally related, but they do not have a hierarchical relationship.
Other kinds of cases include cause-and-effect and case relationships that can occur in your business operating environment.
Establish valid case relationship types on the Case Relationship Type page. Each relationship is marked as hierarchical or equivalent (non-hierarchical). Each case in a relationship has a relationship label. If the relationship is hierarchical, separate labels exist for the parent case and the child case. If the relationship is equivalent, only one valid label exists.
If the case is not a hierarchical relationship, the Relationship field controls how the relationship is described on the Related Cases page. If you look at either one of the related cases, the Relationship field displays the equivalent label.
This topic discusses delivered relationship types. All of these values are associated with the SHARE setID.
These values are used in Active Analytics Framework (AAF) policies. For example, the PeopleSoft system delivers AAF policies to cascade case statuses and to send notifications to owners of related cases when a case status changes. If you use the delivered policies, you must use the delivered values or change the event processing rules to reference new values.
Relationship Types
This table lists the delivered relationship types:
Type |
Hierarchical |
Short Name |
Labels |
---|---|---|---|
COMMO |
Yes |
Common |
Parent, Child |
DUP |
Yes |
Duplicate |
Original, Duplicate |
EQUAL |
No |
Equivalent |
(none) |
GLOBE |
Yes |
Global |
Parent, Child |