Один Telegram-бот для чата и браузера: как не писать сценарий дважды

Бот для заявок на отгрузку работает в Telegram полгода: менеджеры создают заявку, РОП согласует, кладовщик получает уведомление. Потом выясняется, что на складе два компьютера без Telegram, у кладовщика руки в перчатках, а транспортная компания хочет видеть заявки по ссылке, без установки мессенджера. Появляется просьба: «сделайте то же самое в браузере».

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

В чём проблема

Логика бота состоит из правил. Кто может создать заявку, какие поля обязательны, кто согласует заявку больше 300 000 ₽, что происходит после согласования, кому уходит уведомление. Кнопки и экраны только показывают эти правила человеку.

Когда делают вторую версию под браузер, вместе с кнопками легко продублировать и сами правила. Тогда любое изменение (новая проверка, новый статус, ещё одна ступень согласования) приходится вносить в двух местах. Рано или поздно версии расходятся: в Telegram заявка уходит на согласование главбуху, а в вебе проходит сразу. Такие ошибки находят обычно по жалобе, когда товар уже отгрузили.

Три слоя: ядро, транспорт, интерфейсы

• Ядро. Все правила: обработка команд, проверки, работа с базой, запись в 1С, отправка уведомлений. Ядро не знает, откуда пришёл пользователь.
• Транспорт. Переводчик между внешним миром и ядром. Telegram присылает одно событие, браузер другое, оба превращаются в понятный ядру формат: «пользователь 42 нажал “Согласовать” в заявке 1 187».
• Интерфейсы. Чат в Telegram, веб-страница, приложение на планшете склада. Это разные окна в одну и ту же логику.

Удобно сравнить с диспетчером. Ему всё равно, позвонили ему, написали в чат или оставили записку на столе: он берёт заявку и запускает один и тот же процесс. Диспетчер здесь ядро, а телефон, чат и записка играют роль транспорта.

Как это сделать, если бот уже написан

Переписывать бота с нуля обычно не нужно. Самый быстрый путь для Python-бота на aiogram или python-telegram-bot: браузерный интерфейс отправляет на сервер события в том же формате, в каком их присылает Telegram, а ответы перехватывает промежуточный слой и отдаёт в веб вместо отправки в мессенджер. Существующие обработчики получают привычные объекты и работают без изменений.

Это хороший первый шаг: веб-версия появляется за 1–2 недели, логика не дублируется. Дальше, по мере развития, правила постепенно выносят из обработчиков в отдельный модуль ядра, и тогда добавлять новые интерфейсы становится ещё проще.

Что это даёт

• Одна правка вместо двух. Поменяли порог согласования, и он поменялся и в чате, и в браузере.
• Меньше ошибок. Нет двух версий процесса, которые могут разойтись.
• Дешевле поддержка. Разработчик не синхронизирует две кодовые базы и не тестирует каждое изменение дважды.
• Третий интерфейс без переписывания. Понадобился планшет на складе со сканером или виджет в Битрикс24, и это снова новый транспорт поверх той же логики.

Кому в компании нужен браузер

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

• Склад и производство. Кладовщик работает за общим компьютером или с ТСД, личный телефон часто лежит в шкафчике. Ему нужна страница с крупными кнопками и списком заявок на сегодня.
• Подрядчики и перевозчики. Ставить мессенджер и подписываться на бота ради одной задачи им неудобно. Ссылка с ограниченным доступом к своим заявкам решает вопрос.
• Руководители. Смотреть сводку по 200 заявкам в чате невозможно. В браузере это таблица с фильтрами по статусу, менеджеру и дате.
• Бухгалтерия. Главбуху удобнее согласовывать оплаты с компьютера, где рядом открыты 1С:Бухгалтерия 3.0 и Диадок или СБИС.

Подводные камни

1. Состояние пользователя. Бот помнит, на каком шаге находится человек: выбрал клиента, ждёт ввода суммы. Если состояние хранится в памяти Telegram-бота, в браузере человек «потеряется». Его нужно хранить в базе и привязывать к пользователю, а не к чату.
2. Разные возможности интерфейсов. В чате удобны кнопки и короткие сообщения. В браузере удобнее форма на одном экране, таблица, загрузка нескольких файлов, например скана ТТН. Транспорт должен уметь показать один и тот же шаг по-разному.
3. Авторизация. В Telegram пользователя определяет его аккаунт. В браузере нужен вход: через Telegram Login Widget, одноразовую ссылку из бота или логин с паролем. Права (кто видит суммы, кто согласует) проверяются в ядре, одинаково для всех интерфейсов.
4. Уведомления. В Telegram они приходят сами. Для пользователей браузера нужно решить заранее: дублировать в Telegram, отправлять письмо или показывать счётчик новых событий на странице.

Когда это не нужно

Если интерфейс один и он всех устраивает, не усложняйте. Если процесс простой и полностью живёт в чате, оставьте как есть. Разделение на ядро и транспорт оправдано, когда:

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

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

Если хотите примерить это на свой процесс, можно написать в Telegram @automationdev24: опишите, как всё устроено сейчас, и мы скажем, хватит ли доработки текущей системы или нужна своя.