Basic Service Request Setups

This chapter outlines the basic common setups applicable to all modules of Oracle TeleService.

This chapter covers the following topics:

• Setting Up Business Processes
• About Statuses, Status Groups, and Service Request Types
• Setting Up Service Request Statuses
• Setting Up Status Groups
• Setting Up Service Request Types
• Grouping Service Request Types into Categories for Oracle iSupport
• Setting Up Service Request Severities
• Setting Up Service Request Urgencies
• Setting Up Default Response and Resolution Times
• Setting Up Task Types and Priorities for Service Request Tasks
• Setting Up New Note Types for Service Requests and Tasks
• Indexing Note and Summary Text for Searches
• Enabling Integration with Oracle Enterprise Asset Management
• About Oracle Workflow Processes Included with Your Application
• Setting Up the List of Values for the Language Field
• Obtaining a List of Valid System Profiles and Lookups

Setting Up Business Processes

Business processes are required for setting up the default service level agreement, Oracle Service Contracts' coverage templates, and for Charges (available in Oracle Forms-based Service Request window only).

To setup business processes

1. Under the Service responsibility, navigate to Setup, Charges, Service Business Process.

   The Service Business Process window appears.

   

2. Enter a name and optional description.

3. Specify the applications where you wish this business process to be visible by selecting the appropriate check boxes:

   • Depot Repair: Oracle Depot Repair

   • Field Service: Oracle Field Service

   • Service Request: Oracle TeleService (all modules).

4. If you are using Charges, you must also associate service activities to the business process in the Service Activities region. See Setting Up Business Processes, Service Activities, and Billing Types for Charges.

5. Save your work by clicking Save in the toolbar.

About Statuses, Status Groups, and Service Request Types

This topic explains the various elements you use to model your service request business processes:

• Service Request Statuses

• Status Groups and Status Transitions

• Service Request Types

• Service Request Type Categories for Oracle iSupport

Service Request Statuses

Service request statuses provide a classification system you can use to track the stage of a response to a customer problem from the initial customer contact to its resolution.

The application provides the following seeded statuses:

• Cancelled by User

• Clear

• Closed

• Open

• Planned

• Waiting

However, you can set up any number of statuses appropriate for the different types of customer problems.

For example, for billing problems you may want to include “Invoice Disputed”, “Dispute Denied”, and “Invoice Corrected”, for equipment exchanges: “Received”, “Fixed”, and “Shipped Back to Customer”.

Statuses can also:

• Specify what service request updates are permissible

  You can specify if a user is permitted to update a service request in a specific status.

  For example, if you use Charges to bill customers for service and you calculate the amount to be billed only after work has been completed, then you may want to permit agents working on “Open” service requests to update the information about the customer problem, but not the charges. When the work has been completed and the service request has the status of “Closed”, then you may want to bar agents from updating the problem information, but permit them to modify the charges.

• Indicate the service request has been responded to or resolved and automatically fill in the date and time in the Responded On or Resolved On fields.

• Indicate a service request is on hold.

  This is important if you are implementing automatic work distribution where agents click the Next Work or Get New Work buttons to work on the most urgent service request. When an agent sets a service request to an on-hold status, the application ignores the service request when determining the highest priority service request. See Implementing Work Assignment and Distribution .

• Indicate a service request requires approval or an electronic signature.

  Extra setups are required, including the creation of special intermediate statuses the service request is set to while it is waiting for action. For details, see Electronic Approvals and Records.

• Alert an agent that a customer has replied to an e-mail sent regarding a service

  Integration with the Oracle Email Center makes it possible for agents to send e-mails to customers in the context of the service request. The application stores the e-mails and any customer replies in the service request history. You can set up a special status (for example, “Email Received”) that alerts agents that a new reply has arrived in a service request. For details, see Enabling Oracle Email Center.

Service Request Status Groups and Status Transitions

Status groups make it possible for you to specify:

• Which statuses can be used for which problem

• Permissible status transitions

• Different behavior for different classes of users

Statuses for Specific Problems

By grouping your statuses in status groups and mapping them to different service request types, you can specify which service request statuses are going to be available for what customer problem.

For example, “Invoice Corrected” makes sense as a status of a service request for a billing question and “Repaired” as a status for inhouse equipment repairs, but not vice versa.

Permissible Status Transitions

Status groups also make it possible for you to specify the permissible status transition rules for each status in the group (which statuses can be set to which).

You specify the initial status of the service request when agents or customers create it and the transition rules that determine what statuses agents or customers can choose for a service request of a given status.

For example, all new service requests get the initial status of “New”, but you do not want to permit agents to reset a service request back to “New” after it has already been worked on. Or you may not want to permit agents to turn a “Closed” service request back to “Open” because the work has already been completed.

Note: The status transition rules only govern what statuses users can select, they do not determine whether the information in the service request can be updated or not. You determine whether users can modify information when you set up the statuses themselves.

Different Behavior for Different Users

By creating multiple status groups with different status transition rules and mapping them to different responsibilities, you can reserve certain actions only for designated users.

For example, supposed you want to permit only agent supervisors to close service requests of type Refund. In this case you:

1. Create a status group for the agents that does not permit a transition to the closed status.

2. Create a status group for the supervisors that permits the transition to closed.

3. Map the agent status group to the agent responsibility and the service request type Refund.

4. Map the supervisor status group to the supervisor responsibility and the service request type Refund.

See About Mapping Status Groups to Service Request Types and Responsibilities.

Service Request Types

Agents use service request types to categorize the service request.

If you have implemented Oracle iSupport, then customers themselves can also use service request types to categorize their problems when they create a service request on the Web.

Examples of service request types include:

• Request for Information

• Customer Complaint

• Billing Issue

• Installation Request

• Preventive Maintenance Visit

• Return

• Depot Repair

You can set up service request types to:

• Channel different types of customer problems and inquiries to different groups in your organization

  This is accomplished by associating service request types with different responsibilities. For example, you can restrict only accountants to viewing and updating billing service requests and service organizations to restrict access to Installation Requests to the field service organization.

• Provide data security

  Responsibility to service request type mappings provide data security not just for the service request information itself, but also for all related information including service request tasks, notes, and interaction history.

  Agents that are barred from using a service request type cannot view or modify any service-request-related information.

• Restrict agents to using appropriate problem and resolution codes

  Problem codes and resolution codes provide agents with a quick and consistent way of classifying customer problems and resolutions. You can specify which codes map service request types to problem codes and resolution codes to restrict selection to those appropriate to the problem.

• Automatically create tasks when a service request is created

  You can use service request types along with Problem Codes, Items, and Item Categories to generate tasks that need to be performed to resolve the customer problem. You can then have agents or dispatchers assign these tasks to the engineers who will do the work.

• Capture additional information about a customer problem

  You can set up service request types to capture additional information you may need to resolve the customer problem.

  For example, a government agency receiving a call about an abandoned vehicle must capture the make, model, color, and the license plate number so the towing service knows which vehicle to tow away and what tow truck to send to do the job.

  Based on the information entered, the application can automatically create different tasks and check if the new service request is a duplicate.

  The application provides two different and incompatible methods of capturing additional service request information. Which is appropriate depends on the application module you are setting up:

  • If you are using the Contact Center (Oracle Forms) to capture the additional information use the method described inCapturing Additional Service Request Attributes in the Contact Center.

  • For all other modules, including case management, use the method described inCapturing Additional Service Request Information with Extensible Attributes.

• Launch Oracle Workflow processes

  Each service request type can be linked to an Oracle Workflow process that can be automatically launched when agents create or update a service request of this type.

• Specify different response and resolution times

  Service request types are mapped to specific business processes. Each business process permits you to specify different response and resolution times either through individual service contracts created in Oracle Service Contracts or through the default service-level agreement (SLA) you set up as part of your service application implementation (See Setting Up Default Response and Resolution Times).

• Enable integration with Oracle Enterprise Asset Management

  You can specify a service request type to display Enterprise Asset Management work orders in service requests.

• Specify type of electronic record you want to generate

  If you are implementing Oracle E-Records to capture electronic records you can set up each service request type to capture either a detailed record or an abbreviated record. See Electronic Approvals and Records.

About Mapping Status Groups to Service Request Types and Responsibilities

After you set up status groups, you must specify where they are to be used by mapping them to service request types.

You can do this in one of two ways:

• If all users of that service request type are going to be using the same status group, then you can map the service request group directly to the service request type on the Service Request Type window. (See Setting Up Service Request Types.)

• To specify different status groups for different classes of users, you must map the status groups to a combination of the service request type and the responsibility. This is accomplished using the Service Responsibility Setup page (Setup, Mapping, Responsibility Mapping). See Mapping Responsibilities to Service Request Types and Status Groups.

About Final Statuses Aborting Existing Oracle Workflow Processes

You can set up a service request to automatically launch a workflow whenever an agent creates or updates it. Because each update launches a new instance of the workflow, each service request can have multiple instances of the workflow running at the same time. (For details about associating workflows to service request types, see Setting Up Service Request Types. )

If a workflow is running and an agent sets the service request to a status you flag as Final, then the application takes one of two possible actions:

• Warns the agent with a message that an instance of the workflow is running and permits the agent to terminate the workflow by clicking a button in the message text.

• Aborts any instances of the workflow automatically without warning the agent.

To abort the workflows automatically without the warning messages, you must select the Abort Workflow on Final Status without Warning check box in the Service Request Type window. If you leave this check box unselected, then agents always receive a warning.

Service Request Type Categories for Customers Using Oracle iSupport

You can make it easier for customers logging into their Oracle iSupport portal to select the correct service request type by classifying service request types into categories. For example, by creating different categories for product problems and for order problems you shorten the lists of service request types a customer or agent must choose from and increase accurate classification of a problem.

You can upload images customers can use as visual cues to identify the categories on their screen. A printer icon may represent the printer service request type category and a currency symbol the invoice category, for example.

Any service request types you do not map to a category appear for Oracle iSupport users under the heading Other.

If you restrict access to service request types by mapping them to Responsibilities, the category will appear as long as the Responsibility has access to at least one of the service request types in the category.

Setting Up Service Request Statuses

Use this procedure to set up service request statuses. The status of a service request tracks the status of a customer problem from the initial customer contact to resolution and controls what kind of information in the service request can be updated. For details, see Service Request Statuses.

To set up a service request status

1. Under the Service responsibility, navigate to Setup, Definitions, Service Request Statuses.

   The Service Request Statuses window appears.

   

2. Enter a name in the Status field. The text you enter here is what is displayed in the Status List of Values (LOV) in the Service Request window.

3. By selecting the Responded check box, you can set a status to automatically fill in the date and time in the Responded On field of the service request. The date and time reflect the time the agent sets the service request to this status.

4. By selecting the Resolved check box, you can set a status to automatically default the date and time in the Resolved On field of the service request if the agent has not done so manually. The date and time reflect the time the agent sets the service request to this status.

5. Select the Final check box if you want the application to:

   • Enter the date in the Closed field of a service request set to this status.

     The Closed field appears in the Service Request window header.

   • Terminate any instances of the workflow you have associated with the service request of that type in the Service Request Type window. For more information see About Final Statuses Aborting Existing Oracle Workflow Processes.

6. To use a status as the initial status of a service request, select the Initial check box. You may wish different service requests types to have a different initial statuses. For example, you may wish to designate a service request created by a customer using Oracle iSupport as “Opened by customer” and one opened by service agent in the Service Request window as “New”.

   Note: You cannot designate as initial any of the triggering or intermediate statuses used for enabling e-record and e-signature capture.

7. If you are using automatic work distribution to deliver the next service requests to an agent, then you may wish to designate a status as on hold by selecting the On Hold check box. An on-hold status indicates that work on the service request is temporarily suspended because an agent is waiting for more information from the customer or for spare parts to become available, for example.

   Automatic work distribution permits agents to request the next most urgent piece of work from the Universal Work Queue by clicking the Next Work button.

   Placing a service request on hold excludes the service request from the pool of work evaluated by the application when the agent requests the next highest priority work item.

   Without an on-hold status, the application will deliver the same service request over and over again if it happens to be the item with the highest priority.

   For more information, see Implementing Work Assignment and Distribution.

8. Select the Include in Duplicate Checking check box to include the status in the Status list on the Automatic Status Updates Rules page. This status can be used for identifying duplicate service requests.

9. Using the Classification drop-down list, you can classify each status as:

   • Waiting on Customer

   • Waiting on Support

   • Waiting on Internal Group

   • Waiting on External Group

     HTML-based service and case management modules display this classification on the Agent Dashboard for every service request in agent queues (Waiting On field). The application also uses the classifications to calculate agent and group performance displayed in the Key Performance Indicators region. See Understanding and Setting Up Key Performance Indicators.

10. Optionally, enter Start and End dates for the status to restrict status use. By specifying a future start date you can delay the use of a new status. You can inactivate a status by setting an end date.

11. A check mark in the Predefined check box indicates the status was seeded by Oracle. You cannot delete a predefined status, but you can modify its wording or remove it from use by entering an end date.

    Oracle includes the following predefined statuses:

    • Cancelled by User

    • Clear

    • Closed

    • Open

    • Planned

    • Waiting

12. For the Oracle Forms-based Service Request window, you can use the Text Color field to assign a color to the text the support agent sees in the Status field of the service request.

13. To restrict users from updating certain types of information, select one or more of the Service Request Status Restriction check boxes:

    • Disallow Request Update: Prevents users from updating the service request. Selecting this check box does not affect Customer Support, Service Desk, and Case Management except when the prohibition is required by an electronic approvals process (See Electronic Approvals and Records.)

    • Disallow Task Update: Prevents users from updating tasks related to the service request in the Service Request window. (Tasks can still be modified from within the Oracle Task user interface, however.)

    • Disallow Charge Update: Prevents users from updating charges.

    • Disallow Owner Update: Prevents users from updating service request ownership.

    • Disallow Product Update: Prevents users from updating product information.

    • Disallow Charge: Prevents users from entering charges information.

      Note: The Intermediate Status and Rejection Status fields as well as the Pending Approval check box are used only for setting up approvals and electronic signatures using Oracle E-Records. See Electronic Approvals and Records.

14. Save your changes.

15. Repeat the above procedure for all the statuses you need for all of your service request types.

    You are now ready to group the statuses you have created into Status Groups specific to each service request type according to the procedure outlined in Setting Up Status Groups.

Setting Up Status Groups

You can use status groups to specify for each service request type:

• Which statuses can be used for service requests of that type

• The initial status for a service request

• The permissible status transition rules for each status in the group.

For an overview of status groups and their function see About Statuses, Status Groups, and Service Request Types.

Prerequisites

Before creating status groups, you must create the statuses by following the procedure outlined in Setting Up Service Request Statuses.

To set up status groups:

Under the Service responsibility, navigate to Setup, Rules, Status Groups and Transitions.

The Status Group Summary page lists status groups that have already been set up and provides the launching point for updating, copying, and creating new status groups and their transitions.

Notes:

• You can either create a new group from scratch by clicking Update or copy and modify an existing group by clicking Duplicate (the icon showing two sheets of paper).

• The Status Group Definition you use to create status groups is divided into four regions.

  Note: You must scroll down to see all of the regions.

• Use the first two regions on the page to specify the status group name and add the statuses.

  

  The bottom two regions is where you specify the default initial status for a service request type using this status group, and define the permissible status transitions.

  

• You must add all of the statuses first and click Apply to save your work before selecting the default initial status or entering transition rules.

• You can only select a status as an initial status if it has been set up as an initial status in the Service Request Statuses window.

  Note: If you are automatically closing duplicate service requests using the status update feature offered by service request relationships, then you must include the seeded status of “Waiting”, “Clear”, and “Closed” and the status group transition rules must permit all statuses to transition to the status of “Closed”. See Service Request Linking to Specify Duplication and Other Relationships.

Setting Up Service Request Types

Use this procedure to set up service request types used by agents and customers themselves to categorize service requests. For more information about service request types, see Service Request Types.

Prerequisites:

• You must create the object you want to link to the service request type first. For example, to link a service request type to a status group, you must create the status group first.

• If you create service requests for Oracle Installed Base item instances, then you must create business processes the application uses to lookup customer entitlements in service contracts.

  You must create at least one dummy business process even if you do not use Oracle Service Contracts. This is because the application requires a business process to look up the default service agreement whenever an agent enters an Oracle Installed Base instance in the service request.

To create a service request type

1. Under the Service responsibility, navigate to Setup, Definitions, Service Request Type.

   The Service Request Types window appears.

   

2. Enter a name of the service request type in the Type field. This is the text agents see in the Type list of values in the Service Request window.

3. If the service request type is going to be used for creating service requests for Oracle Installed Base item instances (products the customer owns), then select a business process from the Business Process list of values. The business process supplies the response and resolution times specified in Oracle Service Contracts or in the default service level agreement.

4. Optionally, enter Start and End dates. By specifying a future start date you can delay the use of a new service request type. You can inactivate a type by setting an end date.

5. Enter a description for the service request type.

6. If you have set up a status group for this service request type, then select it using the Status Group Name list of values (LOV).

   Note: To specify different behaviors for different users by using multiple status groups, use the mapping done in a separate setup. See About Mapping Status Groups to Service Request Types and Responsibilities. This alternate way of mapping status groups to service request types and responsibilities supersedes the mapping you make here.

7. To enable this service request type for use with Oracle Enterprise Asset Management, select the Asset Maintenance check box.

8. To enable the service request type for Oracle Complex Maintenance, Repair, and Overhaul, select the Complex Maintenance check box.

9. If this service request type is being used in Oracle iSupport, then you can display an image to help customers select the correct type during request creation.

   For example, a computer hardware company may present users with an icon of a printer for the Printer Trouble and an icon of a monitor for Monitor Trouble. To display the image, upload the image to APPL_TOP in the OA_MEDIA directory and enter the name in the Image File Name field.

10. Optionally, associate an Oracle Workflow process (of item type SRVEREQ) using the Workflow list of values (LOV). This can be a process you have created or one that is included with your application.

    Your application includes three seeded workflows which are a part of the SRVEREQ item type and appear in the LOV (See About Oracle Workflow Processes Included with Your Application.):

    • Duplicate Check and Autotask Create for iSupport and Email Center Created SR

      Checks for potential duplicates when service requests are created in Oracle iSupport and Oracle Email Center.

    • Call Support Process

      Use this workflow only under special circumstances if you are using Oracle TeleService.

    • Customer Support Event Process

      Do not associate this workflow here. It is used by Oracle TeleService internally.

11. If you have associated a workflow, then select one or both of the related check boxes:

    • Auto Launch Workflow: Launches workflow automatically when a service request is created and updated.

    • Abort Workflow on Final Status without Warning: Selecting this check box aborts without warning any instances of the workflow you have associated with this service request type whenever an agent sets that service request's status to a status that is flagged as Final in the Service Request Statuses window. (See Setting Up Service Request Statuses.)

      If you do not select this check box, then the agent always receives a warning if a workflow is about to be terminated and has a chance to cancel the abort.

12. To make this service request type available to customers who are creating service requests on the Web using Oracle iSupport, select the Web Entry check box.

13. If you are implementing Oracle E-Records to capture electronic records, you can have the application capture a detailed e-record by selecting the Detail ERES Record check box. By default, the application generates an abbreviated record. See Electronic Approvals and Records.

14. Click Save on the toolbar.

15. If you have selected the Auto Launch Workflow check box for any service request type, then you must set the set the system profile Service: Auto Launch Workflow to Yes.

Grouping Service Request Types into Categories for Oracle iSupport

You can create categories of service request types and include icons to make it easier for customers using Oracle iSupport to select the correct service request type for their problem. For more information, see Service Request Type Categories for Oracle iSupport.

To create a category and map it to service request types

1. Under the iSupport Administrator responsibility, navigate to Request Type Administration, Request Type Categories.

2. From the Request Type Categories Page, you can create new categories or modify existing ones. To create a category:

   1. Click Create on the Request Type Categories Page.

      The Create Request Type Category Page appears.

      

   2. The category name, which displays in the customer's web portal page, is the only field required.

   3. If you would like to specify a specific order in which you wish the categories to appear in the list of values, enter a sequence number in the Display Order field.

   4. If the category you are creating is being used in Oracle iSupport, then you can display an image to help customers identify the category visually. To display the image, upload the image to APPL_TOP in the OA_MEDIA directory and enter the name in the Image File Name field. This image is not displayed in any of the Oracle TeleService modules.

   5. Click Apply.

      You are returned to the Request Type Categories page which displays the new category.

3. Click the Mapping icon.

   The Type Category Mappings page Appears.

   

4. Click Add Request Types.

5. On the search page, you can select multiple service request types to map at the same time, so you may want to display them all by using the "%" sign in search field.

6. Click Select to return to the Type Category Mapping page.

7. You can specify an order for the way the service request types appear in the list of values by entering numbers in the Display Order field.

8. Click Apply to save your work.

Setting Up Service Request Severities

You define service request severities to assist in setting service request priority. The service request severity reflects the support agent's perception of the reported service request. Service request severity is a mandatory field in the service request.

Following are some examples of service request severities:

• High

• Medium

• Low

To set up a service request severity

1. Under the Service responsibility, navigate to Setup, Definitions, Service Request Severities.

   The Service Request Severities window appears.

   

2. Enter a severity name in the Severity field in the header of the Service Request window.

3. Enter a numerical value in the Importance Level field. The importance level indicates the importance of this particular severity with respect to other defined severities.

   If you are implementing automatic workload balancing for automatic work assignment, then you must group the severities into four categories: 1 through 4, where 1 are the severities of the highest priority and 4 are those with the least priority. See Implementing Service Request and Task Assignment.

4. Enter an optional description of the severity.

5. If you are enabling automated work distribution, where agents assign work to themselves in the Universal Work Queue using the Get Work and Next Work buttons, then you must use the Priority Code list of values (LOV) to select one of the four priorities: critical, high, medium, or low.

   The application uses the priority you enter here together with the service request due date to calculate the most urgent work item to assign to agents when they click the Get Work and Next Work buttons.

   The Priority Code maps onto the Global Priority Levels in the Universal Work Queue.

   For more information on automatic assignment topics, see Implementing Service Request and Task Assignment.

6. Optionally, enter Start and End dates to control the use of severities. By specifying a future start date you can delay the use of a new severity. You can inactivate a severity by setting an end date.

7. Optionally, select a text color in the Text Color field. The severity will be shown in this color on the Service Request window (Oracle Forms only).

8. If a descriptive flexfield has been enabled for this form, select the appropriate values.

9. Save.

10. Set up the severity you want to use as a default by setting the system profile Service: Default Service Request Severity at the site level. This setting is required if you are creating service requests using the actions architecture on the Contact Center Install Base tab.

Setting Up Service Request Urgencies

You define service request urgencies to provide an indicator of the customer's perception of the urgency of the service request. Urgency is an optional field in service requests.

Following are some examples of service request urgencies:

• Inoperable

• Partially Operable

• Not Urgent

To set up service request urgencies

1. Under the Service responsibility, navigate to Setup, Definitions, Service Request Urgencies.

   The Service Request Urgencies window appears.

   

2. Enter an urgency name in the Urgency field. The urgency name appears in the Urgency list of values in the service request.

3. Enter a numerical value in the Importance Level field. The importance level indicates the importance of this particular urgency with respect to other defined urgencies. You can have multiple urgencies with the same importance level.

4. Optionally, enter a description and Start and End dates (to control the availability of urgencies).

5. For Oracle Form's based interfaces you can select a text color using the Text Color field list of values.

6. If a descriptive flexfield has been enabled for this form, select the appropriate values.

7. Save your service request urgency.

Setting Up Default Response and Resolution Times

Use this procedure to set up default service request response and resolution times by business process and service request severity.

Service request types are mapped to specific business processes. Each business process permits you to specify different response and resolution times either through individual service contracts created in Oracle Service Contracts or through the default service-level agreement (SLA) you set up as part of your service application implementation.

When agents create a service request not covered by a contract, the application uses the default resolution and response times for the business process to calculate the deadlines for responding and resolving the service request and automatically defaults the Respond By and Resolve By fields.

The SLA is calculated based on the value specified in the Service: Date to Calculate SLA profile option, and either the reported date or the date on which the service request is created.

If an agent later selects a contract for the service request or enters an installed base item covered by a contract, these default times get overwritten by those specified in the contract.

To set up default response and resolution times:

1. Set up an Oracle Service Contract coverage template with the reaction times and resolution times for each business process and service request severity as described in the Oracle Service Contracts User Guide.

   Note: The template you create is for defaulting reaction times and resolution times only. It cannot be used to default pricing information such as discounts and labor rates.

2. Navigate to Others, Profile System Values and set the system profile option Service: Default Coverage for SLA to the name of the template you have created.

Setting Up Task Types and Priorities for Service Request Tasks

This step is required to use service request tasks. The procedure described here describes only service-request related requirements, please see Oracle Common Application Calendar Implementation Guide (in previous releases known as the Oracle Common Application Components Implementation Guide) for the full explanation of task setups.

To set up task types and priorities

1. Under the Service responsibility, navigate to the Task Type Setup window (Setup, Task Management, Task Types).

2. All existing task types are displayed. To make task types available for service requests:

   1. Click Map Types.

      The Mapping Objects window appears.

   2. For each task type, use the lists of values to enter Service Request in the Source Object field and the task type in the Task type field.

   3. Save your work.

3. Navigate to Setup, Task Management, Task Priority.

   The Task Priority window appears displaying existing task priorities.

4. To make task priorities available for service request tasks:

   1. Click Map Priority.

      The Mapping Objects window appears.

   2. For each task type, use the lists of values to enter Service Request in the Source Object field and the task priority in the Task Priority field.

   3. Save your work.

5. For each task priority you want to use with service request tasks:

6. Associate the source Service Request to the task priority.

7. Save your work.

Setting Up New Note Types for Service Requests and Tasks

You can use note types to classify the information your organization keeps on service request, tasks, and customers. Use this procedure as a guideline for setting up new note types. For additional details, see the Setting Up Notes section of the Oracle Common Application Calendar Implementation Guide.

The application includes the following seeded note types for use with service requests:

• Action

• Cause

• Changes

• Fact

• Objective

• Problem Description

• Resolution Description

• Symptom

You can create additional note types for use with service requests, with tasks and with customers.

To set up a new note types

1. Under the Service responsibility, navigate to Setup, Notes, Note Types and create the note type. The codes for seeded service note types start with “CS_”, but you can use any unique code you want.

2. Navigate to Setup, Notes, Source and Note Type Mapping and use the Mapping Objects window to map the note type to the object where you are going to be using it. The following table lists the objects you can map and where the mapping displays:

   Source Object	Where the Note Type appears
   Party	Contact Center
   Service Request	Service requests in all Oracle TeleService modules
   Task Manager	Tasks in all modules. Oracle iSupport does not expose task notes.
   Public Service Requests	Service requests in Oracle iSupport

   To have notes created with your note type appear in multiple objects, you must map the note type multiple times. For example, for a note to appear in both Oracle TeleService and on the Oracle iSupport web portal customers user to access service request information, you must map its note type to both Service Request and Public Service Request.

   The application does not use entries in the Application field for the mapping.

3. To use the note type for knowledge searches, you must map the note type to a Knowledge Management statement type. For more information see the “Integration" chapter of the Oracle Knowledge Management Implementation and Administration Guide.

Indexing Note and Summary Text for Searches

You must run the Service Request Synchronize Index concurrent program to make it possible for agents to search for text in the summary and note fields of service requests. By setting this concurrent program to frequently, you can ensure that agents can search recently-created service requests.

To run the Service Request Synchronize Index concurrent program

1. Under the System Administrator Responsibility, navigate to Security, Responsibility, Request.

2. Query on the Group "Support Reports".

3. Add the Service Request Synchronize Index concurrent program to the list.

4. Save.

Enabling Integration with Oracle Enterprise Asset Management

Agents can create service requests for internal assets maintained in Oracle Enterprise Asset Management using either the Service Request window (Oracle Forms) or the Service Request update page in Customer Support. The Contact Center (Oracle Forms) does not support the creation of these types of service requests.

Agents can view work orders created in Oracle Enterprise Asset Management related to the service request, but the life cycle of the work order is not in any way tied to the service request life cycle. Closing work orders tied to a service request does not close the service request and vice-versa.

To enable the Oracle Enterprise Asset Maintenance integration

1. Set up Oracle Enterprise Asset Management according to the procedures described in the Oracle Enterprise Asset Management User's Guide.

2. Set up service request types with the Asset Maintenance check box selected. See Setting Up Service Request Types.

3. If you are using the Service Request window (Oracle TeleService), then use the Oracle Forms Folder tool to add the following two fields to the Service Request window header:

   • Inventory Org

   • Maintenance Org

   These fields are enabled for entry only for asset maintenance service requests.

4. Set the default maintenance organization in the system profile: Service: Default Maintenance Organization.

   If you have set the system profile Service: Validation Inventory Organization to the inventory master organization (the recommended setting), the list of values includes all of the subordinate maintenance organizations.

   If Service: Validation Inventory Organization is set to an inventory organization subordinate to the master inventory organization, then the list of values of the maintenance organizations is restricted to those maintenance organization(s) for that subordinate organization.

About Oracle Workflow Processes Included with Your Application

Your application includes four Oracle Workflow processes:

• Call Support Process

  This process notifies the individual service request owner each and every time a service request of this type is created or updated. The owner can set the status of the service request to Closed by clicking the Resolved button on the notification.

  This process has been superseded by a more flexible notifications process which implementers can use to selectively notify both service request owners and customer contacts of service related events. (See Setting Up Notifications). You will want to associate this workflow to a type only if the resolution functionality is important to you.

  If you associate this workflow with a service request type and also use the new notifications feature, owners may receive two notices for the same event.

• Customer Support Event Process

  This process notifies service request owners and contacts of different events related to service requests and is used by the notifications feature of Oracle TeleService. See Setting Up Notifications.

• Duplicate Check and Autotask Create for iSupport and Email Center Created SR

  This Oracle Workflow process checks for potential duplicate service requests when customers create service requests using Oracle iSupport or agents create service requests from within Oracle Email Center. If the process finds a potential duplicate, it notifies the service request owner.

  When customers create a service request of a type set up with extended attributes, the program instead alerts the individual you specify in the Alert Recipient field of the Service Request Attributes Configuration window. You must be sure to select the Autolaunch check box to enable this process.

• E-mail Notification Generic Process

  This sample process initiates when a task of type “Email Follow-up” is created for service requests that have been set up with additional Contact Center attributes. (For information about the workflow process, seeSample Generic E-mail Notification Workflow. For details about capturing the attributes, seeCapturing Additional Service Request Attributes in the Contact Center.)

  The process gets the task attribute details (such as requester, approver, or subject) from the values you enter on the Optional tab of the Task Type: Attribute Configuration window and sets a due date for the approver to acknowledge the e-mail notification.

  The due date is set based on the service request creation date and the number of days you enter in the Offset for Due Date attribute. An e-mail is sent to the Approver with the text entered in the Subject, Message Header, Message Body, and Message Footer attribute. If the approver does not acknowledge the message by the end of the due date, the process sends a reminder notification. If the approver acknowledges any of the notifications (the original or a reminder), the workflow terminates. Otherwise, after sending the maximum number of reminders specified in the Email Reminder Counter attribute, the workflow fails and terminates.

  When the process completes successfully, the workflow updates the task status to Completed. If the processing fails, the process sets the task status to Cancelled. You can modify these statuses by setting the following system profiles:

  • CUG_TASK_FAILED_STATUS

  • CUG_TASK_SUCCESS_STATUS

Setting Up the List of Values for the Language Field

Use this procedure to set up the list of values (LOV) for the Language field in the Service Request. Agents can use this field to indicate a customer's preferred language for a specific service request.

Note: The language preference agents enter using this LOV remain specific only to individual service requests. The preference is not stored in the customer record itself. This means that selecting a language preference in a service request does not modify the customer's overall language preference which is entered in the Preferred Language field in the Party Information tab of the Contact Center.

To set up the list of values for Preferred languages

1. Under the Service responsibility, navigate to Setup, Definitions, Preferred Languages.

   The Oracle Service: Service Request Preferred Language window appears.

   

2. Use the Language Code LOV to select the languages you wish to add to the list of values in the Preferred Language field.

   The language name the agent will see in the LOV appears in the Description field.

3. Optionally, enter dates to limit the availability of your entry.

4. Click Save.

Obtaining a List of Valid System Profiles and Lookups

You can obtain a list of Oracle TeleService system profiles and lookups for this release by logging in under the Functional Administrator responsibility, selecting the Core Services tab and either the Profile Categories or the Lookups subtab.

Note: List of system profiles and lookups you obtain from the Oracle Forms-based user interface may include legacy data.

Both system profiles and lookups are categorized by application. The two relevant applications for Oracle TeleService are:

• Service

  For all the service request-related features.

• Customer Care

  For all the customer information and Contact Center-related system profiles.

The system profiles are also categorized by the function they serve. For example, the Service Work Management category under the Service application includes system profiles you need for work assignment and distribution.

A category may not include all the system profiles that you need to set up a feature, however. This is because the categories apply only to system profiles owned by Oracle TeleService. For example, for work management, you must set up system profiles from a number of foundation modules, including the Universal Work Queue. You must check with the appropriate procedures in this guide to find all the relevant system profiles for any feature.

For detailed information on how to use the features of the administrator interface, see the Oracle Applications System Administrator's Guide - Maintenance guide.