Could someone explain the calculation logic behind the ‘Average Handle Time’ metric displayed in the Flow Performance view for a specific Decision block within our Architect flow?
Background
The organization is currently managing a BYOC setup in the EU-West region. We have recently optimized an inbound IVR flow designed to route high-priority customer inquiries. The flow utilizes a Decision block to evaluate the customer_tier attribute against a set of predefined conditions.
When analyzing the performance data for the 24-hour window ending 2023-10-27 23:59:59 UTC, the Flow Performance dashboard reports an Average Handle Time of 45 seconds for the Decision block itself. This figure appears inconsistent with the expected behavior, as a Decision block is a non-interactive element that should theoretically contribute negligible time to the overall handle time. The underlying queue activity metrics align with expected values, suggesting the issue is isolated to the flow-level aggregation.
We have verified that the customer_tier attribute is populated correctly via the external data source integration. Furthermore, no loops or delays are configured within the immediate path of this Decision block. The concern is whether the metric is inadvertently capturing the duration of subsequent blocks or if there is a latency issue with the attribute lookup that is being attributed to the Decision block.
Question
How is the handle time calculated for non-interactive blocks such as Decision or Assignment blocks in the Architect flow performance metrics? Is it possible to isolate the processing time of the Decision block from the subsequent queue wait times to ensure accurate performance reporting? Any clarification on the metric aggregation methodology would be greatly appreciated to ensure our dashboard configurations reflect true operational efficiency.