Implementing Real-Time Adherence (RTA) Monitoring for Remote Asynchronous Workers

How-To-Articles
1

Implementing Real-Time Adherence (RTA) Monitoring for Remote Asynchronous Workers

What This Guide Covers

  • Architecting a robust Real-Time Adherence (RTA) framework for agents handling non-voice, asynchronous Workitems in Genesys Cloud CX.
  • Configuring WFM Activity Codes and Status Mapping to prevent “ghost” adherence alerts for back-office and asynchronous digital tasks.
  • Implementing an automated notification pipeline for adherence exceptions using the Genesys Cloud Notification Service and EventBridge.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 3 or CX 1/2 with the WEM Add-on. Work Management features require a Work Management license.
  • Permissions:
    • Workforce Management > Adherence > View, Edit
    • Work Management > Workitem > View, Edit
    • Notification > Subscription > Create
  • OAuth Scopes: wfm, workmanagement, presence, notifications.
  • Infrastructure: Access to the Genesys Cloud Developer Center for API testing and a middleware environment (e.g., AWS Lambda, Node.js) for consuming EventBridge streams if external alerting is required.

The Implementation Deep-Dive

1. Defining the Asynchronous Work Landscape in WFM

The fundamental challenge with asynchronous workers-those handling emails, back-office claims, or offline tasks-is that their productivity isn’t measured by “Talk Time.” In Genesys Cloud, these tasks are best handled via Work Management (Workitems). However, WFM adherence traditionally looks for a “Presence” or “Routing Status” that matches a “Scheduled Activity.”

To support async RTA, you must first create a specific Activity Category for Asynchronous Work.

The Configuration:

  1. Navigate to Admin > Workforce Management > Activity Codes.
  2. Create a new code: Async Task Processing.
  3. Set the Category to Workitem or Busy (depending on whether you want them “On Queue” for workitems or purely dedicated to offline tasks).
  4. The Trap: Avoid mapping asynchronous activities to the On Queue category unless the agent is actually assigned to a Queue-based media type. If you map a back-office worker to On Queue but they are working in a third-party CRM or a Genesys Workitem that doesn’t trigger a “Routing Status” of Interacting, the RTA engine will flag them as Out of Adherence (Unscheduled Status) because they are Available but not “On Queue” for a specific interaction type.

2. Mapping Presence and Routing Status for Async Adherence

RTA in Genesys Cloud is a comparison of two states: Schedule vs. Actual.

  • Schedule: “The agent is supposed to be doing Async Task Processing from 09:00 to 11:00.”
  • Actual: “The agent’s current Presence is Busy and Routing Status is Idle.”

To make RTA work for async workers, you must configure the Status Mapping within the WFM Business Unit.

The Implementation:

  1. Go to Admin > Workforce Management > Business Units > [Your Unit] > Activity Code Mapping.
  2. For the Async Task Processing code, map the allowed System Presences.
  3. Include Busy, Meeting, and potentially a custom presence like Processing Tasks.
  4. The Trap: If you use a custom Presence for async work, ensure it is enabled for the specific division the agents reside in. A common failure mode is creating a “Back Office” presence that is only visible to the Admin division, causing agents in the “Customer Service” division to default to Available when they can’t find the correct status, immediately triggering an adherence violation.

3. Monitoring Workitem Adherence via API

For high-maturity organizations, simply seeing a “Green” status in the WFM UI isn’t enough. You need to know if the agent is actually interacting with the workitems assigned to them during their async window.

You can use the Notification Service to stream adherence changes to an external dashboard or supervisor alert system.

API Implementation (WebSocket Subscription):
First, create a channel:
POST /api/v2/notifications/channels

Then, subscribe to the adherence topic for a specific user:
POST /api/v2/notifications/channels/{channelId}/subscriptions
Payload:

[
  {
    "id": "v2.users.{userId}.workforcemanagement.adherence"
  }
]

The payload you receive will look like this:

{
  "topicName": "v2.users.6f7...adherence",
  "eventBody": {
    "user": { "id": "6f7..." },
    "adherenceState": "OutToUnscheduled",
    "actualPresence": "Available",
    "scheduledActivityCodeId": "async_task_123",
    "systemPresence": "Available",
    "routingStatus": { "status": "IDLE" }
  }
}

Architectural Reasoning:
We use the OutToUnscheduled state to trigger immediate supervisor intervention. For remote async workers, the most common “theft of time” isn’t logging off-it’s staying in an Available or Idle state without actually picking up Workitems. By streaming these events to a middleware like AWS EventBridge, you can trigger a Slack alert if an agent remains OutToUnscheduled for more than 5 minutes.

4. Handling Cross-Platform Nuances (NICE CXone)

If you are managing this in a hybrid environment or migrating to NICE CXone, the logic shifts from “Presence Mapping” to State Mapping within the WFM module. NICE CXone uses “Real-Time Adherence Data Feed” (RTAD) to push these updates.

The Trap in CXone:
In CXone, if an agent is handling an “Offline” work type, the system often defaults to an “Available” state in the agent application. You must explicitly configure the ACD State to WFM Activity mapping in the NICE CXone Central. Failure to do this results in “Adherence Blindness,” where the system sees the agent as “Available” (waiting for a call) instead of “Working” (processing an async task).

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Ghosting” Workitem

Failure Condition: The agent is working on a long-lived Workitem (e.g., a complex insurance claim) that stays open for 4 hours. The agent is scheduled for a “Break” at the 2-hour mark.
Root Cause: Genesys Cloud RTA sees the “Routing Status” as Interacting (because the Workitem is open) but the “Schedule” as Break. This results in a “Severe” adherence violation.
Solution: Implement Auto-Status Management via the SDK. When an agent moves to a “Break” activity in WFM, the middleware should check for open Workitems and either:

  1. “Park” the workitem (moving Routing Status to Idle).
  2. Update the WFM schedule via the PATCH /api/v2/workforcemanagement/managementunits/{muId}/schedules/... endpoint to delay the break.

Edge Case 2: Presence Sync Lag

Failure Condition: Remote workers using a VPN experience 10-15 second delays in Presence updates. RTA flags them as “Late” for every shift start.
Root Cause: The RTA engine is hyper-sensitive to the timestamp of the status change vs. the schedule start time.
Solution: Configure Adherence Thresholds in the Business Unit settings. Set the “Severe” threshold to 5 minutes and the “Warning” to 1 minute. This suppresses noise caused by network latency or slow application boot-up times on remote workstations.

Edge Case 3: Mapping “Available” to “Working”

Failure Condition: For certain asynchronous channels (like Chat or Message), an agent is “Available” while waiting for the customer to reply. WFM marks them as “In Adherence” for “On Queue” work, but their productivity looks like zero.
Root Cause: RTA only measures presence, not utilization.
Solution: This is an architectural trap. Do not use RTA to measure work quality. Use Performance Management (Gamification) metrics to track “Workitems Handled” alongside RTA. If RTA is 100% but Workitems Handled is 0, you have an “Active Idle” worker.

Official References