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

Hello Maico,

Just do add something that I haven't seen in the previous comments:

As far as I'm aware, the Call.EstimatedWaitTime variable will update automatically every time the inQueue flow gets to the end (as it automatically loops back to the start). I think Camila mentioned above that the variable doesn't get updated if you build your own loop, and that's correct, but I just wanted to add that it will automatically update if you just use the default loop capability of the inQueue flows (which loops back to the start when getting to the end).

Also, as you mentioned, the variable is not supposed to ever increase in value (So if at any point it returned "5 minutes", it will never go above that value), but there are reportings in 2018~2019 threads in this community of this not working properly (So during tests, it would still increase in value)... But since that was a long time ago, this might not be the case currently. But make sure to test it to be sure.

And finally, just wanted to give some opinion regarding your plans. It sounds good to always be updating the customer, but unfortunately you might risk getting to "0" in your countdown, and then I'm not sure what you would tell the customer. Because if you just keep updating it to : "5 minutes... 4 minutes.. 3 minutes... 2...1... 30 seconds..", then what exactly do you say when it reaches 0?

You could say something generic like: "Your call will be answered at any moment now", but still it could take several more minutes until it's actually finally answered, as the initial EWT is just a estimation, so the initial "5 minutes" could end up being 6~7~8 minutes... Anyway, just something to keep in mind.

------------------------------
Marcello Jabur
------------------------------