Max как запасной канал: что технически нужно, чтобы перенести туда общение с клиентами

Задачу «а давайте продублируем нашего бота в Max» сейчас получают маркетологи в половине компаний, у которых есть хоть какая-то коммуникация в мессенджерах. Формулировка обычно именно такая, через «просто продублировать».

Про стратегическую сторону написали уже все. Про техническую почти никто. А там ровно те места, где сроки и бюджет разъезжаются с ожиданиями руководства.

Расскажем, как эта задача выглядит со стороны разработки.

Сначала о том, почему это не пустая суета

К июню 2026 года в Max больше 125 миллионов зарегистрированных пользователей, ежедневная аудитория превышает 77 миллионов человек, суточный объём переписки перевалил за полтора миллиарда сообщений. Платформа входит в реестр российского ПО и в список социально значимых сервисов.

Это уже не «ещё один мессенджер», это инфраструктура. Дальше вопрос только в том, делаете вы переезд заранее и спокойно или срочно и дорого.

Главное заблуждение: «код же почти тот же»

Тут и ломается большинство планов.

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

С мини-приложениями та же история. Концептуально это близко к тому, что вы знаете по Telegram Web Apps, но SDK другой: приложение подключает библиотеку MAX Bridge и работает через собственный объект в браузерном окружении. Опытная команда переносит фронтенд за несколько дней, но именно переносит, а не копирует.

Отдельный сюрприз ждёт тех, у кого бот написан на Python. Официальная поддержка сделана под Java и Go, потому что основные клиенты платформы это банки и госструктуры. На Python работать можно, никто не запрещает, но через голые HTTP-запросы к эндпоинтам и вебхуки, без готовой библиотеки. Для команды это означает больше кода и больше времени на отладку.

Что не переносится вообще

А вот эта часть чаще всего становится неприятным открытием уже после релиза.

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

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

Организационные мелочи, о которых не предупреждают

Три вещи, которые всплывают в процессе и сдвигают сроки.

Подключиться к партнёрской платформе могут только резиденты РФ: юридические лица, ИП и самозанятые. Если у вас бот заведён на физлицо-подрядчика или на иностранную структуру, начинать придётся с оформления.

Бот проходит модерацию. Расширенные настройки и возможность подключить мини-приложение открываются только после неё. Закладывайте это в план релиза, а не узнавайте в день запуска кампании.

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

Как не построить два продукта вместо одного

Самая дорогая ошибка выглядит так: одна команда поддерживает телеграм-бота, вторая делает такой же в Max, и дальше каждая доработка делается дважды.

Правильно устроенный переезд выглядит иначе. Вся бизнес-логика живёт в вашем бэкенде: сценарии, состояния диалога, интеграции с CRM, база пользователей. Мессенджер при этом становится транспортом, тонким слоем, который принимает и отправляет сообщения. Тогда добавление второго канала это не второй продукт, а ещё один адаптер.

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

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

Сколько это стоит и сколько занимает

Ориентиры по рынку на начало 2026 года. Простой бот с заявками, ответами на частые вопросы и уведомлениями, без интеграций – от одной до двух рабочих недель. Бот с подключением к CRM – две-четыре недели. Бот вместе с мини-приложением, где есть каталог, корзина и оплата, – от месяца до двух. Перенос уже работающего телеграм-бота обычно занимает одну-три недели и сильно зависит от того, как написан оригинал.

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

Что имеет смысл сделать на этой неделе

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

Проверьте, на кого оформлен бот и есть ли у компании доступ к партнёрской платформе.

Прикиньте, откуда возьмётся аудитория в новом канале. Не «люди перейдут», а конкретные точки: баннер на сайте, QR в чеке, строка в письме.

И решите, что вы вообще переносите. Дублировать весь функционал редко нужно. Часто достаточно уведомлений и приёма заявок, а тяжёлое мини-приложение можно отложить.

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