Внутриканальные боты в MAX: уведомления и процессы для команды

Общий чат не масштабируется

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

Я не предлагаю завести регламент, что важные сообщения нужно помечать или дублировать руководителю голосом. Это чинится не договорённостью между людьми, а тем, что уведомление вообще не должно попадать в общий чат — оно должно приходить конкретному человеку в личку от бота, с контекстом и на основании события в системе, а не потому что кто-то вспомнил написать.

Событие в CRM — сообщение в MAX

Технически это несложная конструкция, если строить её через API, а не через визуальный конструктор сценариев. У amoCRM и Bitrix24 есть вебхуки на смену статуса сделки, назначение ответственного, просроченную задачу. Я вешаю на нужные события обработчик, который проверяет условие (сумма сделки выше порога, третий день без движения, эскалация от клиента отмечена тегом) и отправляет сообщение через Bot API MAX конкретному сотруднику — не в чат, а в личку, со ссылкой на карточку сделки.

Это же работает в обратную сторону как согласования. Заявка на отпуск, заявка на расход, запрос на скидку клиенту — вместо того чтобы сотрудник писал руководителю в чат и ждал, пока тот увидит, бот в MAX присылает руководителю карточку с кнопками «согласовать» / «отклонить». Нажатие кнопки — это вызов API, который меняет статус в учётной системе (в Bitrix24 это может быть элемент бизнес-процесса, в отдельном случае — просто запись в таблице заявок). Ответственный не переключается между приложениями, а решение фиксируется там, где оно должно храниться, а не расползается по переписке.

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

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

Почему для этого слоя я выбираю MAX, а не Telegram

Здесь есть практический довод, который для внутренних уведомлений весомее удобства интерфейса. Во внутренней переписке команды регулярно мелькают данные, которые формально являются персональными: имя клиента, номер телефона, сумма сделки, содержание жалобы. Когда это уходит ботом в Telegram, это уход данных на инфраструктуру, которая физически и юридически находится вне России. Для компании, которая обрабатывает персональные данные клиентов, это лишний вопрос к архитектуре, даже если de facto никто никогда не проверял.

MAX — российский мессенджер, и данные, которые проходят через него, остаются в российской юрисдикции. Для клиентской части бота это часто аргумент на уровне маркетинга. Для внутреннего слоя, где в уведомлении может быть номер телефона клиента или сумма сделки, это уже вопрос соответствия 152-ФЗ, а не выбора платформы по вкусу. Я закладываю это в архитектуру заранее, а не как дополнение постфактум — это ровно так же реализуется через Bot API, только адрес отправки другой.

Что в итоге получается

На практике внутренний слой бота в MAX — это несколько обработчиков вебхуков от CRM и один или два сценария внутри самого бота: уведомление конкретному человеку по событию и согласование через инлайн-кнопки с записью решения обратно в систему. Это не отдельный продукт и не надстройка над чатом — это код, который живёт рядом с интеграцией CRM и аналитики и использует те же события, что уже есть в системе. Если событие в CRM уже существует и уже размечено, довести его до сообщения конкретному человеку в MAX — вопрос вебхука и одного API-вызова, а не нового процесса, который нужно объяснять команде и надеяться, что его будут соблюдать.