​These topics describe how to configure and extend the Personal Auto Claim Status Inquiry Microjourney™, which is part of the Pega Customer Service™ for Insurance application.

This Microjourney enables customers (policyholders) to receive status updates in their preferred channel of communication and to see the status of their claims.

• Business value

• Personas, channels, and use cases

• Self-service example 
• Data model
• Enabling and extending the Microjourney

• Handling inquiry events without Pega Customer Decision Hub

• FAQ

Business value

Having an auto accident is a stressful time for a customer. This Microjourney reduces the effort that customers need to make to see the status and the next steps of the claim. 

With the Claim Status Inquiry Microjourney™, insurance policyholders can subscribe or unsubscribe to SMS or email notifications about proactive updates to their active claim whenever there is a change in the status of the claim. The microjourney also enables them to view the latest updates from their self-service portal on a mobile or desktop web browser.

The policyholder can update their preferences whenever they like, and upload any new photos related to the claim, even after filing the claim.

Personas, channels, and use cases

The following table shows the personas, channels, and use cases that are pre-configured for this Microjourney.

For information about all the interaction channels that Pega Customer Service supports, see Interaction channels.

Self-service example

Customers can enroll for notifications on status updates at the end of claim filing and can change their preference, at any point of time, along with uploading new images supporting their claim.

The typical flow for this interaction is the customer subscribes to status notifications at the end of the claim filing process by selecting either SMS or Email, both of which are supported by default in the product. Pega Customer Service for Insurance sends outbound notifications to the customer on their preferred channel whenever the status of the claim changes. The customer can visit the self-service portal to view detailed claim status and the next steps of the claim.

The following image is a self-service example: 

1. Customer views more details of the claim, by clicking the View button. The customer enrolls for the claim status notification preference while filing a Personal Auto Claim.
2. Customer manages the notification preference, by clicking the Edit button. For example, change a preferred channel to receive notifications and subscribe/unsubscribe to notifications.
3. Customer can optionally select SMS, Email, or both as their notification preference, and then save the preference.

Data model

Use the Data model page in App Studio to quickly view and understand the relationship between all data objects in the application. You can add, update, and delete data objects without exiting the visual data model.

For information about the Data model page, see Data modeling. 

Enterprise relationship diagram

The following figure shows the entity relationship diagram (ERD) for this Microjourney. For each data object, the ERD shows only the properties that apply to this Microjourney.

Populating data in the Claim Status Inquiry Microjourney

Configure this Microjourney to retrieve required data by modifying the data pages to which the Microjourney refers. For example, customer claims include all claim-related data stored in external data sources. The D_CustomerClaimCases,andD_StatusTrackerdata pages serve as extension points for the configuration, to fetch details from the right source. For more information, see Data pages.

Populate data from an external data source by replacing the data source of a data page. For more information about changing data sources, see Changing the data source of a data page.

Populating self-service Claims filed by customers

The D_CustomerClaimCases data page retrieves a list of claims filed by logged-in customers. Pega Customer Service for Insurance can source this data or can also source the data from an external claims system by using a REST service.

The D_CustomerClaimCases data page takes the following parameters as input:

• Required:ContactIDto fetch claims related to specific contacts.
• Optional:PolicyIDto fetch claims related to a single policy.
• Optional:PolicyTypeto fetch claims related to a specific policy type.

After you modify the source of the data page, the system populates the following fields from the new source: 

• ClaimType: The type of claim. For example, personal auto, whole life, term life, and travel.
• ContactID: The ID of the customer (contact) who filed the claim.
• pxCurrentStageLabel:  The current stage of the claim.
• pyID: ID of the claim to uniquely identify it.

Populating the Timeline view of the claim in self-service

The D_StatusTracker data page retrieves the current status of the claim in context and forms a sequential view of the claim progression based on the pre-defined case stages, to give the customers a holistic view of the events completed and events remaining before their claim is settled.

This data page takes the following parameters as input:

• Required:ClaimID to fetch the stages related to the claim.
• Required:Context to identify the context. For example, claims.

After you modify the source of the data page, the system populates the following fields from the new source: 

StatusTrackerDetails page holds the following data:

• pyDescription: Detailed description of the current status.
• pyStatusValue: The value of the status as it appears in the system.
• pyStatusMessage: Any message to be passed to the customer in the next steps.

Enabling and extending the Microjourney

Extension points make it easier and faster to configure this Microjourney to meet your specific business needs, and easier to upgrade this Microjourney in the future. For more information, see Extension points.

The Personal Auto Claim Status Inquiry Microjourney is designed for common insurance scenarios, and enables the following features:

• Subscribe/unsubscribe to notifications on multiple channels while filing a claim.
• Register claims along with the user’s notification preferences to external claims systems.
• Provide real-time updates on claim status in Pega Customer Service for Insurance from an external claims system.
• Customize notification messages based on the current status of the claim.
• Update notification preferences through the self-service channel.
• Upload additional images supporting the logged claim.

The following sections provide more information about the extension points in the Claim Status Inquiry Microjourney:

Subscribe/unsubscribe to notifications

The Claim Status Inquiry Microjourney starts with the customer subscribing to notifications about status changes in the claim that they are registering, at the end of the claim filing process. The product supports two channels by default (SMS and Email), which can be utilized without any changes. Additionally, if implementation clients intend to add more channels, they can use App Studio and edit the screens as required. They can also use Dev studio and extend these channels by making changes to the following rules:

• InitialSetup_WSS:Flow which governs the claim creation process. The implementation client can completely change the path of how a claim is created, and also change the point at which notification preferences are captured.
• EnableNotification:Section that holds the channels in which the notifications are sent. The implementation client can add more channels, along with the supporting handles that are required to send the notification. For example, when adding WhatsApp as a channel, the corresponding WhatsApp mobile number must be captured.

Register claims in external claims systems

Once the customer provides all the details related to the claim that they are filing, the claim is registered in the external claims system for further processing before settlement, in line with the standard guidelines. When filing the claim, implementation clients also replicate the claim in Pega Customer Service for Insurance with the claim ID, for future reporting purposes. You can extend the following rules to customize the claim creation in the external system:

• D_CreateClaim:This data page persists the claim in the external claims system and is sourced by a connectorClaimFile.
• ClaimFileRequestPOST:Modify thisdata transform to customize the properties passed to the external claims system for processing Apart from any other data the implementation client can capture as part of the claim creation process, this includes the newly added notification preferences.
• ClaimFileResponsePOST:Use this data transform to map the properties sent back by the external claims system after successful claim creation. Typically, this data transform must return the status and ID of the claim that was created. If the external claims system sends in more data, those properties can also be mapped here.

Provide real-time updates on the claim status

When a claim progresses, the implementation clients need to notify the customer based on the customer’s preferred channel, which they specify when creating the claim. To keep the messaging consistent, Pega Customer Service for Insurance sends the correspondences to the customer, instead of the external claims system, which might have a different presentation. The status updates are sent back to Pega Customer Service for Insurance in real-time and are persisted in duplicate/replicated claims. You can customize the following rules to modify this functionality:

• CSInsuranceCases:This is the REST service package that processes any Case-related information in Pega Customer Service for Insurance. You can enhance this service package to support other use cases that can be triggered using REST services.
• Claims:This is the REST service that processes real-time updates to the claim file in the external claims system.
• UpdateClaimDetails: This activity used in the REST service updates the status in Pega Customer Service for Insurance and sends the update notifications to the customers through their preferred channel, which they specify when creating the claim. If the customer wants to use the external claims system for notifications, they can disable this activity.

Customize status messages

Often, customers cannot easily understand claim statuses in external claims systems. Implementation clients can use the following rules to customize these messages based on the status mapping:

DetermineClaimContentPerStatus: Use this decision table to map the status to a meaningful user message.

Update notification preferences

Customers can update their notification preferences using self-service. The following rules help in customizing the experience and persisting their preferences to the external claims system for subsequent notifications:

• EnableNotification: Section that holds the channels in which the notifications must be sent. The implementation client can add more channels, along with supporting handles that are required to send the notification. For example, to add WhatsApp as a channel, the corresponding WhatsApp mobile number must be captured.
• SaveClaimNotificationDetails: Use this Data Transform to persist the updated notification preferences in Pega Customer Service for Insurance. You can also enhance it to pass the details to an external claims system, if required.
• D_SaveClaim: Use this data page to persist the claim data to Pega Customer Service for Insurance. The implementation client can also update the source of this data page to a REST service to persist this in an external system.

Upload additional images

A customer can log in to the self-service portals to upload more images supporting their claim. The default functionality saves these images to Pega Customer Service for Insurance. The implementation client can use the following rules to enhance this functionality:

AttachedDocuments:Section that displays the list of images attached to the claim and allows the customer to add more images.

Handling inquiry events without Pega Customer Decision Hub

This section provides information for capturing the number of customer inquiries related to different entities, such as claims and policies, and creating a deflection report that shows the effectiveness of self-service, proactive or preemptive service.

Present implementation

The present implementation stores all the inquiries as events in Cassandra. For example, when a claim status update is proactively shared with the customer and a positive deflection must be added in the database, an event is created as follows:

This data is used in the deflection report, which helps to identify the number of times a CSR call has been deflected by a proactive service or web self-service.

Implementation without Pega Customer Decision Hub

While storing events in Cassandra database has its own benefits, such as faster access, elastic scalability, and consistency, events can also be stored using a relational database.

Creating inquiry events

Update the @baseclass.CaptureInquiryEvents activity. This activity captures the following parameters:

• Channel – Channel through which the inquiry has been created/deflected.
• ContactId – Customer unique identifier. For example, CONT-1.
• DeflectionType – Holds the type of deflection. For example, positive, negative.
• PolicyType – If the policy line of business is in the context of the inquiry, then pass this optional parameter.
• EventID – The pyID associated with the inquiry.
• EventType – A string that defines the data entity or type of event. For example, claims, policy.
• AdditionalData – This parameter passes any other additional values that are needed to capture the inquiry. All additional parameters need to be passed in the JSON format. In the CaptureInquiryEventsactivity, the values can be deserialized and subsequently used for processing.

Forexample, if events are stored as an instance of PegaCRM-Data-SFA-BusEvents, make the following changes to the CaptureInquiryEvents activity.

Extend the data transform SetEventCreationParams in the required class and map the parameters to the required properties, as in the following figure:

Save the required data, as in the following figure:

Retrieving the inquiries

Extend the D_InquiryDeflectionReport data page to fetch the data from required sources. The following flags are used in the deflection report widget and ensure that these flags are populated as expected:

Display the simulated data in the dashboard widget, as follows:

Extend the Code-Pega-List.SimulateDeflectionReport data transform and ensure that the highlighted properties are fetched as expected, as in the following figure:

Displaying the inquiries in the Inquiry Deflection Report

Extend the ClaimInquiryDeflectionReportWidget section to display data based on business needs, as follows:

FAQ

Can the status of the claim be shown in a web self-service site if Pega Personal Auto Claim First Notice of Loss (FNOL) is not used?

Yes, the status of the claim can be shown without the need to use Pega Personal Auto Claim First Notice of Loss (FNOL) case.