Конструктор чат-ботов: как собрать сценарий для веб, Telegram, VK и MAX

Большинство конструкторов чат-ботов ставят выбор между двумя крайностями. Либо вы перетаскиваете квадратики и получаете очередное дерево ответов, которое не умеет разговаривать с вашими системами. Либо вы открываете редактор кода, осваиваете ещё один YAML-диалект и неделю собираете то, что никто в команде потом не сможет отредактировать. Конструктор Связио визуальный, но у него есть запасной выход для каждого серьёзного требования: валидируемые вводы, ветвления, реальные HTTP-вебхуки с маппингом ответа, переменные, переходящие из шага в шаг, и передача живому оператору в любой момент.

Один и тот же сценарий работает на всех поддерживаемых каналах: веб-виджет на сайте, Telegram-боты, сообщества VK и каналы MAX. Inline-клавиатуры отрисовываются нативно на каждой платформе. На каналах без клавиатур (например, Авито) кнопки автоматически превращаются в нумерованный текст, чтобы клиент мог ответить «1» или «2». Вы собираете сценарий один раз, а движок сам разбирается, как его «произнести» на каждом канале.

Зачем визуальный конструктор вместо кода и дерева ответов

Главное преимущество визуального редактора — не в том, что «его может редактировать не-разработчик». Есть более тонкие выигрыши:

Сценарий читается как схема. Любой член команды — руководитель поддержки, продакт, маркетолог — открывает редактор и за 30 секунд понимает, что делает бот. Кодовое описание бота надо читать. Визуальный сценарий воспринимается как формы. Это сокращает ревью с дней до минут.

Края и исключения имеют своё место. Классическое дерево решений разваливается под живым трафиком, потому что у каждого интересного сценария есть циклы, повторы, таймауты и передачи оператору. В Связио всё это явно разводится по веткам: упавший вебхук идёт в error-ветку, невалидный ввод запускает повторный запрос, таймаут сессии открывает диалог в инбоксе оператора. Всё видно и привязано к конкретным нодам.

Переменные делают бота stateful. Каждая нода input пишет в переменную. Каждый вебхук может замапить части ответа в переменные. Каждая следующая нода умеет подставлять их в сообщения: «Здравствуйте, {{name}}, ваш заказ {{order_id}} уходит завтра». Бот запоминает информацию, а не начинает с нуля на каждом шаге.

Каналы, где работает один и тот же сценарий

Веб-виджет общается через Socket.IO. Telegram и MAX принимают inline-клавиатуры. VK использует свой формат keyboard. Движок переводит каждую ноду в нужный транспорт: buttons превращается в inline_keyboard на Telegram, в payload keyboard на VK, в Socket.IO-событие на виджете. Вы видите один сценарий независимо от того, где он запустится.

Как устроен сценарий

Каждый сценарий начинается с единственной ноды «Старт». Дальше ноды соединяются стрелками: у каждой ноды 0 или 1 входящее ребро и 1 или больше исходящих. Ноды могут ветвиться, сливаться обратно и закольцовываться — движок просто идёт по рёбрам по одному шагу за раз.

Редактор с выбранной нодой «Кнопки». Слева — палитра нод. В центре — сценарий. Справа — свойства выделенной ноды.

Слева — палитра доступных типов нод. В центре — холст со сценарием. Справа — свойства выделенной ноды. Изменения сохраняются по клику Сохранить, уходят в прод по Опубликовать. Черновик и опубликованная версия разделены — можно спокойно править, не ломая работающий бот.

1. Нода «Сообщение»

Типичное использование: приветствие с именем посетителя, подтянутым из его профиля в виджете, а перед следующим вопросом — пауза. Задержка ограничена на уровне сервера (0–10 секунд), чтобы никто случайно не «подвесил» сессию.

2. Нода «Кнопки»

Кнопки — это основной способ ветвить сценарий. Меню из трёх пунктов («Заказы / Поддержка / Вопросы») порождает три отдельные ветки, в каждой может быть совершенно своя логика. Движок ждёт клик, учитывает rate-limit (30 событий в минуту на сессию), а на Telegram/MAX после клика убирает inline-клавиатуру, чтобы клиент не нажал второй раз.

3. Нода «Ввод» (с валидацией)

Нода «Ввод» настроена на сбор email: переменная email, тип валидации Email, плейсхолдер намекает на ожидаемый формат.

Валидация строгая, но помогает клиенту: email-чек отсекает явно кривые адреса, phone-чек принимает международные форматы и нормализует их, text-чек просто требует непустой ответ. Нода держит сессию, пока ответ не пройдёт проверку. Если клиент молчит дольше таймаута, бот передаёт диалог оператору вместо того, чтобы висеть бесконечно.

Собранные здесь переменные становятся доступны всем последующим нодам. Следующее сообщение может обратиться к клиенту по имени, вебхук — вставить email в payload, а финальная нода «Действие» — записать ответ в профиль, чтобы данные сохранились и после окончания диалога.

4. Нода «Условие»

Условия превращают данные в управление потоком. Клиент написал «отмена» в свободном вводе? Ведём в сценарий отмены заказа. В профиле отметка «возвращающийся клиент»? Пропускаем вводное приветствие. Вебхук вернул status = "vip"? Отправляем в приоритетную очередь. Доступны все ожидаемые операторы: равенство, неравенство, содержит, начинается с, численные больше/меньше, булевы true/false, regex для нестандартных случаев.

5. Нода «Действие» (передача оператору, переменные)

Передача оператору — критичный момент. Задача бота обычно не в том, чтобы заменить оператора, а в том, чтобы квалифицировать, собрать данные и направить в нужный отдел. assign_department отдаёт диалог нужной команде (Продажи, Поддержка, Биллинг), assign_agent закрепляет за конкретным оператором, а close помечает диалог как решённый, когда бот сам довёл его до конца (проверил статус доставки, ответил на частый вопрос). Для клиента это выглядит как бесшовное продолжение — просто дальше отвечает уже человек.

set_visitor_field работает тише, но не менее важен. Он пишет в постоянный профиль посетителя. Email, который бот собрал, становится email-ом профиля. Телефон — телефоном. В следующий раз, когда клиент вернётся — с любого канала — эти данные уже будут на месте.

6. Нода «Задержка»

Задержки — разница между ботом, который кажется клавиатурным шорткатом, и ботом, который воспринимается как разговор. 300–800 мс между короткими сообщениями обычно достаточно. Более длинные паузы (2–3 секунды) хорошо работают перед сообщением, подтверждающим работу: «секунду, проверяю ваш заказ», — особенно если вы заодно вызываете вебхук.

7. Нода «Вебхук» (HTTP в ваши системы)

Эта нода превращает Связио из «игрушечного» чат-бота в платформу интеграций. Найти заказ в вашем бэкенде, запросить CRM, пинг-нуть лояльность, вызвать GPT-completion — всё, что умеет HTTP, умеет и нода «Вебхук». URL, заголовки и тело поддерживают подстановку переменных, поэтому каждый вызов учитывает контекст текущей сессии.

Типичная конфигурация:

После отработки ноды {{status}}, {{tracking}} и {{customer_tier}} становятся доступны всем следующим шагам. Чаще всего следующий шаг — нода «Условие», которая ветвит сценарий по status == "shipped" или customer_tier == "vip".

У ноды два исходящих ребра: success (HTTP 2xx) и error (4xx/5xx, таймаут, SSRF-блок, битый ответ). Если error-ветка не подключена, ошибка падает на default-ребро — сценарий не зависнет молча.

Переменные и шаблоны

Переменные — связующий клей. Каждая нода input, каждое поле responseMapping у вебхука, каждое set_variable-действие пишут в session.variables. Каждая нода message, buttons, URL и тело вебхука могут их читать через {{имя}}. Работает и точечная нотация: если вебхук замапил весь ответ в переменную order, позже можно обратиться к {{order.tracking.url}}.

Жёсткие лимиты (чтобы сессия не раздулась):

• До 100 переменных на сессию
• До 2 000 символов на значение
• Лог прохождения (для аналитики) — до 500 переходов между нодами

В нормальных сценариях эти лимиты не достигаются. Они нужны на случай «патологического» цикла, который пишет в переменные, пока не кончится память.

Три рабочих сценария, которые можно скопировать

Сценарий 1. Квалификация лида для SaaS

Цель: задать три вопроса, оценить лида, тёплых отдать в продажи, холодных — в онбординг.

1. Старт → Сообщение («Привет! Короткий вопрос: что привело вас к нам сегодня?»)
2. Кнопки (Цены / Интеграции / Просто смотрю) → сохраняем выбор в intent
3. Ввод (email, тип email) → в email
4. Ввод (размер команды: 1 / 2–10 / 11–50 / 50+) → в size
5. Условие: intent == "Цены" И size != "1" → ветка «тёплый лид»
6. Действие: assign_department(Продажи) в тёплой ветке
7. Сообщение в холодной ветке («Спасибо! Вот обзор, который может пригодиться: [ссылка]»)
8. Действие: close после холодного сообщения

Время сборки: ~10 минут. Без кода. Одинаково работает на сайте и в Telegram.

Сценарий 2. Проверка статуса заказа для интернет-магазина

Цель: клиент спрашивает про заказ, бот проверяет его в бэкенде магазина, возвращает трек, отдаёт оператору если что-то не так.

1. Ввод (номер заказа, тип text) → order_id
2. Ввод (email из заказа, тип email) → email
3. Задержка (1500 мс) + Сообщение («Проверяю...»)
4. Вебхук → GET https://api.shop.ru/orders/{{order_id}}?email={{email}}, мапим status и tracking_url
5. Ветка success: Сообщение («Ваш заказ {{status}}. Трек: {{tracking_url}}») → Кнопки («Всё ок, спасибо» / «Есть проблема»)
6. «Всё ок»: Действие: close
7. «Есть проблема» или ветка error вебхука: Действие: assign_department(Поддержка)

Сценарий 3. Ночной бот, который передаёт утренней смене

Цель: работает, только когда все операторы оффлайн; собирает минимум данных, кладёт «тикет» в Telegram-канал для утренней смены.

Запускается по условию триггера operators_offline = offline (это в настройках запуска бота, не нода сценария). Сам сценарий — простой:

1. Старт → Сообщение («Мы сейчас оффлайн, но утром обязательно вернёмся к вам.»)
2. Ввод (email) → Ввод (в чём вопрос?)
3. Действие: set_visitor_field(email) + (телефон, если собран)
4. Вебхук → POST в Telegram-канал сводной информации — утренняя смена видит всё сразу
5. Действие: close

Передача оператору и контроль сессии

Последнее слово всегда за оператором. В каждом диалоге с активной сессией бота в дашборде появляется баннер: «Бот X ведёт диалог» и кнопка «Остановить». По клику сессия переходит в HANDED_OFF, все ожидающие inline-клавиатуры в Telegram и MAX убираются, диалог помечается как требующий внимания. Дальше отвечает оператор.

Это не просто «стоп-кран». Это основная интеграция между ботами и людьми. Рутину ведёт бот; оператор подключается, когда начинается интересное. Все переменные, собранные ботом, остаются видны оператору — он не начинает с чистого листа.

В движке в фоне работают несколько страховок:

• Lock в Redis сериализует одновременные клики по кнопкам, чтобы клиент не смог «раздвоить» бот двойным тапом.
• Rate-limit ограничивает сессию до 30 событий в минуту — от случайных или вредоносных скриптов.
• Cron-обход раз в минуту закрывает сессии, которые давно ждут ответа и превысили свой таймаут — диалог возвращается оператору, ничто не зависает.

Тариф и лимиты

Чат-боты — функция тарифа Про. В Про также входят ИИ-ассистент, триггеры и автосообщения, отделы, аналитика, безлимит операторов, 10 Telegram-ботов, VK, MAX и возможность убрать брендинг Связио. На все платные тарифы 7 дней триала без привязки карты.

Посмотреть тарифы полностью или сразу зарегистрироваться.

Частые вопросы

Что почитать дальше