This is a how-to-design article shared with other Pega architects around the world who might be facing a common problem (described below) and thus benefit from our design successfully implemented and went live for one of our healthcare clients.
Business use case
In a Pega Customer Service application, when a caller is verified within IVR and the CTI server sends the incoming call to Pega server, CSR receives a screen pop and accepts the call. At the point, the Pega application normally invokes many web services to gather a large amount of member 360 data, map them to Clipboard, and then launch the member 360 screen (also known as ‘interaction driver’).
For example, in a healthcare context, the data often include claim, eligibility, contract, group, alerts, and other personal details.
At this point, CSR is ready to service the caller.
Because the Pega Customer Service application calls many web services to gather member 360 data, it is causing a long delay during a live interaction. CSR often must wait for 10 or more seconds until the member 360 screen completes loading. Adding this much of delay during a live call across hundreds and/or thousands of CSRs over a long period of time can cost a lot of money for call centers. In addition, customers do not like to wait on the phone for a long pause and may hang up the call.
(I’ve seen this same problem pretty much in every Pega CS project that I’ve engaged past 10 years.)
It is critical to launch the member 360 screen as fast as possible so that CSR can service the caller without much delay. This ultimately translates to both a reduced cost for call center and a higher satisfaction for customer.
Question - how can we launch the member 360 screen as fast as possible for CSR who has a caller on the phone? See attached for our design. Feel free to share any other ideas.
@NalinS it depends on when CSR starts talking to the caller. In your case, when is the conversation starting in regard to the auto launch of interaction? The end goal for us was to reduce a long silence (while calling external services and launching interaction driver) betweet CSR and the caller. We moved all of those service calls, which take the most time, to prefetch (which happens before the conversation bet. CSR and caller).
Posted: 8 months ago
Posted: 17 Feb 2021 12:30 EST
Amit Patel (Amit_Patel)
Director, Customer Service Engineering
@Will Cho In Customer Service 8.6, we took a systematic approach to address some of these delays in the product. Using the performance analyzer tools built in, we looked at each source of delay and fixed them. We were able to make a significant improvement in performance.
But, there's always a but :), this may not translate directly to a customer implementation. The composite in an implementation may be significantly different from the OOTB version, so the fixes that were made may not apply at all. Some toggles were added to skip some intent processing if a customer does not rely on that to guide the CSR. These can be helpful even in an implementation.
Ultimately, this work has to be done in the implementation directly and the changes may be very specific.