Routing scenarios using GPR

From Genesys Documentation
Jump to: navigation, search

ab-test-time-slice

Default Value: 0
Valid Values: 0, positive integers
Changes Take Effect: Immediately

To enable 50/50 A/B testing, which when Predictive Routing and skills-based routing are turned on alternately for equal periods, set the prr-mode configuration option in the same section to ab-test-time-sliced and configure a value for this ab-test-time-slice option. The time slice you set is how long each routing method is enabled before switching to the other.

Note: To configure non-50/50 A/B test periods, set the ab-test-gpr-on-period and ab-test-gpr-off-period options in such a way as to create the on-off split you want to use. For instructions, see the "Configure a non-50/50 comparison test time split" section in the "Routing scenarios using GPR" topic of the Genesys Predictive Routing Deployment and Operations Guide.

When enabled and set to one of the following values, time-sliced A/B testing works as follows:

  • 0 (the default) - The SetIdealAndReadyCondition subroutine uses a formula based on the time of day and the date to determine whether particular interaction belongs to Group A or Group B. The change from A to B and then back to A, and so on, occurs hourly. Which period starts at midnight depends on the whether the day of the year is even or odd. If the date is an odd number, A starts at midnight; if it is an even number, B starts at midnight.
  • A nonzero value (in seconds) - Genesys recommends that you do not set the value of this option to less than 3600 seconds in a production environment. The SetIdealAndReadyCondition subroutine uses a formula based on the configured time slice to determine whether a particular interaction belongs to Group A or Group B.

ab-test-gpr-off-period

Default Value: 0
Valid Values: 0, positive integers
Changes Take Effect: On the next interaction

Specifies the period of time, in seconds, that skills-based routing should route interactions when using time-sliced A/B test mode. This option alternates with the ab-test-gpr-on-period option, with each routing method used for the length of time you specify in the corresponding option. The split percentage is calculated based on the ratio of the two option values.

Important: These options take effect ONLY when the value set for the prr-mode option is ab-test-time-sliced.

For each interaction, the gpmUse KVP records whether GPR (gpmUse = 1) or skills-based routing (gpmUse = 0) routed the interaction.

If either the ab-test-gpr-on-period or ab-test-gpr-off-period option is set to 0, or has a negative or invalid value, GPR defaults to a 50/50 time split with the duration of each routing mode defined by the value of the ab-test-time-slice option.

ab-test-gpr-on-period

Default Value: 0
Valid Values: 0, positive integers
Changes Take Effect: On the next interaction

Specifies the period of time, in seconds, that GPR should route interactions when using time-sliced A/B test mode. This option alternates with the ab-test-gpr-off-period option, with each routing method used for the length of time you specify in the corresponding option. The split percentage is calculated based on the ratio of the two option values.

Important: These options take effect ONLY when the value set for the prr-mode option is ab-test-time-sliced.

For each interaction, the gpmUse KVP records whether GPR (gpmUse = 1) or skills-based routing (gpmUse = 0) routed the interaction.

If either the ab-test-gpr-on-period or ab-test-gpr-off-period option is set to 0, or has a negative or invalid value, GPR defaults to a 50/50 time split with the duration of each routing mode defined by the value of the ab-test-time-slice option.

ab-test-time-slice

Default Value: 0
Valid Values: 0, positive integers
Changes Take Effect: Immediately

To enable 50/50 A/B testing, which when Predictive Routing and skills-based routing are turned on alternately for equal periods, set the prr-mode configuration option in the same section to ab-test-time-sliced and configure a value for this ab-test-time-slice option. The time slice you set is how long each routing method is enabled before switching to the other.

Note: To configure non-50/50 A/B test periods, set the ab-test-gpr-on-period and ab-test-gpr-off-period options in such a way as to create the on-off split you want to use. For instructions, see the "Configure a non-50/50 comparison test time split" section in the "Routing scenarios using GPR" topic of the Genesys Predictive Routing Deployment and Operations Guide.

When enabled and set to one of the following values, time-sliced A/B testing works as follows:

  • 0 (the default) - The SetIdealAndReadyCondition subroutine uses a formula based on the time of day and the date to determine whether particular interaction belongs to Group A or Group B. The change from A to B and then back to A, and so on, occurs hourly. Which period starts at midnight depends on the whether the day of the year is even or odd. If the date is an odd number, A starts at midnight; if it is an even number, B starts at midnight.
  • A nonzero value (in seconds) - Genesys recommends that you do not set the value of this option to less than 3600 seconds in a production environment. The SetIdealAndReadyCondition subroutine uses a formula based on the configured time slice to determine whether a particular interaction belongs to Group A or Group B.

ab-test-time-slice

Default Value: 0
Valid Values: 0, positive integers
Changes Take Effect: Immediately

To enable 50/50 A/B testing, which when Predictive Routing and skills-based routing are turned on alternately for equal periods, set the prr-mode configuration option in the same section to ab-test-time-sliced and configure a value for this ab-test-time-slice option. The time slice you set is how long each routing method is enabled before switching to the other.

Note: To configure non-50/50 A/B test periods, set the ab-test-gpr-on-period and ab-test-gpr-off-period options in such a way as to create the on-off split you want to use. For instructions, see the "Configure a non-50/50 comparison test time split" section in the "Routing scenarios using GPR" topic of the Genesys Predictive Routing Deployment and Operations Guide.

When enabled and set to one of the following values, time-sliced A/B testing works as follows:

  • 0 (the default) - The SetIdealAndReadyCondition subroutine uses a formula based on the time of day and the date to determine whether particular interaction belongs to Group A or Group B. The change from A to B and then back to A, and so on, occurs hourly. Which period starts at midnight depends on the whether the day of the year is even or odd. If the date is an odd number, A starts at midnight; if it is an even number, B starts at midnight.
  • A nonzero value (in seconds) - Genesys recommends that you do not set the value of this option to less than 3600 seconds in a production environment. The SetIdealAndReadyCondition subroutine uses a formula based on the configured time slice to determine whether a particular interaction belongs to Group A or Group B.

prr-mode

Default Value: off
Valid Values: prod, off, ab-test-time-sliced, dry-run
Changes Take Effect: Immediately

Specifies whether an instance of Predictive Routing should run as a production instance or as a test instance.

  • prod - All the interactions that pass through the ActivatePredictiveRouting strategy subroutine are processed using Predictive Routing.
  • off - No interactions use Predictive Routing.
  • ab-test-time-sliced - The periods of time when Predictive Routing and skill-based routing are alternately turned on. The duration of each period is configured in the in the ab-test-time-slice option located in the same section as this prr-mode option.
  • dry-run - Predictive Routing scores agents for your interactions, but does not use the scores for routing.

max-score

Default Value: 100
Valid Values: (integer) 1 - <max>
Changes Take Effect: On the next interaction processed

Defines the maximum score that an agent can be assigned for an interaction. The value of this option is used by the ScoreIdealAgent callback function to re-scale the agent score as the distance from an ideally matched agent for the interaction (assumed by URS to be 0).

The value you set should correspond to the largest possible value returned by this Predictor from the scoring engine. To function properly, this value must be consistent with the value configured for the Predictor Score expression field. Because the GPR scoring engine and URS have different scales, you might need to adjust returned scoring values using the Score expression field in the Predictor configuration. See the instructions for how to configure this field in the "Creating and Updating Predictors" topic in the Genesys Predictive Routing Help for more information.

To take advantage of the most precise values, set max-score to 10000 and the value for Score expression in the Predictor configuration to 10000 * p_score. (p_score is a term used in the GPR documentation to indicate the raw score returned from the scoring engine. It is not in any way derived from or related to the statistical term P value.) For example, if scores range from -4 to 10, use the following p_score - ((p_score + 5) / 16) * 100.

max-score

Default Value: 100
Valid Values: (integer) 1 - <max>
Changes Take Effect: On the next interaction processed

Defines the maximum score that an agent can be assigned for an interaction. The value of this option is used by the ScoreIdealAgent callback function to re-scale the agent score as the distance from an ideally matched agent for the interaction (assumed by URS to be 0).

The value you set should correspond to the largest possible value returned by this Predictor from the scoring engine. To function properly, this value must be consistent with the value configured for the Predictor Score expression field. Because the GPR scoring engine and URS have different scales, you might need to adjust returned scoring values using the Score expression field in the Predictor configuration. See the instructions for how to configure this field in the "Creating and Updating Predictors" topic in the Genesys Predictive Routing Help for more information.

To take advantage of the most precise values, set max-score to 10000 and the value for Score expression in the Predictor configuration to 10000 * p_score. (p_score is a term used in the GPR documentation to indicate the raw score returned from the scoring engine. It is not in any way derived from or related to the statistical term P value.) For example, if scores range from -4 to 10, use the following p_score - ((p_score + 5) / 16) * 100.

max-score

Default Value: 100
Valid Values: (integer) 1 - <max>
Changes Take Effect: On the next interaction processed

Defines the maximum score that an agent can be assigned for an interaction. The value of this option is used by the ScoreIdealAgent callback function to re-scale the agent score as the distance from an ideally matched agent for the interaction (assumed by URS to be 0).

The value you set should correspond to the largest possible value returned by this Predictor from the scoring engine. To function properly, this value must be consistent with the value configured for the Predictor Score expression field. Because the GPR scoring engine and URS have different scales, you might need to adjust returned scoring values using the Score expression field in the Predictor configuration. See the instructions for how to configure this field in the "Creating and Updating Predictors" topic in the Genesys Predictive Routing Help for more information.

To take advantage of the most precise values, set max-score to 10000 and the value for Score expression in the Predictor configuration to 10000 * p_score. (p_score is a term used in the GPR documentation to indicate the raw score returned from the scoring engine. It is not in any way derived from or related to the statistical term P value.) For example, if scores range from -4 to 10, use the following p_score - ((p_score + 5) / 16) * 100.

max-score

Default Value: 100
Valid Values: (integer) 1 - <max>
Changes Take Effect: On the next interaction processed

Defines the maximum score that an agent can be assigned for an interaction. The value of this option is used by the ScoreIdealAgent callback function to re-scale the agent score as the distance from an ideally matched agent for the interaction (assumed by URS to be 0).

The value you set should correspond to the largest possible value returned by this Predictor from the scoring engine. To function properly, this value must be consistent with the value configured for the Predictor Score expression field. Because the GPR scoring engine and URS have different scales, you might need to adjust returned scoring values using the Score expression field in the Predictor configuration. See the instructions for how to configure this field in the "Creating and Updating Predictors" topic in the Genesys Predictive Routing Help for more information.

To take advantage of the most precise values, set max-score to 10000 and the value for Score expression in the Predictor configuration to 10000 * p_score. (p_score is a term used in the GPR documentation to indicate the raw score returned from the scoring engine. It is not in any way derived from or related to the statistical term P value.) For example, if scores range from -4 to 10, use the following p_score - ((p_score + 5) / 16) * 100.

max-score

Default Value: 100
Valid Values: (integer) 1 - <max>
Changes Take Effect: On the next interaction processed

Defines the maximum score that an agent can be assigned for an interaction. The value of this option is used by the ScoreIdealAgent callback function to re-scale the agent score as the distance from an ideally matched agent for the interaction (assumed by URS to be 0).

The value you set should correspond to the largest possible value returned by this Predictor from the scoring engine. To function properly, this value must be consistent with the value configured for the Predictor Score expression field. Because the GPR scoring engine and URS have different scales, you might need to adjust returned scoring values using the Score expression field in the Predictor configuration. See the instructions for how to configure this field in the "Creating and Updating Predictors" topic in the Genesys Predictive Routing Help for more information.

To take advantage of the most precise values, set max-score to 10000 and the value for Score expression in the Predictor configuration to 10000 * p_score. (p_score is a term used in the GPR documentation to indicate the raw score returned from the scoring engine. It is not in any way derived from or related to the statistical term P value.) For example, if scores range from -4 to 10, use the following p_score - ((p_score + 5) / 16) * 100.

Learn about Predictive Routing interaction flows, how the URS Strategy Subroutines work together to score agents and identify a routing target, how URS ranks agents by score, and how GPR handles agent reservation.

Related documentation:

If you would like to evaluate Genesys Predictive Routing for use with service-level routing or business-objective routing, contact Genesys Professional Services for a review of your routing environment.

If your environment uses multiple URS instances receiving interactions from a single T-Server, the only criterion used to select the next interaction for routing is priority.

This topic assumes that you are using a virtual agent group (VAG) as the target for your routing. If you route using a skill expression to identify your targets, convert it to a VAG string expression using the IRD MultiSkill or CreateSkillGroup function before passing the resulting string as an argument to the ActivatePredictiveRouting subroutine. See Using Agent Skills for Ideal Agent Selection in the Supplement to the Universal Routing 8.1 Reference Manual for more information.

High-Level Predictive Routing interaction flow

The graphic in this section 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 Set up data for import 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.
  • Your reporting solution for Predictive Routing - Whether you are using GCXI, Genesys Pulse, or another solution to present the data stored in Genesys Info Mart.GPMCallFlowBasic.png

How the Strategy Subroutines work

The following sequence provides a basic overview of the way the various GPR subroutines work together to evaluate agent scores and determine the best match given the currently available agents and the currently waiting interactions.

  1. ActivatePredictiveRouting retrieves agent scores from the GPR Core Platform via REST API request and stores them in the global map in URS memory. The name of the map is the interaction ConnectionId (the original ID, if the interaction is a consult). This map contains pairs of agent employee IDs as the keys and their scores for the interaction as values. ActivatePredictiveRouting calls the SetIdealAndReadyCondition subroutine for further interaction processing.
  2. SetIdealAndReadyCondition processes the different modes of Predictive Routing. It calls the SetIdealAgent IRD function to schedule the execution of the URS callback subroutines. It calls the ScoreIdealAgent subroutine to facilitate interaction queueing according to their scores, and calls SetReadyCondition (if enabled) to call the isAgentScoreGood subroutine.
    The parameters for these callback subroutines are retrieved and verified before any URS request is invoked to enable the callbacks.
  3. After establishing a list of potential targets based on the target expression (Skill, Agent Group, and so on) SetIdealAndReadyCondition then executes the ScoreIdealAgent callback subroutine.
  4. ScoreIdealAgent retrieves the scores for the potential target agents from the global map set in Step 1.
  5. When an agent becomes ready, URS executes the isAgentScoreGood subroutine to determine whether that target is acceptable. If you enabled agent hold-out, URS executes the isAgentScoreGood subroutine when an agent becomes ready, which determines whether that agent reaches the specified threshold score. If not, URS waits for a configured timeout period, then checks whether any agent now satisfies the adjusted threshold value. See How Does GPR Score Agents? for a detailed discussion of how agent hold-out routing works.
  6. Once the isAgentScoreGood subroutine locates an available agent who scores above the current threshold, it sends the target details to URS to initiate routing.
  7. URS calls the GPRIxnCompleted subroutine as a custom step from a Routing Block in the strategy. It collects the Predictive Routing outcome for the successfully routed interaction (the DBID of the agent to whom it was distributed, the score of the agent, other interaction statistics relevant for the Predictive Routing performance) and prepares the user data for Predictive Routing reporting.
  8. URS calls the GPRIxnCleanup subroutine from both the success and failure exits from the Routing block, or if the interaction is abandoned. The purpose of the subroutine is to publish the Predictive Routing reporting user data and to clean up the ScoreIdealAgent and isAgentScoreGood callback subroutines. GPRIxnCleanup publishes reporting data in two ways:
    • It sends a UserEvent containing the user data relevant for Predictive Routing to T-Server/SIP Server, from which is enters the Genesys historic reporting solution flow.
    • It can submit the same data AI Core Services via REST API request where it is stored in the score_log and can be retrieve using an API request.
Important
If your routing strategy uses the SelectDN and SuspendDN IRD functions instead of a Routing Block, consult with Genesys Professional services about how the ActivatePredictiveRouting, GPRIxnCompleted and GPRIxnCleanup subroutines can be integrated into your strategy.
URSStratSubFlow.png

Routing scenarios using Predictive Routing

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 GPRIxnCompleted 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.

When interactions are waiting, URS uses a number of criteria to decide the order in which it directs the interactions to the best target. In general, URS uses the following hierarchy:

  1. Interaction priority.
  2. Best agent score.
    Important
    In scenarios where both scored and unscored interactions might have the same priority, scoring is disregarded for all the interactions and the selection is based on the next differentiating criterion, time.
  3. Time in queue, which can be based on age of interaction or time in queue and can incorporate predicted wait time.
  4. Interaction ID (URS selects the interaction with the lowest—oldest—ID). This is a rarely-used "tie-breaker" criterion.

Using gpmStatus and gpmSuitableAgentsCount to Monitor Your Routing

gpmStatus and gpmSuitableAgentsCount are KVP values written in the Genesys Info Mart database when an interaction is routed using the GPR subroutines. (You can also retrieve the values by using the GPR API to query the score log.)

  • gpmStatus indicates whether there was an agent-surplus or an interaction-surplus condition when the interaction was routed.
  • gpmSuitableAgentsCount indicates the number of agents who have scores returned from AICS greater than or equal to the initial threshold value when the scoring response is received. If gpmSuitableAgentsCount is 0, then no agents have eligible scores compared with the threshold value, so the interaction must wait for a higher-scoring agent to become available or for the next threshold relaxation step

These KVP values, when analyzed for different interactions over a representative day or week period can help you understand your contact center traffic and GPR performance. The following table indicates certain scenarios and how to interpret them.

KVP Values Inference
gpmStatus = caller-surplus

gpmSuitableAgentsCount > 0

Your GPR Model is returning useful scores with relation to the configured routing threshold, but agent staffing is not adequate to produce satisfactory wait times.
gpmStatus = agent-surplus

gpmSuitableAgentsCount > 0 or consistently a very small number

Analyze why the scores GPR returns are not meeting the configured threshold. You might need to retrain your Model, adjust the scoring expression, or reduce the threshold level.

How Interactions are Sorted within the Queue

As each interaction comes in, it is scored, and then assessed relative to the interaction at the midpoint of the existing array of interactions. Should GPR route it before or after the mid-point interaction?
Important
The order in which interactions are prioritized is called an array here. This is not equivalent to a queue. These interactions might be from multiple queues, each of which is submitting interactions for URS sorting and routing.
After this decision, URS compares the new interaction against the midpoint within the selected region. Each time URS evaluates the interaction, it is assigned to a smaller region with the total array, always relative to the midpoint of the previous region.
Important
The order in which interactions are prioritized is called an array here. This is not equivalent to a queue. These interactions might be from multiple queues, each of which is submitting interactions for URS sorting and routing.

GPRixnOrderArray.png

The sorting decision tree:

GPRixnDecisionTree.png

Example 1

Three calls arrive at a contact center:

  • C1 - priority = 1, agent score = 0.3, timestamp = 0:00, URS ID = 1
  • C2 - priority = 1, agent score = n/a, timestamp = 0:05, URS ID = 2
  • C3 - priority = 1, agent score = 0.6, timestamp = 0:10, URS ID = 3
  1. C1 arrives first and is placed into the empty array.
  2. C2 arrives. URS compares it with the middle (in this case, only) call in the array, C1.
    The priority is equal and, because C2 has no agent score, URS moves to the next decision criterion.
  3. C2 has a shorter wait time, so is put behind C1.
    With only two calls in the array, no further comparison is needed.
  4. C3 arrives. URS compares it against the "middle" entry of the array, C1.
    The priority is equal. C3 has better score (further from 0), so URS puts it in front of C1.

Outcome: C3, C1, C2 (the example assumes that interactions are taken from the left end of the array)

Example 2

Five calls arrive at a contact center and are placed in either the Predictive Routing queue or a conventional queue:

  • C1 - priority = 1, agent score = n/a, timestamp = 0:00, URS ID = 1
  • C2 - priority = 1, agent score = 0.5, timestamp = 0:05, URS ID = 2
  • C3 - priority = 1, agent score = n/a, timestamp = 0:10, URS ID = 3
  • C4 - priority = 1, agent score = 0.75, timestamp = 0:15, URS ID = 4
  • C5 - priority = 1, agent score = 0.95, timestamp = 0:20, URS ID = 5
  1. C1 arrives first. URS places it into the empty array.
  2. C2 arrives. URS compares it with the middle (in this case, only) call in the array, C1.
    The priority is equal and, because C1 has no agent score, URS moves to the next decision criterion.
  3. C2 has a shorter wait time, so is put behind C1. (In this example,
    Current order: C1 C2 (the example assumes that interactions are taken from the left end of the array)
    With only two calls in the array, no further comparison is needed.
  4. C3 arrives. URS compares it against the "middle" entry of the array, C2.
    The priority is equal and, because C3 has no agent score, URS moves to the next decision criterion.
  5. C3 has a shorter wait time, so is put behind C2.
    Current order: C1 C2 C3
  6. C4 arrives. URS compares it against the middle entry of the array, C2.
    The priority is equal. C4 has a better score (further from 0), so URS places it before C2.
  7. Now URS must determine whether C4 should be before or after C1, which is also before C2.
    The priority is equal and, because C3 has no agent score, URS moves to the next decision criterion.
  8. C4 has a shorter wait time (a more recent timestamp), so URS places it behind C1.
    Current order: C1 C4 C2 C3
  9. C5 arrives. URS compares it against the "middle" entry of the array, C2.
    The priority is equal. C5 has a better score (further from 0), so URS places it before C2.
  10. Now URS must determine whether C5 should be before or after C4, the "middle" call in the section of the array before C2.
    The priority is equal. C5 has a better score, so URS places it before C4.
  11. Now URS must determine whether C5 should be before or after C1.
  12. C5 has a shorter wait time, so URS places it behind C1.
    Final order: C1 C5 C4 C2 C3

Using Agent Hold-Out

Agent hold-out enables you to have an interaction wait a specified time, even when an agent has become available, if the available agent is has a low score for the interaction and there is a chance a better-matched agent might become available within the configured time window. The interaction flow is as follows:

  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, 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. Use the relevant Predictive_Route_DataCfg Transaction List Object configuration options to set up the priority increments.

Dynamic Interaction Priority Increments

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.

Use the relevant Predictive_Route_DataCfg Transaction List Object configuration options to set up the priority increments.

Using GPR with agent reservation

When your Genesys environment contains multiple URS nodes, they might compete to distribute interactions to the same pool of agents. URS uses agent reservation functionality to resolve which interaction should be routed to a particular agent. For details, see the agent_reservation option in the Universal Routing 8.1 Reference Manual.

Note: If you are using Service Objective, or Prediction/What-if routing, consult Genesys Customer Care for how to agent reservation works in these scenarios.

For agent reservation, a URS node sends an agent reservation request to a dedicated SIP Server/T-Server application with three extensions: priority, ar-priority-1, and ar-priority-2. The value for the extensions depends on whether this is a GPR interaction and what value you have set for the URS automatic_ideal_agent option.

For GPR interactions:

  • priority: The current interaction priority.
  • ar-priority-1: The score assigned by URS to the agent for this interaction calculated using the following formula: (100 - (<value of max-score> - <agent score assigned by GPR Core Platform>)). The value can be negative.
  • ar-priority-2: The time the interaction spent in the strategy Target block, in milliseconds.

For non-GPR interactions when the URS automatic_ideal_agent option is set to a positive value (the recommended configuration):

  • priority: The current interaction priority.
  • ar-priority-1: The value for this extension is calculated as (100 - <value of the automatic_ideal_agent option>). The value can be negative.
  • ar-priority-2: The time the interaction spent in the strategy Target block, in milliseconds.

For non-GPR interactions when the URS automatic_ideal_agent option is set to false:

  • priority: The current interaction priority.
  • ar-priority-1: The integer part of the time spent by the interaction in the strategy Target block, in seconds.
  • ar-priority-2: The fractional part of a second of the time spent by the interaction in the strategy Target block, in milliseconds (value range is 0-999).

Example 1

Two URS nodes send concurrent agent reservation requests to SIP Server/T-Server targeting the same agent to handle GPR interactions. When SIP Server/T-Server resolves this race condition, it first compares the interaction priority values (the values of the priority Extension key). If they are equal, SIP Server/T-Server compares the values of the ar-priority-1 keys, which were calculated based on agent scores for the interaction. If those values are also the same, SIP Server/T-Server assigns the interaction waiting longer in the Target block, based on the values of the ar-priority-2 keys, to the agent. URS fails the routing attempt for the other interaction and the routing strategy handles rerouting it. GPR reports the failed routing attempt using the reporting key gpmResult=14.

Example 2a

Two URS nodes have the automatic_ideal_agent configuration option set to 45. Predictive Routing has the max-score set to 100. URS node 1 targets a GPR interaction to an agent with an ar-priority-1 score of 60 for the interacrion. Concurrently, URS node 2 targets a non-GPR interaction to the same agent. The agent has an ar-priority-1 score of 55 for that interaction. Based on these scores, the SIP Server/T-Server handling agent reservation assigns the GPR interaction from URS node 1 to the agent.

Example 2b

This example has a scenario similar to Example 2a, but the max-score and automatic_ideal_agent have different values.

Two URS nodes have the automatic_ideal_agent option set to 4500. The Predictive Routing max-score option is set to 10000. URS node 1 targets a GPR interaction to an agent for which the GPR Core Platform has assigned a score of 6000. According to the formula for the calculation of ar-priority-1 (see the beginning of this section), the agent's adjusted value is (100 - (10000 - 6000))=-3900. Concurrently, URS node 2 targets a non-GPR interaction to the same agent, who has an ar-priority-1 value of (100 - 4500) = -4400 for that non-GPR interaction. Based on these values, the SIP Server/T-Server handling agent reservation assigns the GPR interaction from URS node 1 to the agent.

Example 3

Two URS nodes have the automatic_ideal_agent option set to false. Predictive Routing has the max-score set to 100. URS node 1 targets a GPR interaction, Interaction 1, to an agent for which the GPR Core Platform has assigned a score of 60. Concurrently, URS node 2 targets a non-GPR interaction, Interaction 2, to the to the same agent, who has the same ar-priority-1 value of 60 for that non-GPR interaction. Interaction 1 spent 67.3 seconds in the strategy Target block while Interaction 2 spent 180.5 seconds there. The SIP Server/T-Server handling agent reservation receives the requests: one from URS node 1 with ar-priority-1=60, ar-priority-2=67300 and the other from URS node 2 with ar-priority-1=180, ar-priority-2=500. As a result, Interaction 2 is routed to the agent.

Configure A/B comparison test ratios

To test how GPR handles routing on your queues compared with skills-based routing, you can configure an A/B (comparison) test. GPR handles a specified percentage of interactions (GPR on) and the rest are routed by your original routing method (GPR off).

To start using comparison testing, set the prr-mode option to ab-test-time-sliced. This turns on comparison testing mode.

Start A/B testing

Genesys recommends the following sequence:

  1. Start with a fourteen-day, 50/50, hour-on hour-off comparison test in your test environment.
  2. Based on a satisfactory result, turn GPR on for all interactions in your production environment.
  3. (Optional) - To check that GPR continues to generate improvement, run a non-50/50 comparison test in your production environment using a ratio such as 90/10 or 80/20. Such a split enables you to retain most of the benefit from using GPR while verifying GPR performance compared with traditional routing.

Instructions for configuring both 50/50 and non-50/50 time splits follow.

Notes on how A/B testing works

  • When configuring A/B test periods, Genesys recommends that the time slices should be no shorter than 3600 seconds (one hour) and, if you use longer time slices, that they should be multiples of one hour.
  • To ensure that the A and B test slices are comparable, GPR alternates which routing method is on during a specific time slice, both daily and weekly.
    • Example 1 - With an hour-on, hour-off 50/50 test cycle (the default setting), Monday 8-9 uses A, Tuesday 8-9 uses B. The slices are also switched weekly, so that in week 1 Monday 8-9 is A and in week 2, Monday 8-9 is B. By the end of a two-week comparison period, each routing method has been used for each time-slice period.
    • Example 2 - With an eight hours on, two hours off 80/20 test cycle (as explained in the "Configure a non-50/50 comparison test time split" section, below), Monday midnight - 8 am uses A, 8-10 uses B, and so on. In this pattern, the times of day routed using each method shift automatically. This shift produces a full cycle that uses each routing method for each time-slice period. Assuming your environment is active twenty-four hours, a single full cycle takes six days. You must then adjust the length of the comparison test depending on the nature of your environment and the KPI you specify.
  • A comparison test should always run at least fourteen days. In most cases, you must run the test significantly longer to ensure that you produce consistent results. The length of a comparison test should take the following factors into account:
    • KPI type - A KPI such as AHT, which returns an immediate result, requires a shorter test period than a KPI, such as first contact resolution, that takes time before the KPI outcome for an interaction is available.
    • Time ratio configured - Non-50/50 time splits require longer comparison tests. The further from 50/50, the longer the comparison test should be to achieve solid results.
    • Improvement with GPR - The stronger the percent improvement using GPR, the shorter the comparison test period can be.
    • Example - In a test of AHT showing a 3% benefit using GPR, Genesys recommends that you run a test with an 80/20 split for 30 days, and a 90/10 split for 44 days.

Note: A/B comparison testing is based on time-on/time-off segments. The number of calls routed by each method might not exactly match the specified percentage because the number of calls coming into the queue might vary throughout the comparison test period.

Configure a 50/50 comparison test time split

For a 50/50 comparison test split, set the ab-test-time-slice option to a positive value. This is the time, in seconds, for each routing method to run (the time slice).

If you do not configure this option, A/B test periods are hourly by default. For more information, see the complete description of the ab-test-time-slice option.

  • Genesys recommends that your time slice be at least 3600 seconds in a production environment.
  • For robust results, run a 50/50 comparison test time split for at least 14 days with the times slices no shorter than one hour on, one hour off (this is the default setting).

Configure a non-50/50 comparison test time split

If you would like to move GPR into production but monitor the benefit at the same time, Genesys recommends using a non-50/50 split. To set the comparison test time periods to a non-50/50 split, specify values that produce the desired time split in the following two configuration options:

If you leave these options at the default settings, the comparison test defaults to a 50/50 split, with interactions routed half the time using GPR and half using skills-based routing. The on/off periods (time slices) are defined by the value set in the ab-test-time-slice option.

Example configuration for a 90/10 split

  • ab-test-gpr-on-period - 60*60*9 (9 hours ON)
  • ab-test-gpr-off-period - 60*60*1 (1 hour OFF)

Example configuration for an 80/20 split

  • ab-test-gpr-on-period - 60*60*8 (8 hours ON)
  • ab-test-gpr-off-period - 60*60*2 (2 hour OFF)

To get high-quality results from comparison testing, the test must run long enough to smooth out any unusual occurrences or statistical anomalies in the data. The further the split is set from a 50/50 ratio, the longer the comparison test period should be to achieve a high-quality test.

Retrieved from "https://all.docs.genesys.com/PE-GPR/9.0.0/Deployment/ixnFlows (2021-11-27 08:12:19)"