Botmother сравнивают со своим ботом по переносимости сценариев между мессенджерами

Учебный бот записывает на услугу: человек выбирает её, оставляет контакт и получает подтверждение. CTO хочет добавить второй мессенджер, сохранив правила записи. «Один сценарий» здесь означает тот же выбор услуги и тот же заказ в учётной системе.

В Botmother для этого есть целевая платформа компонента. В документации приведён экран, где кнопки Viber работают только в Viber, а для других платформ добавлены свои кнопки. Структура экрана общая, способы показать выбор разные.

Различается и поведение похожих компонентов. По инструкции Botmother кнопки с подсказками в MAX находятся над полем ввода, а в Telegram клавиатура расположена под ним. Во ВКонтакте этот компонент не позволяет запросить контакт. Если без контакта заказ невозможен, для такого канала нужен другой способ его получить.

В собственном коде общий сценарий можно хранить отдельно. Он получает выбор услуги и контакт, проверяет условия записи и создаёт заказ. Адаптер канала переводит нажатие кнопки в этот выбор и показывает человеку ответ. При добавлении мессенджера меняют адаптер.

Репозиторий сам по себе эту границу не создаёт. Если правило записи встроено в обработчик кнопки Telegram, разработчик скопирует его в обработчик следующего канала. Потом в одной копии изменят условие, а в другой забудут. Код принадлежит компании, но сценарии уже расходятся.

Есть и промежуточный вариант. Компонент «Запрос» в Botmother обращается к внешнему API; документация требует JSON для запроса и ответа. Правила заказа можно вынести во внешний сервис, оставив диалог в конструкторе. Для нашего учебного примера это способ проверить границу до полного переноса бота.

Для агента задача должна описывать эту границу: «добавь MAX, сохрани правила заказа, проверь результат». В задании приложите одинаковые случаи для выбранных каналов. Задание «перепиши бота» не определяет результат. Как сформулировать его и принять работу, разбираем в постановке задач агенту.

До заказа переноса попросите вендора перечислить доступные артефакты. Нужны отдельно схема переходов и условия, данные пользователей, состояния незавершённых заказов, файлы и сведения об интеграциях. Полученный файл следует открыть и проверить: что из этого в нём есть и чем его можно исполнить вне сервиса.

В общих настройках Botmother описано дублирование бота внутри аккаунта. Оно копирует структуру, но не диалоги и данные пользователей; подключения платформ надо настроить заново. Это помогает повторить бота в конструкторе, но не подтверждает перенос в собственную программу.

Другие выгрузки тоже решают отдельные задачи. CSV со списком экранов перечисляет экраны, а экспорт подписчиков относится к пользователям и переменным. На странице экспорта подписчиков есть примечание о временной работе через поддержку. Подтверждения экспорта исполняемого сценария во внешний код в проверенных инструкциях мы не нашли.

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

На vibecoding.ru инженер ведёт машину агентов: задаёт правила, принимает изменения и превращает найденные ошибки в проверки. Распределение работы видно в публичной машине разработки. Это наш собственный проект; его масштаб не измеряет скорость переноса чужого бота.

В цепочке оплаты и Telegram-доступа выяснилось, что право на продукт и отправка уведомления не должны зависеть друг от друга. Иначе сбой письма нельзя исправить без новой выдачи доступа. Это тот же принцип для учебного заказа: подтверждение можно отправить повторно, сохранив один заказ.

В материалах курса агентной разработки общая очередь публикаций получила отдельное подключение Telegram. Урок с прежней площадкой требовал заранее подготовленных аккаунтов, а подключение нового выхода разобрали отдельно. Общая очередь сохранилась; настройку канала пришлось пройти заново.

Для сравнения ботов нужен более узкий довод: кто проверяет один и тот же результат в выбранных каналах. Агент может подготовить адаптер и проверки, инженер принимает поведение. Кто отвечает за ошибку после этой приёмки, разбираем отдельно в статье про ответственность за ошибки ИИ.

Возьмите один важный путь, например запись на услугу, и назовите нужные мессенджеры. Зафиксируйте, какой заказ должен получиться, кто считается пользователем и что происходит при повторе действия. Так подрядчик получает результат, который можно принять.

Первой задачей сделайте карту общей логики и зависимостей канала. Попросите показать доступные выгрузки, затем собрать выбранный путь в целевых каналах. Для учебного заказа критерий один: услуга и контакт сохраняются, повторная команда не создаёт лишнюю запись.

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

Следующий шаг для руководителя — проверка задачи до разработки: на странице услуг можно обсудить выбранный сценарий и способ приёмки.

Собрать переносимую часть логики и проверить адаптацию к выбранным каналам можно в подписке на разработку. На 8 октября 2026 «Один проект» стоит 250 000 ₽ в месяц: инженер ведёт машину агентов, выполняет по одной задаче из очереди в репозитории клиента. Пауза возможна в любой месяц. Это цена подписки, а не оценка готового бота или обещанный срок переноса.

1. Назовите общий результат: какое правило и какой заказ сохраняются при смене мессенджера.

2. Отделите правила заказа от кнопок, сообщений и идентификаторов канала.

3. Проверьте состав выгрузки. Копия бота и CSV ещё не доказывают экспорт исполняемого сценария.

4. Примите один путь в выбранных каналах, включая повтор команды и сбой уведомления.

5. Зафиксируйте, кто проверяет результат и поддерживает адаптеры после запуска.