In-queue flows overview

AI-generated summary

Genesys Cloud provides in-queue flows to customize customer experience during queue wait times across call, email, and message interactions. For call flows, the platform includes a default in-queue flow featuring hold music that can be customized with actions such as informational messages about call volume, processing updates, and company information. The in-queue flow uses Task actions to build process behavior, with Menus and Reusable Tasks unavailable in this flow type. The default call in-queue flow must be published before use and cannot be deleted or have its name or description edited, though administrators with appropriate permissions can modify its behavior. Email and message interactions do not include built-in default in-queue flows but support custom flows with auto-responses to update customers on queue position at specified intervals. In-queue email and message flows have a maximum duration of 72 hours before disconnection, and Architect limits open in-queue flows to 30 per interaction to prevent size increases. In-queue flows do not launch for outbound email or message interactions until an inbound response arrives. Recurring states add time intervals between executions to prevent interaction overloading, with in-queue message flows operating on an initial ten-second cycle and in-queue email flows implementing a 60-second initial period. Recurring states execute every five minutes of flow runtime plus an additional five-second wait increment. The system can cancel wait periods when participant attributes are updated outside of flow execution, triggering automatic execution of the recurring state. Customized hold experiences for in-queue message and email flows can include auto-responses updating customer queue position at regular intervals or transferring customers to alternative in-queue flows after specified timeframes. Required permissions include Architect > Flow > Add, Edit, and View capabilities, allowing users with appropriate permissions to customize default flow behavior for in-queue interactions through queue settings.

PrerequisitesClick to expand

Use an in-queue flow to customize the customer experience while they wait in a queue for an agent. You can configure in-queue flows for call flows, email flows, and message flows.

In-queue call flow

In call flows, Architect supplies a built-in default in-queue flow, but you can create and use other in-queue flows to suit your company specifications and preferences. Some examples of a customized hold experience during a voice interaction include:

Hold music.
A message playback about call processing, “We are currently experiencing higher than normal call volume.” or “Calls are processing in the order received. We appreciate your patience.”
Message playback that includes additional information about the company, “Did you know that you can also access online support at www.company.com?”
A combination of actions to make up a complete audio experience.

The in-queue flow uses a feature set similar to other flow types, except it is built into inbound or outbound calls. The in-queue flow uses a Task action to build and create the process that makes up the flow behavior. Menus and Reusable Tasks are not available in this flow. By default, the in-queue flow contains a single changeable music action, which you can change, and add more actions to tailor the experience.

About the default in-queue call flow

The default in-queue flow is not automatically published. To use this flow to handle calls waiting in the queue, you must first publish it.

You cannot delete the default in-queue flow or edit the name or description of the default in-queue flow. However, if you have the Architect user editor or admin permission assigned to your role, then you can modify the default behavior according to your flow design.

In-queue email and in-queue message flows

While similar to the in-queue call flow, Architect does not include a built-in, default in-queue flow for email and message interactions. For more information, see Create and configure queues.

Some examples of a customized hold experience during an in-queue message or email interaction include:

Use an auto response to update messaging customers every 30 seconds to let them know their position in the queue.
After a specific amount of time, transfer the customer to another in-queue message flow.

Notes:

For in-queue email and in-queue message flows, the maximum flow duration is 72 hours. After 72 hours, the flow disconnects.
For email and message flows, Architect limits the number of in-queue flows that open for a particular email or message interaction to 30. This limitation prevents the interaction size from increasing due to the launch of a new flow each time a Transfer to ACD action runs. The problem can occur when the target queue is the current queue.
If the initial email or message is an outbound interaction, the in-queue flow for the interaction does not launch even if it is set as default on the queue that the message is sent on behalf. The in-queue flow launches only after an inbound response arrives.

Recurring states

The overall periods for in-queue message flows is initially ten seconds. The overall period for in-queue email flows is initially 60 seconds. In these in-queue flows, recurring states run for every five minutes of flow runtime and then the system adds an additional five seconds to the wait period.

In some cases, an exception can cancel the wait time. For example, if the participant attributes are updated on the conversation outside of the flow execution, the current wait period will be cancelled, and the recurring state executes automatically.

[NEXT] Was this article helpful?

Get user feedback about articles.