We’re on Zoom Contact Center, and we’re seeing inconsistencies with ACTUAL_TIME reporting in WEM. It’s impacting our SERVICE_LEVEL reporting, so we need to figure this out. The problem seems to be with how agent states are being interpreted when an agent transitions during a call - specifically when they move from AVAILABLE to NOT_READY while still actively handling a call.
The issue isn’t consistent across all agents. It’s popping up mostly with agents who frequently use auxiliary work codes while on calls - things like HOLD, CONFERENCE, or even just quick NOT_READY states for internal lookups. We’ve checked the AGENT_STATUS in the Zoom Contact Center ACD, and it looks correct - the agent is showing as handling the call, but WEM is inflating their ACTUAL_TIME spent in a NOT_READY state.
IF (AGENT_STATE == AVAILABLE) THEN
ACTUAL_TIME = CURRENT_TIME - START_TIME
ELSE IF (AGENT_STATE == NOT_READY) THEN
ACTUAL_TIME = CURRENT_TIME - START_TIME
ENDIF
That’s how we expect it to work, but it doesn’t. I suspect the WEM system isn’t properly tracking the ACD state changes while the call is still active. It feels like it’s interpreting the brief NOT_READY state as the entire time the agent was handling the call, even though they were mostly AVAILABLE during it.
We’ve looked at the REAL_TIME_ADHERENCE views, and it’s showing the agent as being in the wrong state for portions of the call. It’s not a simple misconfiguration of the WORKGROUP assignments. The ACTUAL_TIME differences are small - usually a few minutes per call - but they add up. For what it’s worth, we have several complex Architect flows managing call handling, with multiple IVR branches and skill-based routing. We’re using the Zoom Contact Center API to update AGENT_STATUS in real-time.
I’ve checked the API logs, and the state changes are being reported correctly to the Zoom Contact Center. It’s the interpretation of that data within WEM that seems to be wrong. The last SDK version we updated was about a month ago, but I haven’t found any release notes indicating a fix for this. SIDE NOTE: I can’t reproduce this consistently, which makes it even harder to debug. It seems to be intermittent.
That’s a tricky one! We’ve seen something similar - it’s often related to how the ACD state changes are being logged in WEM, especially during those quick transitions. From what I’ve seen, the ACTUAL_TIME calculation depends heavily on the timing of those state updates.
You should check the REPORTING_CONFIGURATION in your Zoom Contact Center instance - specifically, the ACD STATE_EVENT_THRESHOLD. It controls how long a state needs to be active before it’s considered a valid event for WEM. If it’s too short, it might miss those brief AVAILABLE to NOT_READY transitions!
Also, worth a shot - can you verify the agent’s TIMEZONE is correctly set in the AGENT_PROFILE? A mismatch there can throw off the timing. And make sure your WEM integration is pulling the latest ACD data - sometimes a manual sync can help!
The discrepancies you’re seeing with ACTUAL_TIME likely stem from event ordering within the Notification API stream - specifically, how quickly state changes are propagated and acknowledged during concurrent events. We’ve encountered this previously.
Are you subscribing to events at the user level (v2/users/{userId}/events) or the agent level (v2/agents/{agentId}/events)? Subscribing at the agent level can sometimes provide more granular state information, potentially reducing ambiguity during rapid state transitions.
To further refine the diagnosis, could you provide a sample of the WebSocket event sequence around the time of the state change? A log excerpt containing the BEFORE and AFTER states, alongside the timestamp of each event, would be beneficial. I’m particularly interested in the ordering of the acd.state and user.presence events. A screenshot of this log segment would be ideal.
Consider the WebSocket reconnection behavior. Frequent disconnections, even brief ones, can introduce event reordering. The SDK attempts to handle this, but it’s not always perfect. What is the typical reconnection interval you’re observing? Shortening the token TTL - as we did in the similar case involving abandon events - might help, although that’s a trade-off between token validity and event sequencing.
Regarding the REPORTING_CONFIGURATION and ACD STATE_EVENT_THRESHOLD, that’s a valid point. However, the Notification API operates outside of WEM’s configuration. The stream represents the real-time interpretation of events - it isn’t governed by reporting thresholds. Therefore, any adjustments there won’t address discrepancies in the raw event data.
Fun one today. That’s right, event ordering is key - but we’ve found the Notification API can be…optimistic.
Consider the Event Horizon: Zoom Contact Center’s event stream doesn’t guarantee arrival order. State changes can arrive out of sequence, especially during fast transitions.
SDK Pagination: If you’re using the Python SDK, ensure you’re handling pagination correctly for events - it’ll silently truncate otherwise. The API can return partial results if you don’t loop.
The conversational experience hinges on accurate state reporting, and it appears the ACD state event threshold - as As noted above - is the key. We’ve found that a lower threshold value - say, 2 seconds instead of 5 - can improve the granularity of state capture, though it also increases the volume of events processed. This may reduce discrepancies in ACTUAL_TIME, particularly during those quick transitions from AVAILABLE to NOT_READY while still handling a call. Apologies if this is obvious, I’m still learning the specifics of event processing.
From what I’ve seen, the reporting configuration’s impact on containment metrics is substantial. A misconfigured threshold can artificially inflate handle times, creating a perception of lower agent efficiency. It’s worth considering a phased rollout of any changes to the ACD STATE_EVENT_THRESHOLD, with a control group to validate the impact on both ACTUAL_TIME and overall SERVICE_LEVEL performance. It’s a bit of a balancing act, really.
