Designing Proactive Outbound Notifications for SLA Breaches to Support Supervisors

How-To-Articles
1

Designing Proactive Outbound Notifications for SLA Breaches to Support Supervisors

What This Guide Covers

  • Breaking away from passive dashboard monitoring where supervisors must stare at a screen to notice that a queue is failing.
  • Architecting an event-driven notification pipeline using the Genesys Cloud Analytics Notification API, AWS EventBridge, and external messaging platforms (Slack/Microsoft Teams).
  • The end result is a proactive operational environment where supervisors are instantly “pushed” an alert on their mobile devices the moment a queue breaches its Service Level Agreement (SLA), enabling rapid intervention.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1, 2, or 3.
  • Permissions: Analytics > Queue Observation > View, Integrations > Integration > Edit.
  • Infrastructure: AWS EventBridge (or a webhook consumer like AWS Lambda) and an incoming Webhook URL configured in Slack or Microsoft Teams.

The Implementation Deep-Dive

1. The Problem with “Stare-and-Compare” Management

In traditional contact centers, Floor Supervisors sit in front of wallboards or dashboard screens. If the “Billing Queue” SLA drops below 80%, the dashboard turns red.

The Trap:
This relies entirely on human visual attention. If the supervisor is coaching an agent, on a lunch break, or simply looking at the wrong tab, the SLA breach goes unnoticed until customers start complaining on social media. Operations must move from a “Pull” model (looking at a dashboard) to a “Push” model (receiving a targeted alert).

2. Architecting the Event Stream

Genesys Cloud calculates queue statistics in near real-time. We must tap into these calculations without building a resource-heavy polling script.

Implementation Steps:

  1. The EventBridge Integration: Navigate to Admin > Integrations and ensure Amazon EventBridge is configured and active.
  2. The Analytics Topic: You must subscribe to the queue observation metrics topic. The specific topic string is:
    v2.analytics.queues.{id}.observations
    (Replace {id} with your specific Queue ID, or use * to subscribe to all queues and filter downstream).
  3. The Metric of Interest: The JSON payload published to this topic contains real-time aggregates. You are looking for the metric oServiceLevel. This metric is an object containing ratio (e.g., 0.85 for 85%), numerator, and denominator.

3. The Serverless Evaluation Logic (AWS Lambda)

EventBridge will stream every change in the queue metrics. You need a middle layer to evaluate these metrics against your specific business thresholds.

Architectural Reasoning:
If you send an alert to Slack every time the SLA drops by 1%, the supervisor will suffer from alert fatigue and mute the channel. You must implement Thresholds and Cooldowns.

Implementation Steps (The Python Lambda):

import json
import boto3
import requests
import time

# DynamoDB table to store the last time we alerted (Cooldown mechanism)
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('SLA_Alert_Cooldowns')

SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/T0000/B000/XXXX"
SLA_THRESHOLD = 0.75 # Alert if SLA drops below 75%
COOLDOWN_MINUTES = 15

def lambda_handler(event, context):
    # 1. Parse the EventBridge Payload
    detail = event['detail']
    queue_id = detail['queueId']
    
    # 2. Extract the SLA Ratio
    # Note: The payload contains an array of data. We must find the oServiceLevel metric.
    sla_ratio = None
    for metric_obj in detail['data']:
        if metric_obj['metric'] == 'oServiceLevel':
            sla_ratio = metric_obj['stats']['ratio']
            break
            
    if sla_ratio is None:
        return # SLA metric not present in this specific event payload
        
    # 3. Evaluate the Threshold
    if sla_ratio < SLA_THRESHOLD:
        
        # 4. Check the Cooldown
        response = table.get_item(Key={'QueueId': queue_id})
        last_alert_time = response.get('Item', {}).get('LastAlertTimestamp', 0)
        current_time = int(time.time())
        
        if (current_time - last_alert_time) > (COOLDOWN_MINUTES * 60):
            # 5. Send the Alert!
            send_slack_alert(queue_id, sla_ratio)
            
            # 6. Update the Cooldown
            table.put_item(Item={'QueueId': queue_id, 'LastAlertTimestamp': current_time})

def send_slack_alert(queue_id, sla_ratio):
    message = {
        "text": f"🚨 *CRITICAL SLA BREACH* 🚨\nQueue `{queue_id}` has dropped to a Service Level of *{round(sla_ratio * 100, 1)}%*.\n<https://apps.mypurecloud.com/directory/#/engage/dashboard|Click here to open the WFM Dashboard and re-skill agents immediately.>"
    }
    requests.post(SLACK_WEBHOOK_URL, json=message)

4. Refining the Alert for Operational Impact

A raw Queue ID (e.g., a1b2c3d4-....) is useless to a supervisor in a panic. The alert must be human-readable and actionable.

Enhancement Steps:

  1. Dynamic Queue Names: The Lambda function should make a quick GET /api/v2/routing/queues/{queueId} call to the Genesys Cloud API to resolve the UUID into a human-readable name like “Tier 2 Technical Support”.
  2. Deep Linking: Include a direct URL in the Slack message that immediately opens the Genesys Cloud Queue Activity Dashboard for that specific queue. The supervisor clicks the link on their phone, the Genesys App opens, and they immediately see exactly which calls are holding.
  3. Escalation Tiers: If the SLA stays below 75% for 15 minutes, send the alert to the Floor Supervisor channel. If it drops below 60%, trigger an AWS SNS alert that texts the VP of Operations directly.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Morning Start-Up” False Positive

  • The Failure Condition: At 8:01 AM, the contact center opens. The very first call of the day abandons after 10 seconds. The SLA for the queue instantly drops to 0%. The Lambda script blasts an emergency “0% SLA” alert to the entire executive team. Panic ensues over a single abandoned call.
  • The Root Cause: Statistical variance is extreme when the sample size (the denominator) is incredibly low.
  • The Solution: Implement a Minimum Volume Threshold in your evaluation logic. The Lambda script must check the denominator of the oServiceLevel metric. If the denominator is less than 50 interactions, bypass the alert logic entirely. The SLA metric only becomes statistically relevant after a sufficient baseline of calls has occurred.

Edge Case 2: The Silent Recovery

  • The Failure Condition: An alert fires at 1:00 PM stating the SLA is 70%. The supervisor drops what they are doing, rushes to their desk, logs in, and sees the SLA is actually 85%. They assume the alerting system is broken.
  • The Root Cause: The queue recovered rapidly (e.g., a burst of 10 fast calls came in right after the alert), but the system only alerts on failures, not recoveries.
  • The Solution: Implement a Recovery Notification. When the SLA drops below the threshold, log a State = BREACHED flag in DynamoDB. On subsequent EventBridge payloads, if State == BREACHED and the new sla_ratio > 0.80, send a green “:white_check_mark: SLA RECOVERED” message to Slack and reset the state. This closes the loop for the operations team.

Official References