Genesys Cloud - Developer Community!

Hi everyone,

I'm working on an in-queue flow where we need to inform customers of their estimated wait time verbally, and then repeat that announcement every 30 seconds while they're waiting.

The tricky part is that we want the announcement to reflect the remaining time – essentially, deducting the time the customer has already been waiting from the initial EWT. For example, if the EWT is 5 minutes, after 30 seconds the customer should hear "approximately 4 minutes and 30 seconds," and so on.

I understand the native Play Estimated Wait Time action has built-in safeguards that prevent the value from ever increasing , which is excellent for customer experience. However, I'm not sure if it automatically refreshes the value when placed inside a loop within the flow.

My main questions:

1. Does the Call.EstimatedWaitTime variable automatically update on each iteration of an in-queue flow loop, or is it static once the call enters the queue?

2. If it doesn't automatically refresh, what's the recommended approach to achieve this "countdown" behavior? I've seen mentions of using a Data Action to fetch the EWT via the Platform API on each loop iteration  – would that be the right path?

3. Are there any best practices or pitfalls I should be aware of when implementing periodic EWT announcements?

I'm aware the built-in action is designed to provide a good customer experience by never increasing the wait time , and I want to respect that logic while still giving customers accurate updates on their remaining wait.

Any insights or examples would be greatly appreciated!

Thanks in advance.

Achieving this "countdown" behavior in Genesys Cloud is a bit more complex than it seems, as the platform has specific behavior regarding the estimated wait time variable. There are two main approaches, each with its own advantages and disadvantages.

The most straightforward way-and the one recommended by the platform itself-is to use the "Play Estimated Wait Time" action. You can place it inside a loop that repeats every 30 seconds. The major benefit of this action is its intelligent "never increase" logic. This means that if the actual wait time increases (for example, due to priority calls), the system will never play a longer time than what was already announced, preventing customer frustration.

The key point is how Call.EstimatedWaitTime behaves inside a loop. Documentation and community insights indicate that if you create your own loop within the "InQueue" task, the value does not update automatically. To force an update, you have two options: The first is to add a "Play Estimated Wait Time" action configured with the NOT_SET expression to force an internal refresh of the variable without playing any audio to the customer. The second is to use a Data Action to call the queue's estimated wait time API (GET /api/v2/routing/queues/{queueId}/estimatedwaittime) on each iteration of your loop.

My suggestion is:

1. In your In-Queue flow, add a loop that repeats while the customer is still in the queue.

2. Inside the loop, place a "Wait" block (such as "Music on Hold" or "Play Audio") for the first 30 seconds.

3. Immediately after the wait, add the "Play Estimated Wait Time" action.

4. Keep the Estimated Wait Time (EWT) field with its default value, Call.EstimatedWaitTime.

5. Select a playback mode of your preference, such as Precise for the exact time, or Less Than for a more comfortable estimate.

6. To ensure the variable updates on each cycle, you can add an extra "Play Estimated Wait Time" action before the loop, configuring the EWT field with the NOT_SET expression (this will not play any audio but will force the value to refresh).

It's crucial to know that the Call.EstimatedWaitTime value should never be used for routing decisions (such as routing to a different queue based on time). The documentation itself warns that, because of the "never increase" logic, the value does not reflect real-time reality for that purpose-it is only intended to inform the customer. Additionally, some community members have reported that the NOT_SET technique didn't work in all cases, and it was necessary to use Call.EstimatedWaitTime itself to force the update. Be sure to test thoroughly in a staging environment.

I hope this helps you build your flow. If you have any further questions about implementation, the community is here to help.

Hi Maico,

We had a slightly different challenge because our agents work across multiple queues, so the native queue-level EWT wasn’t representative for us.

Instead, before the in-queue messages begin, we call a custom Data Action once. It queries the Analytics Conversation Aggregates API for the tWait sum and count across our relevant queues and calculates a combined weighted average wait time.

Rather than announcing an exact value, we use a padded range (±1 minute). For example, if the calculated average is around 3 minutes, we announce “approximately 2 to 4 minutes.” We’ve found this provides a more realistic expectation for customers while accounting for normal fluctuations in wait times.

It doesn’t provide a live countdown, but it has worked well for us where agents are shared across multiple queues and a single queue’s EWT isn’t representative.

Regards,

Phaneendra