FAQs: Predictive routing
Predictive routing: Workload balancing and reporting FAQs
How does predictive routing impact agent workload?
Predictive routing attempts to assign interactions to the highest scored agents for the selected KPI, which can create workload imbalance. Workload balancing can be enabled as part of the predictive routing assignment to rebalance volume toward other, lower scored agents.
How does workload balancing work?
Workload balancing uses all agents in a balanced way while still considering the best possible agent to interaction matches. With workload balancing, predictive routing can rescore agents in two ways:
- By agent idle time: agents who have been idle longer are scored higher to receive more calls, while busy agents are scored lower to reduce load.
- By occupancy rate: agents are rescored up or down based on how their recent occupancy compares to threshold values defined by the customer, spreading work evenly across the team.
The trade off: because workload balancing reduces how often the single best agent is chosen, there may be a slight decrease in KPI gains. Best practice is to test with and without workload balancing, for example, two weeks each, to compare impact on KPI optimization results.
Recommended approach: start with the default idle time setting and monitor results. If that does not provide sufficient balance, switch to occupancy based scoring using customer defined thresholds, for example, agent occupancy should stay between 30 percent and 80 percent.
Will reports be available to see who is getting certain calls, for example, to detect imbalances or training needs?
Yes. The Queue Performance Detail view in Genesys Cloud shows which agents are handling interactions, with metrics such as answered calls, handle time, and transfers. Results can be filtered to the agent level and by time, media type, or skill.
For queues enabled with GPR, this view helps identify how predictive routing distributes calls across agents, detect imbalances, and identify where training or model adjustments may be needed. See Queue Performance Detail view.
In the Interactions report, for interactions routed by predictive routing, the Predictive Agent Selected column lists the agent assigned by predictive routing, while the Predictive Agents Proposed column lists the first five highest scored agents evaluated for interaction assignment.
Predictive routing: Revenue KPI and data FAQs
What additional customer data can be used to improve revenue KPI (for example, retention or churn) predictions?
Beyond standard interaction and agent data, customers can supply additional participant data to strengthen revenue focused models. Common categories include:
- Demographics and socioeconomic: income range
- Contract or policy: contract status, plan type, tenure, coverage start date, plan tier
- Billing and payment behavior: bill amount, premiums, late fees, payment method, overdraft frequency
- Usage behavior and engagement: usage volume, feature adoption, transaction volume, claims submitted
- Account value and profitability: ARPA, profitability, fees paid, premiums to claims ratio
- Account stability signals: usage or size changes, balance or transaction drops, policy utilization changes
- Channel and digital behavior: portal or app logins, website usage, email click rates
- Sentiment and survey feedback: CSAT scores, sentiment scores, complaints history
- Plan or product switching events: plan changes, upgrades, product switching, cancellations, and re enrollments
These data points are included as participant data and processed as model features. The most relevant features surface in the predictor explainability report.
Is a specific data platform, such as Snowflake, required to support revenue KPI optimization?
No. A platform such as Snowflake may be proposed as one possible approach for the data pipeline, but it is not a strict requirement. The pipeline can be adapted to fit the customer’s own data governance and security requirements, for example, using SSH key based authentication instead of Snowflake access.
Predictive routing: Billing and token consumption FAQs
Does running benefit assessment consume my AI tokens when GPR is enabled?
AI tokens are consumed only when an interaction is routed from a queue has predictive routing enabled. No AI tokens are used in the following scenarios:
- When running benefit assessment.
- When running comparison or value-monitoring mode.
- When an interaction on a queue that has GPR enabled is routed using a different routing method due to a timeout.
Predictive routing: Testing and benefit assessment FAQs
How can I test Predictive Routing?
Predictive Routing is part of the AI Experience Bundle, which includes a 60-day free trial. The AI Experience Bundle also provides monthly tokens for continued use. For more information, see AI Experience token metering and pricing.
What does a controlled pilot look like, and how should success be measured?
A typical controlled pilot runs for approximately six weeks across four stages.
Stage 1: Select and baseline (weeks 1 to 2)
- Run a benefit assessment to identify high potential queues per KPI. Benefit assessments are free and consume no AI Tokens.
- Shortlist one or two queues that meet the readiness criteria: at least 90 days of historical interaction data and more than four agents assigned.
- Establish the baseline. For AHT, take it from historical queue data. For NCA, note that queue level data is not available before enablement. The Channel Insights dashboard reports NCA at organization level by media type, so the benefit assessment output serves as the reference point.
- Agree on the success threshold and the guardrail metrics before enabling anything.
Stage 2: Train and activate (weeks 3 to 6)
- The model trains on the queue’s history. Once activated, the model takes a short time to become usable. Standard routing continues to distribute interactions in the meantime with no impact.
- Use comparison or value monitoring mode together with A/B testing, so that lift is measured against a live control rather than against recalled performance. No AI Tokens are consumed for interactions that do not route via predictive routing.
Stage 3: Read the results
- Allow for the measurement lag. AHT results appear immediately but become meaningful after approximately two weeks. NCA results appear after the seven day lookup period.
- Test with and without workload balancing, approximately two weeks each, to see what balancing costs in KPI lift and what it returns in distribution.
Stage 4: Tune and expand (week 6 onward)
- Adjust the timeout and the workload balancing mode, then extend to further queues once the pattern is established.
Measuring success
The pilot should be measured on the selected KPI together with a small set of guardrails, so that a KPI gain is not achieved at the cost of fairness or service level.
| Metric | What it confirms |
|---|---|
| Primary KPI lift | Lift in the selected KPI compared with the A/B control on the pilot queue |
| Workload distribution | Whether volume is concentrating on higher scored agents, visible in the Queue Performance Detail view and the Interactions view, both of which identify the predictive agent selected and the agents proposed |
| Service level and ASA | Confirmation that the timeout is not extending wait times beyond what the queue can absorb |
| Occupancy spread | If occupancy moves outside the acceptable band, switch to occupancy based workload balancing |
| Model plausibility | Whether the Predictive Model view shows the model relying on features that make operational sense |
Routing admin ownership: stages 2 and 4 belong to the routing admin, covering activation, timeout, workload balancing mode, and the A/B configuration.
Workforce manager ownership: stages 1 and 3 belong to the workforce manager, covering queue selection, the success threshold agreed in advance, and the judgment on whether the KPI lift justified the workload trade off.
Why am I not seeing results in comparison testing after a few days?
The availability of GPR results depends on the selected KPI:
- Average Handle Time (AHT): Results are available immediately but become more meaningful after approximately two weeks of data collection.
- Next Contact Avoidance (NCA) and Net Conversion Rate: Results are available after the seven-day look-up period.
Predictive routing: License and permission requirements FAQs
Is predictive routing available in my Genesys Cloud instance?
Predictive routing is available in GC1, GC2, and GC3 with the AI Experience Bundle. It is included by default in GC4.
What permissions are required to view benefit assessment evaluation results?
A pre-benefit assessment can be run even if predictive routing is not yet enabled. To run one, make sure you have:
- Routing > Assessment > All permissions
- Routing > Key Performance Indicator > View
Predictive routing: KPI and queue configuration FAQs
Can we optimize for other KPIs than AHT with predictive routing?
Besides the standard AHT KPI, GPR supports revenue KPIs. Revenue KPIs include sales conversion, customer retention, customer churn, and sales value. Standard service KPIs include Average Handle Time (AHT) and Next Contact Avoidance (NCA).
For more information about revenue KPIs, see Revenue KPIs for Predictive Routing.
How can I establish a baseline for Next Contact Avoidance (NCA) optimization?
Unlike average handle time (AHT), Genesys Cloud does not currently provide queue-level NCA data that you can use to establish a baseline before enabling GPR. The Channel Insights dashboard in the Analytics workspace provides NCA data at the organization level by media type.
Genesys recommends running a benefit assessment to determine whether a queue is a good candidate for NCA optimization. Currently, there is no standalone queue-level data available to compare NCA performance before and after GPR optimization.
Can predictive routing improve average speed of answer (ASA) as well as AHT?
Predictive routing optimizes AHT (Average Handle Time) as a KPI and not average speed of answer (ASA). However, your ASA may change either way as a result of AHT.
How the ASA may improve: When predictive routing lowers AHT on a queue, agents free up faster, resulting in lower wait times. So ASA can improve as a byproduct of efficiency gains.
How the ASA may fall: When predictive routing briefly holds an interaction to wait for a better matched agent before opening it up to the wider pool. That short hold can make an individual wait slightly longer than standard routing would.
To avoid longer wait times to find the right agent, you configure a timeout routing method. This helps cut the waiting period. Genesys recommends that you run benefit assessment on queues to know the value of predictive routing on those queues. Queues with fewer agents or lower volume feel the hold time more than the capacity gains.
Does predictive routing consider an agent’s AHT across queues or only within a given queue?
When ranking eligible agents for an interaction, predictive routing contextualizes the AHT of the agent within the specific queue. Predictive routing does not consider an agent’s historical AHT across other queues that the agent serves.
What type of queue is best suited for Predictive Routing?
To know which queue can be best optimized with predictive routing, we recommend running a benefit assessment on the queues. Benefit assessment identifies queues with a high potential for optimization. Before you run benefit assessment, Genesys recommends that your queues have the following:
- At least 90 days of historical interaction data
- More than four agents assigned to the queue
Does predictive routing support outbound?
Predictive routing is only available for inbound queues.
How does the timeout setting affect predictive routing for a queue?
The timeout setting specifies how long Genesys Cloud attempts to route an interaction using predictive scores before it uses the backup standard routing option.
During the timeout period, predictive routing initially prioritizes the highest-scoring agents. If these agents are unavailable, it progressively expands the pool to include lower-scoring eligible agents. More of the timeout period is allocated to higher-scoring agents. Genesys Cloud waits approximately 25% of the timeout period for the agents with the highest score; it distributes the remaining period across the other agent score ranges, gradually reducing the time in each range.
For example, with a 20-second timeout, predictive routing uses the following approximate score ranges:
Predictive score range | Time |
90–100 | 5 seconds |
80–100 | 4 seconds |
70–100 | 3 seconds |
60–100 | 3 seconds |
50–100 | 3 seconds |
30–100 | 2 seconds |
If the timeout expires before an agent is selected, Genesys Cloud routes the interaction using the standard routing method.
What is the minimum timeout setting supported for predictive routing?
The minimum predictive routing timeout is 12 seconds. You can configure the timeout between 12 seconds and 259,200 seconds.
Predictive Routing: General concepts and functionality FAQs
What is Genesys predictive routing?
Genesys predictive routing uses machine learning to match each interaction with the eligible agent most likely to achieve the queue’s chosen business outcome. Unlike standard routing, it considers the best agent customer fit, not just who is available first. Each queue optimizes one KPI at a time, such as Average Handle Time, Next Contact Avoidance, or Revenue.
What is the best way to explain GPR to agents and operational teams?
GPR does not rate agents from best to worst. It estimates which available agent is the best fit for each interaction and the selected queue. Different agents can be ranked first for different customers and interactions.
Is GPR simply routing interactions to the fastest agent?
No. GPR does not maintain a universal ranking of agents based on speed. Instead, it uses a queue-specific model to predict how each eligible agent is likely to affect the selected KPI for a particular interaction.
For example, Agent A may have the lowest overall Average Handle Time (AHT) in the queue, but GPR may rank Agent B higher for a specific interaction based on factors such as customer contact history, agent performance, and similar historical interactions.
Or, when Next Contact Avoidance is the selected KPI, GPR may favor an agent who is more likely to resolve the underlying issue, even if that agent does not have the lowest AHT.
GPR uses multiple data points to determine the predicted agent-interaction fit rather than simply ranking agents by speed.
How does predictive routing differ from standard skill-based routing?
Predictive routing does not replace skills based routing. It works on top of it. Skills continue to decide who is eligible for an interaction, and predictive routing decides which of those eligible agents is the best fit.
Standard skills based routing is deterministic. It filters to the agents who hold the required skills at the required proficiency, then selects among them using a fixed rule such as longest idle or agent priority. Every agent who clears the skill bar is treated as interchangeable.
Predictive routing keeps that eligibility filter and then ranks within it. When skill matching is enabled on the queue, the required ACD skills still gate who is eligible. Predictive routing scores those eligible agents on how likely each one is to achieve the queue’s selected KPI for that specific interaction, and tries the highest scoring agents first.
The practical differences:
- Eligibility compared with ranking: skills determine who may handle the interaction, predictive routing determines which of them is the best fit.
- Fixed rule compared with a learned model: skills based routing applies the rule you configured. Predictive routing builds a model from the queue’s historical outcomes and retrains as new data arrives.
- Uniform compared with per interaction: a skills rule treats all qualifying agents alike. Predictive routing can rank different agents first for different customers and interaction types.
- Per queue scope: each predictive routing queue has its own model optimizing one KPI. There is no global cross queue ranking of agents.
- Fallback: if no suitable agent is found within the timeout, the interaction routes using your standard method, so behavior returns to what you have today rather than failing.
Adopting predictive routing does not require you to restructure your existing skills or proficiency assignments. They continue to serve the same purpose. To turn skill matching on or off per queue, see Configure skill matching.
Routing admin view: your existing skill model stays as it is. Enabling predictive routing changes how an agent is chosen from the eligible pool, not who is in the pool.
LoB owner or workforce manager view: the change is from “anyone qualified, whoever has been free longest” to “the qualified agent most likely to deliver the outcome selected for this queue.”
Does predictive routing work with bullseye routing?
No. Predictive routing does not support bullseye routing. However, you can use predictive routing with conditional group activation (CGA).
CGA dynamically adjusts the pool of eligible agents based on configured conditions, while predictive routing optimizes agent selection within the currently active pool.
For example, you can configure CGA to activate an overflow group when the estimated wait time (EWT) of the queue exceeds five minutes. When the condition is no longer met, that is the EWT falls below five minutes, CGA removes the overflow group. Predictive routing continues to select the best-fit agent from the eligible agents throughout this process.
In this configuration, CGA determines which agent groups are active, while predictive routing determines which agent is the best fit for the interaction from within the pool.
How does predictive routing select agents?
GPR can use multiple categories of agent, customer, interaction, and performance data. The features that the model uses can vary based on the queue, media type, available data, and selected KPI.
Genesys Cloud uses internal data sources, including the agent directory and analytics data. GPR can also use optional data from sources such as web surveys, sentiment analysis, external contacts, agent profile fields, participant data, and WEM external metrics.
Examples of data that GPR can use include:
| Data category | Examples |
|---|---|
Agent profile – Identifies agents’ experience, specialization and organizational context | Skills, language, department, tenure or hire date, employee type, and certifications |
Agent performance – Identifies agents past performance in terms of stronger outcomes in comparable circumstances
| Historical queue-level AHT, after-call work, transfer patterns, and other interaction outcomes |
Customer history – Provides context about the customer’s relationship with the contact center and the likely complexity of the interaction
| Repeat-contact history, number of previous contacts, and previous queue interactions |
Interaction and operational context – Helps determine the current operating situation
| Queue, media type, time period, interaction priority, waiting time, and available-agent conditions |
Customer or business attributes (Optional data) – Adds business context when these attributes are consistently supplied as participant data
| VIP indicator, contract type, intent code, or churn propensity supplied as participant data |
Experience data (Optional data) – Can help enrich the patterns available to the model when enough usable data exists
| Survey results, sentiment, and external contact information |
Workforce metrics (Optional data) – Can enhance the agent profile with performance measures maintained outside the core interaction data
| External agent performance or specialization metrics supplied through WEM Gamification integrations |
For optional attributes, Genesys recommends broad data coverage and consistent values. The model may not use attributes that contain insufficient data or values that are highly unique.
Can customers see which features influence predictive routing decisions?
Yes. Genesys Cloud provides model explainability information for predictive routing queues. The Predictive Model view shows the most influential features and groups them into agent, customer, and other feature categories.
Feature importance indicates how useful a feature is to the model when making predictions. However, it does not indicate that the feature caused an outcome. For example, low after-call work may be associated with lower AHT, but reducing after-call work alone does not necessarily result in lower AHT.
What factors influence predictive routing decisions?
Predictive routing decisions are based on a predicted agent score calculated for each interaction in real time. AI models use the following as inputs:
- Past interaction history
- Available agent profiles
- Participant data
Does predictive routing take skill levels into account, or do skill level reviews need to happen separately?
Yes. Administrators can turn skill matching on or off for individual queues configured to use the predictive routing method. Skill matching allows an organization to factor agent skill settings into routing decisions for inbound interactions, and includes all non language ACD skills associated with queue members. See Configure skill matching.
Can customers enhance predictive routing with external data?
Yes. Customers can inject external data as participant data at runtime routing, which can then be used as features for the predictive routing machine learning models.
Is customer intent required for predictive routing?
No. Predictive routing does not require intent detection or classification, and there is no prerequisite to deploy a bot, an intent model, or IVR intent capture before enabling it. The model learns from data the platform already holds for the queue: historical interaction outcomes, agent profile and performance, the customer’s previous contact history, and the operational context of the interaction.
Intent is optional enrichment. If an intent code is already derived elsewhere, for example from a bot, a menu selection, or a classification step in the flow, it can be supplied as participant data, and the model may use it as a feature. Two conditions apply, as they do to any optional attribute:
- Coverage must be broad. An attribute present on only a small proportion of interactions gives the model little to learn from.
- Values must be consistent. Highly unique or free text values are generally not usable as features.
Whether a supplied intent attribute makes a difference can be verified afterward. The Predictive Model view shows which features are influencing predictions, so administrators can confirm whether the attribute is being used rather than assuming it is.
For a routing admin: no flow redesign is needed to begin. If an intent attribute is already set, it can be passed as participant data, and the Predictive Model view can be checked later to confirm whether the model uses it.
For a workforce manager: predictive routing does not depend on an intent or NLU project being completed first. It can start from the interaction history already available.
Can the model be guarded against favoring calls that are too short, for example, assuming that one to two minute calls are optimal?
Yes. The model scores agents based on how likely they are to achieve the selected KPI, not on call length alone. For AHT, the model learns from historical patterns and recognizes that extremely short calls, such as transfers or misroutes, do not represent true success, so it does not prioritize them. See How the AI model scores agents for Predictive Routing.
Could predictive routing pull in quality evaluation scores from managers into the decision model?
No. Quality evaluation scores are not consumed by GPR models automatically.
Why does predictive routing data model retraining fail?
Retraining fails due to insufficient data for certain media types, because of a reduced number of interactions on the queue since activation. For more information, see Predictive routing during KPI processing phase.
Why does predictive routing fail to activate correctly?
An error occurs either because of insufficient data to create a data model or because of an unlikely system error. For more information, see Predictive routing during KPI processing phase.