Multiple agents are experiencing a new behavior that started today (as best we can tell) - when doing a warm transfer, the agents are speaking to prompt a human detection well before the call actually connects to the human recipient. It’s usually about ~9 seconds before the transfer target picks up, as you can see from this screenshot. The original caller experiences a long, awkward silence during this time.
Checking transcripts from this time last week, with agents on the exact same version/settings, does not show this issue, but it is affecting multiple agents as of today and end users have escalated the issue back to us. Changing hold music did not seem to help eliminate the awkward silence on the originally caller’s end, and we don’t see any additional settings that we think would help solve this issue.
The example screenshot is call call_8f621baef550667905ae1717d0c, agent agent_fb7a62cd4852bfa793c53f2c1e (and examples of additional agents affected today are agent_c23e2c04fd0b881e70f7feaf6c and agent_e0d6e15440977eb2ec6339befa).
Hey @S0003771 I’ve escalated this issue to our team for further investigation.
We’ll keep you updated as soon as we have more information.
Best regards
Hello @S0003771 Thanks for the detail and the example call — it helped pin this down.
What we found on call_8f621baef550667905ae1717d0c:
- The transferee leg answered cleanly ~3.8s after dial — the bridge itself is healthy.
- The line at 2:44 (“Hello, is anyone there?”) is not the post-bridge greeting. It’s a built-in human-detection probe that fires 8s after the destination picks up if no human voice has been classified yet on that leg.
- On this call the destination was silent for ~20s after answering — the first audible words were “Thanks for Kevin.”, which reads like an automated greeting/disclaimer. That silence is what tripped the 8s probe.
- The proper post-bridge handoff line ran only after a human was detected, in the correct order.
The direct fix: set optOutHumanDetection: true on the warm_transfer transferOption. That disables the 8s probe entirely, so the original caller won’t hear that prompt during a destination IVR / silent-pickup window. Your three affected agents currently have it set to false, which is why the probe is armed.
On the “started today on multiple agents” pattern: we want to be straight that we haven’t yet identified a code path that would have changed probe behavior for your config in the last 24h — the field that controls it is preserved by recent changes, so the regression driver isn’t confirmed. It’s possible the destination-side behavior (IVR timing on the receiving numbers) shifted and is now consistently exceeding the 8s window. Setting optOutHumanDetection: true will eliminate the symptom either way; we’ll keep digging on the root cause and circle back if we find a backend-side trigger.
Thank You
