Overview of anomaly detection for monitored entities

AI-generated summary

Genesys Cloud's anomaly detection feature continuously analyzes queue performance to proactively identify unexpected behavior and emerging trends within 15-minute intervals, eliminating the need for supervisors to manually monitor dashboards. An anomaly is flagged when a queue's actual value deviates from its expected range for a specific 15-minute time slot, with confirmation required from at least two of three detection models: Isolation Forest, Z-Score, and Chronos LLM-based model. The system establishes baseline expectations through nightly model retraining, daily prediction calculations broken into 15-minute intervals, real-time inference comparisons every 15 minutes, and consensus validation across multiple models before publishing confirmed anomalies to the dashboard. The feature supports voice, message, email, and outbound queue interactions, excluding outbound/dialer campaign interactions. Queue eligibility requires sufficient historical interaction volume accumulated over several weeks to build reliable predictive models; administrators can monitor a maximum of 50 queues per organization and must identify eligible queues for monitoring. Detected anomalies are viewable through the Anomaly Detection Dashboard, enabling supervisors to efficiently identify mitigation steps. In practice, supervisors can use anomaly flags to make informed decisions such as reallocating agent resources to address emerging queue issues before they escalate. Genesys Cloud's anomaly detection capability enables proactive workforce management by identifying operational issues that standard dashboard monitoring might miss or detect too late. In a practical scenario, the system flagged a predicted staffing shortfall during afternoon peak hours based on updated demand forecasting. The administrator reviewed the anomaly alert and took corrective action by offering overtime to 10 agents before their shift change, allowing queue activity to stabilize by 5:00 PM. This demonstrates how anomaly detection functions as an early warning system that supports real-time decision-making for queue management and staffing optimization, enabling supervisors to address potential service disruptions before they impact customer experience.

Feature coming soon

What is anomaly detection?

Anomaly detection continuously analyzes queue performance to identify and surface unexpected behavior as it occurs. Instead of requiring supervisors to monitor dashboards for issues, anomaly detection proactively flags issues and emerging trends that may require attention. Based on an identified anomaly, the supervisor can efficiently identify the next steps to mitigate the situation.

What constitutes an anomaly?

An anomaly is flagged when a queue’s actual value falls outside its expected range for that 15-minute interval. A deviation only counts as an anomaly only if at least two of the three detection models agree that the value is unusual. The system does not compare a queue against one expected value for the whole day — it breaks the day into 15-minute time slots (9:00–9:15 am, 9:15–9:30 am, and so on), and each slot has its own expected value based on what is historically normal for that specific time of day.

Example: A Claims queue is typically expected to have around 40 calls offered between 9:00 and 9:15 am on a Tuesday. If only five calls come in during that slot, and at least two of the three models agree that’s outside the normal range, that 9:00–9:15 am slot is flagged as an anomaly.

How does Genesys Cloud detect an anomaly?

For each monitored queue, the Genesys Cloud builds a predictive model from historical data to establish an expected, baseline value on normal operating conditions. It builds the prediction in the following sequence:

Training: Models are retrained nightly.
Prediction: Expected values, bounds, and deviations are calculated for the day ahead, broken into 15-minute intervals.
Inference: Every 15 minutes, actual results are compared against the prediction.
Consensus: No single model can call something an anomaly by itself. The system currently runs three models: Isolation Forest, Z-Score, and a Chronos LLM-based model. An anomaly is only confirmed when at least two of the three agree that a data point is unusual.

Once confirmed, the anomaly is published as an event on the dashboard.

Which media types are covered?

The supported media types are voice, message, email, and outbound interactions from a queue. Outbound/dialer campaign interactions are not included.

Which queues can be monitored?

A queue needs enough historical interaction volume before the system can build a reliable model for it. A sustained average number of interactions per day over few weeks is required to build the prediction models. This means, although newer queues with less data can be enabled for anomaly detection, the results may not be usable. Administrators must identify the queues that are eligible for monitoring.

What can an administrator do to configure the feature?

As an administrator, view the list of entities that are eligible for monitoring and enable anomaly detection as required. You can monitor a maximum of 50 queues per org. For more information, see Enable anomaly detection in monitored entities.

Where can I view the anomalies that are detected?

To view the anomalies report, visit the Detected Anomalies dashboard. For more information, see the Anomaly Detection Dashboard.

What does this look like in practice?

Mark supervises a 300-agent homeowners and renters insurance business unit at a large insurance company, open 8:00 AM to 8:00 PM.

Morning: After reviewing their standard metrics and scheduling a couple of coaching sessions, Mark checks their anomaly detection dashboard, which flags unusual activity building up in the Claims queue. Based on the flag, Mark reviews agent skills, training, and performance profiles and decides to move four agents into the Claims queue. Mark informs them, and updates their queue activations.
Midday: Wait times are improving slightly, but anomaly detection flags something new: a staffing shortfall later in the day based on updated demand. Mark reviews the flag and decides to offer overtime to 10 agents before their 4:00 PM shift ends.
Afternoon: By 5:00 PM, with new agents added, the queue activity stabilizes.

In each case, the pattern is the same: anomaly detection notices something a dashboard review would have missed or caught too late and flags it for Mark to take corrective steps.

[NEXT] Was this article helpful?

Get user feedback about articles.