Looking for advice on resolving a specific metric alignment issue within the Performance Dashboard concerning WebRTC softphone handoffs. Our EU-West BYOC environment utilizes Architect flows to manage complex inbound routing, specifically involving a “Warm Transfer” action followed by a “Hold” state while the agent prepares the context for the receiving party.
The problem manifests as a divergence between the actual conversation duration recorded in the Conversation Detail View and the “Talk Time” metric displayed on the Agent Performance widget. When an agent initiates a warm transfer via the WebRTC softphone, the dashboard registers the transfer initiation time as the end of the talk time. However, the agent remains on the call, listening to the bridge, for an additional 30 to 45 seconds before the final disconnection. This gap is not being captured as “Talk Time” nor is it consistently categorized under “Hold Time” in the real-time performance views.
This discrepancy creates significant reporting inaccuracies for our workforce management team, as they rely on these metrics to calculate average handle time (AHT) and agent efficiency. The issue appears isolated to calls routed through a specific Architect flow version (v14) that employs a custom data action to tag the interaction before the transfer.
Below is the relevant configuration snippet from the flow where the handoff occurs:
actions:
- id: warm_transfer_initiate
type: transfer
target:
queueId: "support-queue-02"
transferType: warm
data:
transferContext: "pre-approved"
- id: post_transfer_hold
type: hold
duration: 45000
reason: "agent-preparation"
We have verified that the WebRTC client logs show continuous RTP packets during this bridge phase, indicating the connection is active. The question is whether the Performance Dashboard logic in the EU-West region has a known limitation regarding how it parses the state transition from “Transferring” to “Holding” in conjunction with WebRTC softphone events. Has anyone encountered similar metric fragmentation when using warm transfers in this specific cloud region?