Customer Service methodolgy for agent interaction and 360 composite data placement

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



Description Best practices for designing a customer service application
Version as of 8.4
Application Customer Service
Capability/Industry Area Customer Composite / 360



When designing a Pega Customer Service application, a cohesive methodology about what, where, and when to display data elements during the customer and agent interaction life cycle is often lacking. This lack of planning often leads to building screens that either mirror the existing system (bad practices and all) or where everything has been placed on the screen with a just-in-case thought process that leads to a wall of data. This article provides a sample methodology to help you make decisions on the need, placement, and level of access to data when designing and building your Customer Service solution.

Terminology[edit]

Visible - Information that is present and visible on the screen without having to click or navigate to it (in the top 10% of all data).

Available - Information that is easily reached, usually within one click:

  • In the middle 20-70% of data.
  • An ability to quickly view the data is required.

Accessible - Information that is reachable often with 2 clicks. This information is two levels down. Items that fit into this category are not always used and are in the bottom 20% of data.

Cognitive load - The mental processing power needed to use a product. If the amount of information that needs to be processed exceeds the user’s ability to process it, the overall performance suffers. For example, when using an application and presented with a wall of data, both the sheer volume of data and potentially the layout and arrangement of that data can cause a high cognitive load.

Evaluation matrix[edit]

The following criteria are a starting point for a standard way of evaluating and deciding on the importance, usage, location, and potential implementation of data elements and corresponding views within your application. Each column shows a criteria and possible values, and the bottom row shows an example.

Information

name

Description Who needs the information: CSR, caller, or both? Is the information

usually needed

more than

once during the interaction?

Average usage Likelihood to change the caller behavior, questions, or perception Likelihood to change the

CSR behavior or

handling of the caller

During the interaction,

when will the information be requested or presented

Suggested

presentation

Suggested

screen order

CSR Yes bottom 20% (rarely used) Unlikely Unlikely First 10 seconds Visible 1st quarter
Caller No middle 20-70% (frequently used) Likely Likely First minute Available 2nd quarter
Both top 10% (almost always used) Very likely Very likely First half of call Accessible 3rd quarter
Last half of call Other
Throughout
Unknown
Examples
Caller Name First and last

name of the caller

CSR Yes 90-100% Likely Unlikely Throughout Available 1st quartile

Evaluation matrix criteria[edit]

Who needs the information: CSR, caller, or both?[edit]

Is the information going to be requested by the caller or the CSR during the interaction? How likely will this request be, and when will the request likely happen? For example, the current balance or available credit is a very likely question that would be asked by a customer in a credit card servicing situation.

Is the information usually needed more than once during the interaction?[edit]

If a piece of information will be referenced often during the interaction, this has high value in always being visible. The customer name or account number are examples of items that would be referenced often by a CSR and should be visible at all times.

Average usage[edit]

Looking at all the interactions that CSRs handle in a given year, what percentage of those will reference a specific data element:

  • Bottom 20% of data elements only come up in very specific servicing scenarios. Information that is in this bottom fifth should be at least one or often two clicks away. This may involve putting the information in a collapsible view or section or on one of the 360 composite tabs that are not displayed by default.
  • Middle 20-70% of data elements make up the bulk of information that is available within an application. The elements are often scenario-based in that they are frequently needed based on different scenarios:
    • A customer servicing application may have hundreds of pieces of information but typically only 10 to 20% of that information is either directly or indirectly referenced during any given servicing interaction.
    • Data that falls into this bracket must have good information hierarchy that leads to it, but this data should not always be visible.
    • Allowing the CSR to make this information visible, either temporarily or permanently, for example, by expanding hidden fields, can help accommodate the situational nature of these data elements.
    • Data elements in this category are usually referenced during an interaction and should have prominent placement on the screen, such as in the top half of the UI or other place of focus.
  • Top 10% of data elements, which should be limited in number, receive the most prominent placement on the screen. Regardless of the action or event that is being performed, these data elements are visible. Good examples of this would be caller name and account number.

Likelihood to change the caller behavior, questions, or perception[edit]

Is the information of a nature that it will alter the way the caller perceives or goes about asking questions for the interaction? For example, by telling a customer that you are aware that they called yesterday and you already know what they called about can greatly change the questions, call time, and behavior.

Likelihood to change the CSR behavior or handling of the caller[edit]

Is the information of a nature that it will alter the way the CSR handles a caller interaction? For example, knowing that the caller is a frequent caller and that they are at an elite level will change the CSR handling of the caller.

During the interaction, when will the information be requested or presented[edit]

Information has value at different points in the interaction life cycle:

  • For example, if the caller is a VIP customer and should be treated accordingly, that information must be highly visible to the CSR at the beginning of the customer interaction during caller verification process.
  • Conversely, if data is required at the end of an interaction, this should also be considered for the UI.

Customer Service interaction elements[edit]

The Pega Customer Service UI includes many of these best practices. The figure below shows the elements of a phone interaction case.

  • The Ribbon provides information that will always be visible even when performing a task.
  • Notes are a good example of time-sensitive information that is potentially always referenced at the beginning of a call but does not need to be always visible.
  • Key inquiry fields are fields that are likely to be required during a customer interaction. Different implementations may have different needs and thus the fields displayed will vary.
  • Notice the Statements and Transactions tabs that are collapsed at the bottom. These are available with a single click.

Composite-data-placement.jpg

Results[edit]

When updating and extending the user experience of your Pega Customer Service implementation, take into account the key principles of visible, available, and accessible. Think about the timing of data during an interaction. Put a methodology in place early and scrutinize what, where, and how you place data elements in your UI. Following these simple rules will help you complete your journey to a great user experience and avoid continuous churn on data usage best practices.