Agent Scripting Timeout Handling and Occupancy Calculation in EU-West BYOC

Is it possible to configure a specific timeout behavior for Agent Scripting tasks that prevents them from artificially inflating the ‘Occupancy’ metric in the Real-Time Performance dashboard? The organization is operating within the EU-West BYOC environment. We have recently migrated our agent guidance workflows from static PDFs to the native Agent Scripting feature within Architect flows. While the functional delivery of information is consistent, we are observing a significant discrepancy in the reported agent utilization metrics. Specifically, when an agent initiates a complex scripting sequence that involves multiple conditional branches and external data lookups, the dashboard registers the agent as ‘On Call’ for the entire duration of the script execution, even if the agent is technically idle while waiting for asynchronous data actions to complete. In the previous architecture using external web widgets, the occupancy calculation was tied strictly to the voice/media leg, resulting in a more accurate reflection of active handling time. With the native scripting, the ‘Active’ state persists until the final script node is closed. This creates a scenario where an agent appears to have 95% occupancy during peak hours, whereas the actual talk time and auxiliary code usage suggest a much lower figure, closer to 70%. The business stakeholders are concerned that this inflated occupancy metric is leading to incorrect workforce forecasting models. We have reviewed the ‘Queue Activity’ and ‘Agent Performance’ views, but there does not appear to be a granular setting to exclude ‘Script Navigation’ time from the core occupancy calculation. Is there a recommended architectural pattern or a specific flow configuration that allows us to pause the occupancy timer during non-interactive scripting phases, or is this a known limitation of the current metric definitions in the EU-West region? We need to ensure that the performance data fed into the WFM module accurately represents productive handling time rather than system-induced wait states.