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:

1. Training: Models are retrained nightly.
2. Prediction: Expected values, bounds, and deviations are calculated for the day ahead, broken into 15-minute intervals.
3. Inference: Every 15 minutes, actual results are compared against the prediction.
4. 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.