Can anyone clarify the precise logic used for Occupancy calculation when digital messaging conversations are routed through complex Architect flows in our EU-West BYOC environment? The organization relies heavily on performance dashboards to monitor agent efficiency, yet there is a persistent discrepancy between the time agents spend handling digital interactions in the queue versus the final reported occupancy metric. Specifically, when a flow involves multiple bot handoffs and conditional routing steps before connecting to an agent, the Real-Time Performance dashboard appears to capture the entire flow duration rather than isolating the active agent handling time. This inflation of the occupancy percentage significantly impacts our service level reporting and workforce management forecasts. The current configuration utilizes standard digital channels with no custom API integrations, relying solely on native Architect routing capabilities. Detailed analysis of the Conversation Detail View confirms that the timestamps align with the flow execution, but the aggregation in the Performance View seems to include idle wait times within the bot logic. Is there a specific configuration parameter or flow design pattern recommended to ensure that only the actual agent interaction time contributes to the occupancy metric? The objective is to align the dashboard reporting with the operational reality of agent workload, excluding the computational overhead of the automated flow segments. Previous attempts to adjust the flow timeouts have not resolved the reporting variance, suggesting that the issue lies within the metric definition itself rather than the flow execution speed. Assistance in understanding how to structure these flows for accurate metric reporting would be greatly appreciated, as this discrepancy is currently affecting our quarterly performance reviews.