Interaction cases and service cases

The concept of having separate records for the point of engagement (the interaction) and the work performed (the service case), is key to how Pega Customer Service is built.

The relationship between the two concepts can be loosely conceptualized as a parent-child relationship, although service cases can - and in a lot of situations do - have a life cycle that extends beyond the duration of the interaction case. For example, as work moves from the front office to the back office, or in the case of a complex fulfillment request, the service case is active long after the initial chat, phone call or email interaction has ended. The relationship may be better described as one to many, as one customer interaction can lead to multiple outcomes. A lost or stolen card process might be complemented by an update to a customer profile, a statement copy replacement, and so on, all as outcomes of a single engagement with a customer that is captured in an interaction record.

Before you start building out your new application, consider a few design principles, particularly if you want to make changes to an interaction object. Review these common questions to help you maintain the underlying architecture of the Pega Customer Service application and avoid introducing technical debt.

Consider some of the typical questions on this topic, as well as some recommendations.

What do I use the interaction record for?

The primary use is as a point of engagement, to capture the questions and answers associated with finding a resolution to a customer need (the text transcripts from text channels are attached to interaction records), and as a point for capturing the KPIs (key performance indicators) associated with the interaction. You should always track the AHT (average handle time) or NPS (net promoter score) on the Interaction record. Do not use service cases to capture this interaction information.

Another key design principle is that you should never implement a process on the interaction record - keep that for service cases. Limit any data capture to the wrap-up screen, to disposition the interaction only. If you attempt to add a process to the interaction record, you are beyond the boundaries of what the Interaction record is used for and could bump into restrictions (final rules) that prevent you from doing so. Even if there are extension points that allow you to add a process to parts of the interaction record, avoid doing so.

What do I use the service case for?

Getting work done! Any service process that you want to model would be encapsulated in the service case record. Just as you should not add a process to the interaction record, for update purposes, you should not add KPI tracking, interaction transcriptions and so on, into the service case record. Keep to the pattern outlined in the case templates added in Pega Customer Service to adhere to the guardrails for case design. If there are fundamental patterns that you want to add that are not in the case template, there is likely a good reason for their exclusion.

Can I combine the two? The Interaction/service case model does not work for my business, which has only one service case record.

This question may arise when the initial phase of an implementation project focuses on a single primary service case. In this case, the effort for CSRs to select one and only one service case from the Add Task menu in the Interaction Driver is seen (correctly) as repetitive, low-value work. This fact is occasionally used as an argument for merging the interaction and service case objects together as part of an implementation. Again, our recommendation is to keep them separate for the reasons outlined in this topic. Consider that often work that is initiated in an initial request (a phone call, for example), may need to be updated or referenced in a subsequent interaction (an email status enquiry). Having the service cases separate, with their own independent life cycle, certainly makes things easier if your FCR (First contact resolution) rates are not always 100 percent.

If removing repetitive manual effort is the goal, it is easy to automatically suggest a service case and have it open automatically for every interaction.

The advice in this design pattern helps you stay within the guardrails defined for Pega Customer Service. As your application evolves, you want to avoid adding functionality that is difficult to update, or data that is difficult to repurpose.