Interactions vs Service cases

From PegaWiki
Interactions vs Service Cases / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Interactions vs Service cases

Description The differences between interactions and service cases and advice on how to handle them
Version as of 8.5
Application Pega Customer Service
Capability/Industry Area Interaction management

The toughest decisions when using a Pega Customer Service (PCS) implementation are sometimes easy to make but have implications for the future evolution of your implementation. Will I be able to report on data cleanly, will customer service reps (CSRs) understand how the solution behaves? Do the decisions I make fundamentally alter the way the application works, and will those decisions have an impact on the updatability of my application? In this design pattern, we outline some of the fundamental differences between an Interaction and a Service Case, explain why they are different, and provide some best practices to follow when it comes to how data is collected and used.

For example, a customer new to Pega Customer Service comes to one of their Sprint 0 planning sessions, hears about Interactions and Service cases, and without having a fuller understanding of the roles of each object in the application, decides to remove or combine one or the other together. This design pattern goes beyond curated documentation, which explains what these concepts are and how they are used, and explains why the separate responsibilities of each object need to be preserved.

Before you begin

If you are new to Pega Customer Service, watch the foundational modules on Pega Academy covering Pega Customer Service to understand some of the guiding principles. Working with the sample application and data that comes with Pega Customer Service will also help you understand some of the basic concepts that separate Interactions from Service cases.

The relationship between interactions 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 different 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 well 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, long after the initial chat, phone call or email interaction has ended. A more accurate way of looking at interactions and service cases is that their relationship can be one to many, in that one of the usage patterns that we anticipate and look to support through the use of PCS is that a single engagement can lead to multiple outcomes. A lost or stolen card process might be complimented 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, a few design principles should be considered, particularly if you are considering changes to an interaction object. These are good rules of thumb to help ensure that you don’t stray too far from the underlying architecture of the Pega Customer Service application, and introduce tech debt that might be difficult or expensive to unravel in the future.

Common questions about interactions and service cases

Lets address some of the questions we typically hear on this topic, as well as our recommendations.

What do I use the interaction record for?

The primary use is as a point of engagement, to capture the Q&A 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, and never look to instrument service cases to capture that information instead.

Another key design principle is that you should never look to 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 are attempting to add a process there, you are stepping 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 allowing you to a add process to parts of the interaction record, we would recommend that you 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 wouldn’t try to add a process to the interaction record, for update purposes, don’t try to 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 version 8.5 to adhere to your guardrails for case design. If there are fundamental patterns that you want to add that aren’t in the case template, there could well be a good reason for their exclusion.

Can I combine the two? The Interaction/service case model doesn’t work for my business, which would only have one service case record.

This is a recurring but not regular topic of discussion – it often comes up 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, which is occasionally used as an argument for merging the two objects together as part of an implementation. Again, our recommendation is to keep them separate for the reasons outlined above. An additional observation to note is 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%!

Always remember, if removing repetitive manual effort is the goal, it's easy to automatically suggest a service case and have it open automatically for every interaction.


The advice in this design pattern will help you stay within the guardrails for PCS, ensuring that you don't add functionality that may be tough to update later, or data that will be hard to repurpose as your application evolves.