Without knowing more about how audio is configured, your flow architecture or any constraints in place, we can mainly speak to the platform capability.
The Play Estimated Wait Time action will use:
- The flow's Text-to-Speech (TTS) settings, if TTS is configured in that flow
- Otherwise, it falls back to the organization's default TTS voice
It does not use user-recorded audio prompts, as the value is dynamically generated.
So in practice:
- If your flows are using TTS → the voice comes from the flow-level (or org default) TTS configuration
- If you haven't explicitly set TTS at the flow level → it will use the org-level default
This also means any change at the flow level only impacts that specific flow, whereas org-level changes impact all flows using the default.
If you choose to use Call.EstimatedWaitTime for manual playback, you would need to explicitly retrieve and refresh that value before each time you play it (for example via a Data Action, Update Data or similar step) and then reference it in your audio/TTS. Otherwise, it may not reflect real-time queue changes
------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------
Original Message:
Sent: 03-17-2026 11:39
From: Balaji Balakrishnan
Subject: Technical Inquiry: Manual EWT Calculation Logic in In-Queue Flows
Hi Josh,
Thank you for the detailed insight and for taking the time to share these best practices.
I completely recognize the technical advantages of the native "Play Estimated Wait Time" action-specifically the "never-increasing" logic and the sophisticated historical analytics it provides. However, my pivot toward a manual calculation was driven by a specific architectural constraint regarding Voice Branding.
Currently, other Lines of Business (LOBs) within our org utilize Male system prompts. For my current Proof of Concept (POC), we are required to use a Female voice. My primary concerns are:
Global Impact of System Prompt Overrides: If I modify or override the default system audio for EWT to a female voice, it will globally affect all other LOBs, which is not an acceptable outcome for the broader business.
Granular Audio Control: Manual calculation allows me to use Task-level variables and specific TTS (Text-to-Speech) engine settings or custom prompts that align with our LOB's persona without touching the global settings.
Is there a recommended way to leverage the built-in EWT logic while maintaining LOB-specific voice/audio profiles? For instance, does Genesys support Flow-level audio overrides for the EWT block that wouldn't impact the rest of the organization?
I appreciate your guidance on how to balance real-time accuracy with our specific branding requirements.
------------------------------
Thanks,
Balaji B
Original Message:
Sent: 03-17-2026 10:10
From: Josh Coyle
Subject: Technical Inquiry: Manual EWT Calculation Logic in In-Queue Flows
Hi Balaji Balakrishnan
For the most accurate and consistent EWT announcements, the best practice is to use the "Play Estimated Wait Time" action during In-queue flows rather than manually calculating and playing Call.EstimatedWaitTime.
The main reasons are:
- Sophisticated calculation: The built-in action uses historical analytics (e.g. handle time, abandon rates, offered volume) combined with real-time queue conditions to determine a more accurate estimate.
- Customer experience safeguards: It automatically applies "never-increasing" logic so callers don't hear their wait time go up.
- Automatic handling: It manages refresh behaviour and announcement formatting without additional logic.
- Flexible playback options: Supports Approximate, Less Than, Padded, and Precise modes.
If you do need full control over playback, an alternative is to retrieve EWT dynamically via a Data Action (queue EWT API) on each loop iteration rather than relying on Call.EstimatedWaitTime.
https://help.genesys.cloud/articles/add-an-estimated-wait-time-action-to-a-task/
------------------------------
Josh Coyle
Senior Professional Services Consultant
Original Message:
Sent: 03-17-2026 09:38
From: Balaji Balakrishnan
Subject: Technical Inquiry: Manual EWT Calculation Logic in In-Queue Flows
Hi Genesys Developer Community Team,
I am currently testing a manual Estimated Wait Time (EWT) calculation within an in-queue flow, but the values are not updating as expected in real-time.
The Scenario: I am using the expression if(IsNotSetorEmpty(Call.EstimatedWaitTime),0,(ToInt(ToInt(Call.EstimatedWaitTime)/60000))) to play the EWT in minutes. During testing:
Call 1 announced 6 minutes.
Call 2 announced 12 minutes.
After Call 1 was answered and completed, Call 2 continued to report 12 minutes rather than reflecting the reduced wait time.
Key Questions:
Does the Call.EstimatedWaitTime variable automatically refresh while a caller is in a loop, or is it static upon entry?
What is the best practice for ensuring real-time EWT accuracy when not using the built-in "Play Estimated Wait Time" block?
I would appreciate any guidance on how to ensure the EWT dynamically updates based on real-time queue activity.
#Architect
#DataActions
#PlatformAPI
#Uncategorized
------------------------------
Thanks,
Balaji B
------------------------------