Creating a Self-service application for Pega Customer Service

From PegaWiki
Creating a Self-Service application for Pega Customer Service / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Creating a Self-service application for Pega Customer Service

Description Best practices for creating self-service apps on Pega Customer Service
Version as of 8.5
Application Customer Service
Capability/Industry Area Self Service Mashup



Pega Customer Service is primarily targeted at contact center agents. Agents have access to a large amount of customer data and the ability to deal with many cases on a customer’s behalf. Exposing some of that data and some of the simpler cases to a customer in a self-service channel can reduce contact center traffic. The two most common ways to expose these assets in self-service are through Mashups and Chatbots. A mashup allows the case UI to be shown directly in a client’s customer-facing website. The customer can then run that selected case just as an agent would. Chatbots allows a case to be exposed to the customer in a conversational way by presenting one question at a time. Chatbots can also make customer data available via canned responses and be exposed in many channels, including Web Chatbot, Facebook Messenger, WhatsApp, Twitter DM, Apple Business Chat, and Interactive Voice Response (IVR).

Pega suggests that any assets that are exposed to an end user are built in a separate self-service application on top of the Customer Service implementation. This architecture provides specialization and security for self-service use. The types of specialization that are available include updating flows and updating views for a Mashup so that a different experience can be presented to the end user. For example, a CSR’s view of a case UI may have some internal fields that are not appropriate to show to the end user. In that case, the view can be updated in the self-service application to remove those fields. The self-service application and it’s associated access group can also be updated with more restrictive roles and privileges, which can be used to limit the type of actions that an end user can take, either intentionally for hacking, or accidentally.

Application stack[edit]

We have defined two separate personas that can use the Customer Service application: the CSR and the customer. The following application stack is a high-level view of the appropriate entry point for each persona:

Application stack

In the figure above, the Acme Customer Service application is the implementation layer that is built on top of Pega Customer Service. This implementation layer contains the cases, data, and all other assets that are required for an Acme CSR to perform their daily tasks. The Acme Self-Service application is a thin layer that is built on Acme Customer Service and contains some additional rulesets to provide the required functionality for Chatbot and Mashup support. This self-service application is typically a copy of the out-of-the-box (OOTB) CS Self-Service application, with the built-on application updated to be "Acme."

Building applications with some of the following best practices allows for maximum reuse of assets, and the best user experience by both CSRs and customers. For more information, see Creating a self-service application on the community.

Best practices[edit]

Acme Customer Service implementation[edit]

  • The Acme implementation application should be the core application in which the majority of the assets are developed.
  • Create case type rules using best practices for Stages and parallel flows for conversational channels.
  • Create Case Flows using Flow Action Assignments and sections.
  • Create Case Flows using conversational shapes or stubs for the Flow.
  • There should only be one CaseType rule for a given case. This ensures that parallel flows have consistent stages and flows across both application layers. It provides for escalation of the case from a customer to CSR. The stubs of parallel flows need to be created in the Acme implementation application to save the CaseType rule. However, a parallel flow can be implemented in the Acme Self-Service application.

Acme Self-Service application[edit]

  • The self-service application should contain the changes required to present the cases to a client’s customer.
  • If the case is exposed by using a Mashup, then the flow, flow action, and section rules may need to be updated in the self-service application.
  • If the case is exposed by using a Chatbot, then the flow's conversational version would be created in the self-service application. All required paragraph rules to support the conversational flows should also be created in this application.
  • The various channel instances that are needed to support Chatbot and other unified messaging channels should also be created in the self-service application.