Jump to: navigation, search

Planning: Architecture and Interaction Flows

This topic presents Genesys Predictive Routing (GPR) architecture, first at a high-level overview, followed by more detailed views of the connections used by the AI Core Services (AICS), Agent State Connector (ASC), and Strategy Subroutines components.

This topic discusses in detail only the architecture of the GPR components. Agent and customer data, which can come from Genesys Info Mart, and any other relevant data sources in your environment, is a separate topic. For more about data, see Planning: The Data Pipeline.

Secure Connections

Predictive Routing supports the following security and connection protocols:

  • ADDP
  • HTTPS
  • Transport Layer Security (TLS) 1.2

The following protocols are supported for the specified connections:

  • Tango container to MongoDB container: SSL
  • ASC to Config Server: TLS 1.2; you can specify an upgrade-mode Configuration Server port by updating the -port command line parameter in the ASC Application object Start Info tab.
  • ASC to Stat Server: TLS 1.2
  • ASC to AICS: HTTP/S
  • URS or ORS to AICS: HTTP/S

To use secure TLS connections between ASC and Stat Server/Configuration Server, you must configure such connections manually following the procedures described in the Genesys Security Deployment Guide.

Secure Logins

Predictive Routing supports LDAP authentication for user logins. See Settings: Configuring Accounts and Account: User Management for procedures to configure LDAP authenticated accounts.

High-Level Architecture

The following diagram presents an overview of the various components and connections required for Predictive Routing.

GPMSolutionArchitecture.png

The Tango Container

  • Gunicorn: A Python WSGI HTTP Server for UNIX, used to provide web services for the Predictive Routing API and the web interface.
  • AI Core Services (AICS): The Genesys platform that provides the scoring engine and other analytical underpinnings that drive Predictive Routing. It supports the Predictive Routing API and the web-based user interface.

The NGINX Container

  • NGINX: Used to load-balance the Gunicorn workers and MongoDB instances in test and demo environments.
Important
NGINX is provided as a convenience for our users. It is not intended for use in production HA environments.

The MongoDB Container

  • MongoDB: A highly scalable, highly available no-SQL database which is especially efficient at handling large batches of JSON format data. It also supports fast, efficient queries of that data.

Other Solutions

Note that, in addition to the components included with Predictive Routing or required as prerequisites, you need to have adequate data source(s), and various Genesys components: Configuration Server, Stat Server, Universal Routing Server/IRD or Orchestration Server/Composer, and Genesys Info Mart, which provides a data source and stores user data from Predictive Routing to use in reporting.

ASC Connections

Agent State Connector is a Java application that connects to Configuration Server and Stat Server. ASC can be monitored, started, and stopped in Solution Control Interface. It supports a warm-standby high availability architecture.

ASC pulls all configuration data from Configuration Server and saves it to the Predictive Routing database. From the data, you can create the Agent Profile schema.

Once you have set up your Agent Profile, ASC receives updates from Configuration Server (changes to agent configuration, such as a new location or a change to a skill level) and from Stat Server (updates on agent availability), and sends them to AICS.

ASCNetworkConnection.png

Strategy Subroutines Components and Connections

The URS and Composer strategy subroutine components invoke Predictive Routing models at real time. The strategy subroutines send a request to a predictor to return the projected scores for a specific customer's interaction handled by each agent in the target group. The scores are projections for how well each agent can be expected to handle that interaction, given the particular interaction type, customer intent, agent skill level, and whatever other factors you anticipate to be relevant. You can use the scores to determine the routing target, or choose to disregard them.

Important
Predictive Routing is not supported for environments that use schedule-based routing.

Predictive Routing supplies out-of-the-box strategy subroutines for both IRD/URS and Composer/ORS/URS.

  • IRD requires you to use the Predictive Routing URS Strategy Subroutines component. Insert the strategy subroutines into the appropriate position in your strategy flow.
  • Composer requires the use of the Predictive Routing Composer Strategy Subroutines. Insert the strategy subroutines into the appropriate position in your strategy flow. If you are using Composer, you need Orchestration Server (ORS) as well as URS in your environment.

StratSubsArch.png

Basic Predictive Routing Interaction Flow

The graphic below shows a very general interaction flow using Predictive Routing. Refinements to the flow depend greatly on details of your environment. Key aspects that differ in various environments:

  • Your data—That is, the interaction types supported and the applications that might have relevant information. Genesys Info Mart is a key data source, but CRM systems and other applications in your environment can also provide important data. See Planning:The Data Pipeline for more information.
  • Your pre-routing data flow. This depends on the interaction type and the exact architecture in your environment. For example, is this a chat interaction or a call? Do you use an IVR, and if so, what information do you attach?
  • The Genesys routing solution you are using. Predictive Routing supports routing with IRD/URS and with Composer/ORS/URS.
  • Whether you are reporting on Predictive Routing and, if so, whether you are using GI2 or another solution to present the data stored in Genesys Info Mart.

GPMCallFlowBasic.png

Interaction Flows within Predictive Routing

Existing Composer or IRD strategies are modified to incorporate Predictive Routing subroutines. Instead of picking the Agent with required skills that has the longest-waiting time or using simple agent-group routing, Predictive Routing can predict the best results for an interaction, based on the customer's intent or other relevant information.

When you are using Predictive Routing to route interactions, there are two main scenarios that affect how this matching plays out:

  • Agent Surplus: There are relatively few interactions, which means there could be a number of high-score agents available. You can configure a minimum threshold so that, if the agents available are not very highly ranked, the strategy keeps the interaction in queue until a better-scoring agent becomes available.
  • Interaction Surplus: There are many interactions, so that most agents are busy and it might be more difficult to find an ideal agent for each interaction. In such a scenario, you can have agents matched to the interaction for which they have the highest probability of getting a positive result.

Agent Surplus Flow

In this case there are agents logged in and in the Ready state who can respond to interactions immediately. From a Virtual Agent Group that is defined by skill expression, URS first tries to route an interaction to an agent with the best score, using the following process to match agents and interactions:

  1. An interaction arrives at the routing strategy, which has a target group of agents.
  2. The ActivatePredictiveRouting subroutine sends a request to the Predictive Routing scoring server via HTTP request.
  3. Predictive Routing returns scores for each agent in the target group based on the criteria you selected in the active model.
  4. The ActivatePredictiveRouting subroutine updates a global cache in URS memory, which keeps agent scores for all interactions. When URS tries to route the current interaction to the agent group, it sorts the agents according to their scores, in descending order, and routes to the agents with the best score first.

When URS takes an interaction from the queue:

  1. URS calls the ScoreIdealAgent subroutine, which reads the agent scores in the target group from global map and ranks the agents by score.
  2. URS calls the IsAgentScoreGood subroutine, which selects the available agent with the highest score, assuming the agent has a score high enough to be selected for this interaction.
    In an agent-surplus scenario, it is typically not a problem to route to an agent with a good score. For scenarios where this is not the case, see Interaction Surplus Flow, below.
  3. URS calls the PrrIxnCompleted subroutine, which updates user data with the scoring result for storage in Genesys Info Mart.
  4. URS calls the PRRLog macro, which logs the result in the URS log file.

Interaction Surplus Flow

This scenario covers situations when all agents are already busy handling interactions and new interactions are queued. When one of the agents becomes ready, the system selects the interaction for which the agent has the best score. This is not necessarily the interaction that has been in the queue longest.

  1. URS calls the IsAgentScoreGood subroutine, which determines whether any of the available agents meet the threshold for handling the interaction.
  2. If available agents have low scores for this interaction and the interaction spent only a short time in the queue, URS waits for a better agent to become ready.
  3. The minimum acceptable score required for an agent for the interaction is gradually reduced (you can specify the timing and the increments in the Predictive_Route_DataCfg Transaction List Object configuration options), so if no higher-scored agent becomes available, the lower-scored agent might finally be given the interaction.

After that determination occurs, the remainder of the flow is the same as that given in the agent-surplus flow above.

Avoid Delays While Customers Wait for the Best Agent

To avoid having interactions lingering in a queue for an excessive amount of time, URS can trigger an escalation in interaction priority after a time delay that you set. To speed up interaction handling, you can incrementally relax the minimum skill level required for agents to handle the interaction or expand the pool of agents to consider.

Each time a routing strategy tries to route an interactions, it calls the ActivatePredictiveRouting subroutine. After each failed routing attempt, the strategy checks how long the interaction has been waiting in the queue and, if the time in queue is above a certain threshold, it routes the interaction to the next available agent, no matter their score for the interaction.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 18 May 2018, at 07:31.