Service requests

In Pega Customer Service™, a microjourney is a small part of the customer journey focused on accomplishing a specific goal; for example, a customer wants to change their address. Service requests represent the work that takes place during an interaction with a customer. Customers can complete Service requests by using a Self-service Portal, a chatbot, or speaking with customer service representative (CSR) in a contact center. Service requests are also known as Service Cases or Case Types.

In a Customer Service application such as Customer Service for Financial Services application built with Pega GenAI Blueprint™, the Blueprint identifies microjourneys mapping to Service requests such as Add Account Participant, Change APR, Close Account and so on. The Blueprint defines the microjourneys as workflows using Pega Case Types.

Service requests identified by Blueprint

In the next step, the Blueprint creates Case Lifecycle and Case Data Model for each of the Service requests.

Case Lifecycle

The Case Lifecycle consists of Primary Stages and Alternate Stages needed for accomplishing the task of the Service request.

In Blueprint

Consider one of the Service requests, Add Account Participant identified in the previous step. It consists of the following Stages.

Primary Stages:

Collect Participant Details
Verify and Approve Addition
Get Participant Consent
Resolve and Notify

Alternate Stages:

Escalate suspicious participant

The stages in Add Account participant service request in Blueprint

In Pega platform

When you import the Customer Service application, Customer Service for Financial Services application built with Blueprint into Pega platform, the system adds a few more Primary and Alternate Stages to the Case Lifecycle.

When you open the same Service request Add Account Participant in the Pega Infinity™ instance, you can see the following Stages:

Primary Stages:

Initiate
Identify
Collect Participant Details
Verify and Approve Addition
Get Participant Consent
Resolve and Notify

Secondary Stages:

Escalate suspicious participant
Approval rejection
Cancel
Ineligible
Not verified

The stages in Add Account participant service request in Pega platform

When the system imports the Blueprint and builds the application, it adds Initiate and Identify Stages in the Primary Stages and it adds Approval rejection, Cancel, Ineligible, Not verified Stages to the Alternate Stages. Also, it adds the Processes Save and Update any systems and Send resolution notification within the Resolve and Notify Stage

The purpose of adding Initiate Stage is to pass the Interaction Case details such as contact details, account details, channel information and so on to the Service request Case.

The Identify Stage includes all the commonly used Service request functionalities such as identifying customer, service account, asset, eligibility to run a Case and to allow duplicate search. You can manage these functionalities by modifying the Case processing options of the Service request.

The Process Save and Update any systems in the Resolve and Notify Stage helps in committing the Service request case data into the system of records. This can be configured based on the storage systems set up for the application.

The Process Send resolution notification in the Resolve and Notify Stage helps in sending the notification to the concerned stakeholders and can be set up as required.

Case processing options for Add Account Participant service request

The Service request moves into the Approval rejection Stage in the Alternate Stages when the approval in the Verify and Approve Addition Stage is rejected during the Service request Case Lifecycle.

The Service request moves into the Cancel Stage when a Case is cancelled before resolving in the happy path of the Service request.

The Service request moves into the Ineligible stage when the eligibility process check in the Identify Stage fails.

The Service request moves into the Not verified Stage when the customer fails the verification process check in the Identify Stage.

Case Data Model

The Case Data Model defines individual fields of different types that are required to resolve the service request. In the Blueprint's Data & Integrations section, the Blueprint identifies the Data Objects that are relevant to the Customer Service application. The system integrates the Case Data Model fields to the Data Objects of the Customer Service application. The Case Data Model fields reference to the corresponding Data Objects.