Dealing with a very strange bug here with the alignment of occupancy metrics for our digital messaging queues within the EU-West BYOC environment. Specifically, the Occupancy percentage reported in the Queue Activity dashboard for our primary customer support queue diverges significantly from the individual Occupancy metrics aggregated in the Agent Performance view.
The Queue Activity view indicates an average occupancy of approximately 85% during peak hours (10:00 AM - 12:00 PM CET), which aligns with our historical baseline. However, when aggregating the Occupancy data from the Agent Performance view for the same time frame and queue assignment, the calculated average sits at roughly 72%. This discrepancy suggests that the underlying calculation logic or the definition of ‘handled time’ versus ‘talk time’ may differ between these two reporting modules, or that certain conversation states are being excluded from one view but not the other.
This inconsistency complicates our capacity planning efforts, as we rely on the Agent Performance view to validate individual agent efficiency while using the Queue Activity view for macro-level resource allocation. We need to determine which metric is the source of truth for compliance reporting.
- Attempted to cross-reference the raw data in the Conversation Detail view for a sample of 50 conversations handled during the discrepancy window. The ‘Talk Time’ and ‘Wrap-up Time’ fields appear consistent, but the ‘Total Handled Time’ calculation seems to exclude pre-wrap idle time in one view but not the other.
- Verified that all agents in the queue are operating under the same routing strategy and that no custom scripting or flow logic is artificially altering the conversation duration metadata before it is committed to the analytics tables.
Has the team identified any known limitations or recent changes to the metric definitions for digital channels in the latest platform updates? We are looking for clarification on how Occupancy is derived for messaging queues to ensure our reporting is accurate.