---
title: "Operator queue cascade"
description: "How operator queue reminders work in Scenario Builder: steps, relative delays, messages, branches, aliases, and automatic stop when an operator joins."
---

# Operator queue cascade

**Operator queue cascade** sends reminder messages while a client waits for an operator. Use it after the queue branch of **Connect to operator**, when the chat already exists but no operator has joined yet.

The cascade does not connect an operator by itself. It keeps the waiting flow active: sends messages, runs scenario branches, or starts aliases on a schedule.

## How it works

A cascade contains steps. In each step you define:

- how long to wait after the previous step;
- whether to send a message to the client;
- what to do after the step: do nothing, go through an event branch, or start an alias.

Delays are **relative to the previous step**, not absolute from cascade start. If you set 3, 3, and 3 minutes, step 1 runs at about 3 minutes, step 2 at about 6 minutes from start, and step 3 at about 9 minutes.

## When the cascade stops

In the usual queue flow, the cascade stops automatically:

- when an operator joins the chat;
- when the chat is closed in OperatorLine;
- when the scenario reaches another queue cascade node with **Stop cascade** selected.

A separate stop node is only needed when another scenario event should stop reminders before an operator joins. For example, the client chooses not to wait, switches to another channel, or moves to self-service.

## Messages, branches, and aliases

A step can only send text, or it can also change the scenario route:

| Option | When to use it |
|--------|----------------|
| **No transition** | The step only sends a reminder. |
| **Event branch** | The reminder should continue into another block: file, image, clarification, or service action. |
| **Alias** | The scenario should start a prepared alias. |

If an event branch sends an extra message or action, the active cascade should not restart from the beginning because of a regular client message. It continues with the next scheduled steps.

## After the last step

After the final reminder, you can:

- stop the cascade;
- repeat the last step;
- repeat from the first step.

For an operator queue, repeating the last step is usually the practical option: the client keeps receiving the final reminder until an operator joins.

## See also

- [Configure operator queue cascade](/en/scenariobuilder/how-to/configure-operator-queue-cascade.md)
- [Operator queue cascade parameters](/en/scenariobuilder/reference/operator-queue-cascade-parameters.md)
- [Live operator in a dialog](/en/scenariobuilder/explanation/connect-to-operator-node.md)
- [Use action in scenario](/en/scenariobuilder/how-to/use-action-in-scenario.md)