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.
After an operator joins, the same node can move to a second phase — the operator idle phase (the form section «Оператор мовчить»). It sends the client a message when the operator is already in the chat but has not replied for a long time. You enable this phase separately in the node settings. For this phase, the node must run not only on the queue branch but also when an operator joins immediately — see Operator idle phase.
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.
If the operator idle phase is enabled in the node, only the queue reminders stop when an operator joins. After that, the node watches whether the operator replies to the client.
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.
Operator idle phase
The queue is not the only pause when a client may feel forgotten. Sometimes the operator has already joined but is checking details, and the answer is delayed. The operator idle phase covers this pause: if the operator does not reply to the client within the set time, the client gets your message.
The countdown starts when an operator joins the chat: manually, through automatic distribution, or after a chat transfer. The delay of the first phase step counts from that moment, and later steps count from the previous step. If queue reminders ended earlier, the phase still starts after the operator joins. A node can contain only this phase, without queue steps.
The phase tracks operator silence from the client's point of view. That is why a public operator reply, which the client sees, restarts the countdown from the first step. An internal note is not visible to the client, and a client message does not mean the operator replied, so neither changes the countdown. The bot sends the automatic message, so it is not counted as an operator reply either.
The phase is also tied to the operator who handles the chat. After a transfer to another operator, the countdown starts over for the new operator. If the operator leaves the chat without closing it, or the chat is returned to the queue, the phase waits for the next operator to join. When the chat is closed, the phase stops and no message is sent.
These rules apply while the phase is running. For a summary table, see What changes the countdown.
After the last phase step, the selected mode applies. Stop cascade ends the phase: even if the operator goes silent again, no new messages are sent. Repeat last step sends the last message at the interval set in Repeat delay while the operator stays silent. A public operator reply restarts the countdown from the first step.
The phase works only when Stop when operator joins is enabled in the node and the operator idle feature is enabled for your platform.
An operator can also join immediately, without a queue. That is why the cascade node is connected not only to the queue output of Connect to Operator but also to the other outputs listed in Requirements. The node belongs after this action: if you place it before the action, the phase does not start for a client who contacts you again.