Hi Cody,
From what I understand, the main trade-off here is less about platform stability and more about how much call classification you are willing to sacrifice in exchange for faster agent connection.
The 4–5 second delay you are seeing can indeed be related to the post-connect analysis performed before Genesys decides whether the answering party is a live person, voicemail/answering machine, fax, etc.
One important distinction is that disabling AMD is not exactly the same as disabling Post-Connect Call Analysis (PCA).
If you disable Answering Machine Detection, Genesys stops using the general speech-based AMD mechanism, but tone and audio-print detection can still remain available. According to the Genesys documentation, this can significantly reduce the time required to classify a call while still identifying a meaningful portion of answering machines through those other mechanisms.
On the other hand, if you disable Post-Connect Call Analysis, AMD is also disabled and Genesys no longer waits for post-connect events such as live voice, machine, busy, or fax classification. That provides the fastest connection path, but the functional trade-off is that more voicemail/recorded-message scenarios may reach the agent.
So I would probably test this progressively rather than immediately disabling everything:
-
Keep PCA enabled and test Adjustable Live Speaker Detection (ALSD), starting with Low or Medium.
-
If the delay is still unacceptable, test PCA enabled + AMD disabled.
-
Only then test PCA disabled, understanding that this effectively prioritizes connection speed over post-connect classification.
There is another part of the call path that may also be worth checking: how the interaction is delivered to the agent after the call has already been classified.
The queue's Alerting Timeout itself is not a delay Genesys intentionally adds before delivering the call. It is simply the amount of time an agent has to answer an offered interaction before being placed into Not Responding and the interaction is routed again.
What can remove that agent-answer step is Auto Answer.
For progressive outbound queues, enabling Auto Answer at the queue level can be particularly useful because the interaction can connect automatically as soon as an available agent is selected, without requiring the agent to manually accept it. I would prefer configuring this at the queue level rather than changing agent behavior globally, especially if those agents also handle inbound interactions.
I would also verify two additional items:
-
Persistent Connection, if applicable to the phones/endpoints being used, as this can reduce the time required to establish the agent-side media path for each new outbound call.
-
Whisper Audio on the queue. If a whisper prompt is configured, two-way communication with the customer does not begin until that prompt finishes, so a few seconds of whisper audio can sometimes look exactly like a call-analysis delay.
So, for troubleshooting, I would break the 4–5 seconds into stages:
Call answered → PCA/AMD/ALSD → ACD routing → agent alerting/Auto Answer → whisper → media connection
That should help determine whether the entire delay is really being introduced by AMD/PCA or whether part of it is occurring after Genesys has already classified the call.
I would be very interested to see the timings from each of those test combinations, because for a high-volume progressive campaign, PCA enabled + AMD disabled or ALSD tuning may be a better compromise than completely disabling post-connect analysis.
------------------------------
Fernando Sotto dos Santos
Consultor de Atendimento Senior Grupo Casas Bahia
------------------------------