> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/enqueue.md).

# Enqueue phase in Dialogue Studio

Use the enqueue phase in Dialogue Studio to control queue behaviour after a caller enters the waiting queue.

Use the enqueue phase to control what happens after a caller enters the waiting queue and before the conversation connects to an agent.

The **Enqueue** action selects a skill from Incoming routing. **Queued Callback** is also requested from Incoming, with a selected skill. This page describes its downstream queue effects, not an action to place in this phase. See [Callback Journeys](/contact-center-configuration/building-your-callflow/callback-journeys.md#dialogue-studio-queued-callback).

{% hint style="warning" %}
If you plan to use queued callback, configure and validate regular callback first.
{% endhint %}

## When this phase runs

The **Waiting queue** node triggers when an incoming audio call enters the waiting queue.

| Output path      | Purpose                                                            |
| ---------------- | ------------------------------------------------------------------ |
| Customer Session | The queued caller session and current endpoint context             |
| Position Change  | Queue-position values such as current, previous, and best position |

## Prerequisites

* You can open the target Dialogue Studio flow for the contact center and edit the dependent configuration surfaces referenced on this page.

## How to use this phase

Use the enqueue phase to manage the waiting experience after a caller is queued, including queue messages, queue-position prompts, long-wait handling, and callback branches.

## Queue the caller to a skill

The **Enqueue** action sends the session to a configured skill.

This action can use either:

* a skill defined directly on the node
* a skill passed in through the payload

{% hint style="info" %}
Add a catch node so the flow can recover when the configured skill does not exist or the session payload is incomplete.
{% endhint %}

See [Configure a Catch Node](/product-reference/dialogue-studio/dialogue-studio-example-flows/configure-catch-node.md) for a worked error-handling pattern.

## Treat queued callback as a queue-related branch

After the Incoming **Queued Callback** action, the queue-related journey:

* reuses the caller's contact details when possible
* asks for contact details if they are not already known
* places the callback request behind callers who are already waiting
* can fall back to a regular callback if the queued callback attempt is not completed successfully

These are downstream queue effects. Regular callback must already be configured before you use queued callback.

## Design notes for the enqueue phase

Keep this phase focused on the waiting experience.

Good practice in this phase is to:

* separate queue-position prompts from long-wait handling
* keep the skill handoff explicit and easy to trace
* test the exception path for missing or incorrect skill data
* verify queue-related callback behaviour independently from the normal queue path

## Verification

1. Confirm the queued caller enters the intended skill.
2. Confirm queue-position prompts or announcements play in the intended order.
3. Test one long-wait or escape path.
4. If queued callback is enabled, test both the callback branch and the unanswered-callback fallback.

## Related topics

Go to **Route calls and queue messages** for the broader routing and queue configuration patterns that surround this phase.

{% content-ref url="/pages/ZO573ktrsGDDLCZRkVy3" %}
[Route Calls and Queue Messages](/contact-center-configuration/building-your-callflow/route-calls-and-queue-messages.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/enqueue.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.