NICE inContact cloud contact center software solution, having named as "Magic Quadrant Leader" by Gartner and as a Leader by Forrester Research in The Forrester Wave, has become one of the customer's most preferred Software in recent times offering all-in-one cloud CX platform. Despite a demand as such, our Pega Customer Service framework does not provide an OOTB integration package with Nice inContact like it has for other telephony software like Avaya, Genesys etc. One of our customers hit this roadblock while transforming their contact center solution from Salesforce to Pega because while Salesforce has its own in-built Nice inContact integration component, Pega does not provide the same. We took this challenge and designed this integration component with Pega and NICE to bridge the gap extending the Pega CS capabilities to implement the unified platform.

What it does

Pega Customer Service seamlessly integrates with NICE inContact to provide contact center agents the power to deliver enhanced customer service. Pega makes it easy to use NICE inContact MAX Dialer directly from Interaction Portal with instant transitions of agent states and incoming call pop with precise call coordinates automatically helping the contact center agents to handle incoming calls without having to swap between the two and also helping Pega to load the Customer 360 with utmost ease and accuracy for a coherent customer journey.

Key Features:

  1. Telephony request processing including simple telephony and agent state management using NICE inContact web call controls embedded directly within the Pega Customer Service Interaction Portal
  2. CTI events (incoming call) from NICE inContact are processed by Pega Call, triggering changes such as Call Treatment within your Customer Service application, which can be personalized with relevant caller data from NICE inContact.
  3. Agent state management, including availability status, quick both way status change, auto after call work.
  4. Readily available call coordinates to help kick start the direct interface for Customer 360

How we built it

This utility uses Pega CALL Open CTI interface to create adapters that can be used to integrate with Computer Telephony Integration (CTI) systems. The adapter plugs into the existing Pega Call framework and provides a bridge between the Pega Call framework and the NICE CTI server.

Being a server-side Open CTI implementation, the elementary architecture of the communication between Pega Call and NICE inContact is based on REST API calls. These API’s are cloud based and can be invoked from Pega with help of an authorization header consisting of an accessKeyId and accessKeySecret.

All the other API’s starting from getting the Agent ID based on the email address to joining an existing session using that Agent ID to getting the agent state to getting the next event; all of them will use this authorization header for access.

NICE inContact uses a typical “continuous poll-based” architecture to get the next set of events as far as agent state or call contact event is concerned. For this purpose, they have an API named “GetNextEvent” which gives you a list of events that happened for the last ‘n’ seconds where ‘n’ is a DSS that we have defined in Pega. As part of this implementation, we have designed two queue processors which help in orchestrating these events to the Pega Call event handlers and that in turn manages the agent states and the call pop-up in the Interaction Portal.

NICE inContact provides a soft phone digital channel called MAX (My Agent eXperience) which is installed in agent’s desktop. Once agent logs in using MAX he comes into Pega CS application and logs in into the soft phone present in CTI toolbar

  1. Pega CS invokes an API to get the agent id from NICE inContact on the basis of user’s email address.
  2. Pega CS invokes another API to join the same session which is initiated by logging in into MAX.
  3. Pega CS invokes another API to get the agent state from NICE inContact and then sets the same to CTI tool bar. An entry is added to the queue processor to poll NICE in contact for getting the next set of events. Once the queue processor gets any event related to call or agent state change then it uses web-socket call to sync up the Agent’s CTI tool bar or launch an interaction as per the event.

NICE Integration Sequence Diagram

Challenges we ran into

Handling of NICE InContact Events

In general, to handle events from any third party CTI Service Provider, the Open CTI architecture follows an "On-Demand" paradigm which constitutes of a publishing a REST service which the third party can invoke and broadcast the event as and when it arrives.

However, with NICE inContact , it was a lot different. NICE inContact does not adhere to that paradigm rather depends on the consumer which in this case is Pega - to do a "long-polling" on an API that they have published (getNextEvent) till the time that particular session is live. Once that session is terminated, the long-polling against that session ends. The "getNextEvent" API would first look at the last n seconds to find if there are any events to be transmitted back, if found would broadcast that immediately else would wait for the next n seconds to look for the next event.

This was a challenge for us to have designed an optimum and robust architecture which does this "long-polling" keeping in mind both performance as well as user experience. We thought of multiple design principles but finally narrowed it down to using Pega Queue Processors which leverages the high speed Kafka queues to process the events in form of streams and allowing Pega to scale both horizontally as well as vertically by spawning multiple kafka topics/partitions.

Alternate option that we also deliberated was using Stream data sets in conjunction with Real Time - Data Flows. While the usage of Kafka is common for both, the advantage that the combination of Stream Data Sets and Real Time Data Flows have over Queue Processors is that we can define our own partition keys. If we can define the partition key as Agent ID (say) then we can dedicate an entire partition to a particular agent further decreasing the latency. Having said that for some reason this did not work out and there was a weird infinite loop behavior with Stream Data Sets which forced us to fall back to Queue Processors only.

NICE InContact API

The other challenge we faced was to decode the NICE inContact API and corresponding documentation.

NICE inContact being a cloud based telephony software which provides a huge array of RESTful API's serving a wide variety of consumer requirements. It was an uphill task to go through all the sections of the API's like (1) Admin (2) Agent (3) Authentication (4) Real Time (5) Patron (6) User Hub (7) Reporting Data (8) Extraction etc. compare them with our customers needs, find out the most optimum API to use and then test it to see if it provides the output that we need or not. Overall, this analysis of filtering down the correct API's out from this list was the largest in terms of efforts spent on building this utility.

Finding the correct Extension points

Another challenging task was to find the correct extension points in pega which can be used to accomplish the specializations for our adapters pertaining to the NICE inContact Open CTI implementation.

Accomplishments that we're proud of

  1. With this integration, we were able to extend Pega CS capability to bring the Power of NICE inContact Intelligent CTI and provide unified solution to Customer for their contact center. Although we initially built this component for the customer in 8.4.4 but we made it compatible to the latest version of Pega 8.5 so that anyone can make use of the package as a reusable integration component.

  2. Cloud based platform and API based integration architecture helps in quick configuration with minimum effort and fast adoption in consumer community.

  3. The design principle strictly adheres to the Open CTI architecture and extensively uses Pega Call adapters in such a way that the utility can easily be extended to cater to Full Telephony functions like Transfer, Hold, Conference etc.

What we learned

Although we faced some challenges in building this component, it helped us in learning lot of new things:

  1. Server-side & client-side Open CTI architecture of Pega which enables integration with cloud based CX platform through API invocation.
  2. How does long polling works through queue processor leveraging Kafka topics to increase parallel processing

What's next for Integration with Nice inContact cloud telephony software

Our phase 2 plan for NICE integration is to convert it from a simple telephony integration platform to full-telephony supporting new features like Call Transfer, Hold, Conference etc. As a first step towards this goal, we need to again start identifying the NICE inContact API's that will help achieve the full telephony.

Built With

  • niceapi
  • pega
  • pegacs
+ 21 more
Share this project: