Prepare a voice robot queue

Before you start

Sign in as the organization owner. Prepare an enabled, registered UDP/TCP/TLS robot line and a published scenario version. A WSS browser line serves the additional browser phone.

Queues run autonomously through the robot. Human staffing, agent assignment and after-call work are not prerequisites. Queue concurrency is capped by the enrolled server robot and its license; editing the field cannot increase that capacity.

Click path

1. Open Очереди (/queues) and click Новая очередь. Complete Название очереди; select Линия робота, Сценарий and Опубликованная версия.
2. Set Одновременных разговоров and Ожидание входящего, с. Waiting occurs before the robot answers; waiting inbound calls receive released capacity in FIFO order.
3. Choose rejection or forwarding to a specified SIP destination after the wait expires. Forwarding routes the call onward without creating another robot conversation.
4. Review the outbound time zone, calling window, weekdays and excluded dates. Set attempts, retry delays, answer timeout and maximum duration. New campaigns copy this policy.
5. If recording is required, enable Записывать вызовы этой очереди, complete Документированное основание записи, attest the organization’s authority and choose retention. Recording is off by default. Screenshot examples use synthetic audio only.
6. Click Сохранить очередь and inspect the saved queue. For inbound calls, open Маршрутизация, select the matching line/number, queue mode and saved queue, then save the route.
7. Place an authorized test call and inspect waiting, active and ended states. For outbound calls, create a campaign.

Enlarge screenshot

1 2 3 4 5

1. Сохранить очередь
2. Линия робота
3. Опубликованная версия
4. Одновременных разговоров
5. Записывать вызовы

Verify and recover

The robot answers with the selected version. Capacity is released after physical end and confirmed media cleanup. Caller cancellation removes a waiting call; wait expiry executes its configured fallback.

Existing campaigns keep their copied policy/version when the queue changes. Review their snapshot before launch. Recording depends on the call policy, rather than supervisor presence.

If a line is missing, check robot mode and UDP/TCP/TLS transport. Publish a missing scenario version. An unavailable robot requires registration/runtime recovery; a higher form value cannot supply a missing server resource. After a revision conflict, refresh and compare settings before retrying. Unconfirmed physical end retains capacity until reconciled; do not bypass it with duplicate calls.

Check after connection recovery

Reopen the saved queue and verify the same line, published version and incoming-call state. Keep the existing queue and route while the server runtime is unavailable. After registration recovers, place one authorized synthetic test call and verify the robot’s answer, physical call end and released capacity.

For outbound calling, resume the existing campaign after reconciling its attempts. An infrastructure restart does not replace checking the actual call result and availability of any permitted recording.