Understanding Call Center 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.

See Understanding Products in PeopleSoft CRM.

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.

See Setting Up Problem Codes for Material Returns.

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.)

  See Setting Up Reason Codes.

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.

  See Setting Up Case Relationship Types and Labels.

• 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.

Relationship Types

This table lists the delivered relationship types: