Prerequisites

The following permissions:

  • Architect > Flow > Add
  • Architect > Flow > Edit
  • Architect > Flow > View

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.

Note: For email and message flows, Architect limits the number of in-queue flows that open for a particular email or message interaction to 10. 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.

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.