У вас работает Telegram-бот, и появилась задача запустить его и в MAX. Разберём, как устроить перенос бота из Телеграм в MAX так, чтобы не поддерживать два разных продукта: какая нужна архитектура, какие отличия платформ проверить, как узнавать одного клиента в двух мессенджерах и как запускаться без риска для работающего бота.
Перенос или второй канал
Слово «перенос» обманчиво. В большинстве случаев Telegram-бот никуда не уходит: клиенты к нему привыкли, сценарии отлажены. Задача — дать тот же сервис тем, кто пользуется MAX, и не превратить один продукт в два, которые разъезжаются с каждой доработкой.
Поэтому начинаем не с кода для MAX, а с аудита текущего бота. Отвечаем на вопросы:
- Насколько бизнес-логика отделена от кода, который работает с Telegram? Или вызовы Telegram API разбросаны по всем обработчикам?
- Какие возможности Telegram используются: инлайн-кнопки, платежи, Mini App, группы, файлы, форматирование?
- Где хранятся данные пользователей и как они связаны с CRM?
- Есть ли тесты и документация, или логика живёт только в голове предыдущего разработчика?
Если бот писали не вы и доступов не хватает, сначала стоит спокойно забрать проект — об этом статья о передаче проекта от другого разработчика.
Архитектура: общее ядро и адаптеры
Решение, к которому мы приходим почти всегда, — разделить бота на ядро и адаптеры платформ. Ядро ничего не знает о мессенджерах: оно получает событие «пользователь выбрал вариант X на шаге Y» и возвращает ответ «показать текст и такие-то варианты выбора». Адаптер переводит события конкретного мессенджера во внутренний формат и обратно.
| Ядро (общее) | Адаптер (свой для каждой платформы) |
|---|---|
| Сценарии и состояния диалога | Приём событий через webhook или long polling |
| Правила, расчёты, проверки | Преобразование событий во внутренний формат |
| База данных пользователей и заявок | Отправка сообщений, кнопок, файлов через API платформы |
| Интеграции с CRM, 1С, платёжными сервисами | Форматирование текста под возможности платформы |
| Тексты и настройки из админ-панели | Обработка ограничений и ошибок конкретного API |
Если текущий бот написан с жёсткой привязкой к Telegram, первый шаг — рефакторинг: вынести логику в ядро и оставить Telegram-адаптер. На этом этапе бот для пользователей не меняется, и это удобная точка проверки — всё должно работать как раньше. Только потом пишется адаптер для MAX на основе HTTP API, описанного на dev.max.ru.
Такая схема окупается на первой же доработке: новый сценарий пишется один раз и сразу появляется в обоих мессенджерах.
Какие отличия платформ проверить
Сценарий в ядре описан в общих терминах, но каждую возможность нужно сверить с тем, что умеет MAX. Ниже — список того, что проверяем. Колонка про MAX намеренно без конкретики: актуальные детали уточняются по документации платформы на момент работы.
| Возможность | Как в Telegram | Что проверить в MAX |
|---|---|---|
| Кнопки | Инлайн-кнопки под сообщением и клавиатура вместо поля ввода | Какие типы кнопок есть, сколько их в сообщении, длина подписи |
| Форматирование | Markdown или HTML-разметка | Какая разметка поддерживается, как экранировать спецсимволы |
| Файлы и медиа | Фото, документы, видео, голосовые | Поддерживаемые типы и размеры, способ загрузки |
| Оплата | Провайдеры для физических товаров и услуг, Stars для цифровых | Есть ли встроенная оплата и для каких сценариев |
| Mini App | Telegram Mini Apps, проверка initData на сервере | Как открывается мини-приложение и как проверяются данные пользователя |
| Ссылки с параметром | Параметр при старте бота для меток источника | Можно ли передать метку источника в бот |
| Групповые чаты | Бот в группах и каналах | Как бот работает в групповых чатах, если это нужно |
Если какой-то возможности в MAX нет, сценарий не ломают, а дают альтернативу в адаптере. Например, вместо недоступного типа кнопки — обычный выбор из вариантов, вместо встроенной оплаты — оплата через платёжный сервис. Подробнее о том, как оплата устроена в Telegram, — в статье о приёме оплаты в Telegram-боте.
Один клиент в двух мессенджерах
У пользователя в Telegram и в MAX разные идентификаторы, и автоматически платформа их не связывает. Если ничего не делать, один и тот же клиент превратится в CRM в две карточки с разной историей.
Способы связать аккаунты:
- По телефону. Клиент делится номером в обоих мессенджерах, и система сводит аккаунты в один профиль. Нужно согласие на обработку персональных данных и аккуратная логика на случай, если номер сменился.
- Одноразовым кодом. Telegram-бот выдаёт код или ссылку, клиент открывает её в MAX — и аккаунты связаны. Работает без телефона.
- Через личный кабинет. Если у клиента есть аккаунт на сайте, оба мессенджера привязываются к нему.
В базе это выглядит как таблица клиентов и связанная с ней таблица аккаунтов в мессенджерах. Отдельно храните, куда клиент предпочитает получать уведомления, — дублировать каждое сообщение в оба мессенджера не стоит.
Мини-приложение на два мессенджера
Если у бота есть Mini App, его интерфейс почти целиком переиспользуется: это веб-приложение, и экраны в обоих мессенджерах одни и те же. Меняется тонкий слой работы с платформой — получение данных запуска, кнопки интерфейса мессенджера, закрытие окна.
Главное — серверная проверка пользователя. В Telegram данные Mini App проверяются по подписи на основе токена бота. Для MAX алгоритм берётся из его документации, а не переносится по аналогии. Сервер должен понимать, с какой платформы пришёл запрос, и проверять данные соответствующим способом.
Как подготовить веб-интерфейс к работе в нескольких мессенджерах, разобрано в статье «Как превратить сайт в Mini App для Telegram и MAX».
Тестирование
- Автотесты на ядро: сценарии, переходы, расчёты. Они общие для обоих мессенджеров и запускаются без них.
- Тесты адаптеров: событие от платформы правильно превращается во внутреннее, ответ ядра правильно превращается в сообщение платформы.
- Отдельный тестовый бот в MAX со своим токеном и тестовой базой.
- Прогон всех сценариев параллельно в Telegram и MAX: результат в CRM должен совпадать.
- Регрессия Telegram-бота после рефакторинга — его клиенты не должны заметить изменений.
Мы обычно составляем таблицу сценариев и проходим её в обоих мессенджерах вместе с заказчиком. Расхождения сразу видны и либо исправляются, либо фиксируются как осознанное отличие платформ.
Постепенный запуск
Автоматически перевести подписчиков из Telegram в MAX нельзя — это разные платформы. Клиентов приглашают: ссылкой в Telegram-боте, на сайте, в рассылке, на кассе. Поэтому запуск растягивается сам собой, и это хорошо.
- Сначала бот в MAX открывается для сотрудников — они проходят реальные сценарии.
- Затем ссылка появляется в одном канале, например на сайте, и вы смотрите на первые обращения.
- Каждая заявка в CRM помечается каналом, чтобы сравнивать Telegram и MAX на своих данных.
- Логи и уведомления об ошибках настраиваются для обоих адаптеров отдельно.
- Только после пары недель без сюрпризов ссылку на MAX добавляют везде.
Технические детали самого MAX-бота — вебхуки, хранение состояния, админ-панель — описаны в статье о разработке MAX-бота.
Частые вопросы
Сколько времени занимает перенос бота в MAX?
Зависит от того, насколько логика текущего бота отделена от Telegram. Если отделена, адаптер для MAX делается заметно быстрее, чем новый бот. Если нет, к сроку добавляется рефакторинг — оцениваем после аудита кода.
Можно ли перенести подписчиков Telegram-бота в MAX?
Автоматически — нет, это разные платформы с разными аккаунтами. Клиентов приглашают в бота MAX ссылками из Telegram-бота, с сайта и из рассылок.
Придётся ли поддерживать два разных кода?
При архитектуре с общим ядром — нет: сценарии и интеграции общие, отличаются только адаптеры платформ. Поддержка и развитие такого бота у нас — от 10 000 ₽ в месяц.
Наш бот сделан в конструкторе. Его можно перенести?
Перенести код из конструктора обычно нельзя, но сценарии, тексты и данные можно выгрузить и собрать бота заново — сразу с ядром под два мессенджера.
Обсудим проект
Нужна похожая разработка?
Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.
Источники
Опубликовано · Обновлено