Внутренние боты в MAX: уведомления из CRM и согласования для команды

Клиентский бот в MAX на виду, но заметная часть пользы лежит во внутреннем слое: уведомления команде по событиям из CRM и боты, которые ведут согласования и сбор статусов. Там, где раньше был общий чат, в котором важное теряется среди обсуждений, появляется адресное сообщение конкретному человеку с контекстом и ссылкой на карточку.

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

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

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

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

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

Слой уведомлений не опрашивает базу CRM по расписанию, он подписан на события. У amoCRM для этого есть вебхуки на создание сделки, смену статуса, назначение ответственного, добавление платежа. У Битрикс24 — свои обработчики событий, логика та же. Вебхук приходит на сервер, обработчик проверяет условие — сумма сделки выше порога, третий день без движения, эскалация отмечена тегом — и отправляет сообщение через Bot API MAX нужному сотруднику со ссылкой на карточку сделки.

Второй источник событий — аналитика. В Roistat и DataLens важны отклонения: просадка конверсии из заявки в оплату за сутки, расход на канале без роста заявок, обнуление трафика с площадки, которая обычно даёт стабильный поток. CRM о состоянии воронки в целом не знает, поэтому здесь работает отдельный процесс: он сверяет метрику с ожидаемым коридором и сам создаёт событие, когда отклонение вышло за порог. Листать отчёт раз в день не нужно — код сравнивает текущее значение с базовым.

Оба потока сходятся в одной очереди уведомлений, откуда сообщения уходят в MAX. Для получателя разницы источников нет: «крупная сделка закрыта» и «конверсия в оплату за сутки заметно ниже среднего за неделю» приходят в одном канале и в одном формате.

Согласования и сбор статусов через бота

Та же связка работает в обратную сторону. Заявка на отпуск, на расход, запрос скидки для клиента: бот присылает руководителю карточку с кнопками «Согласовать» и «Отклонить». Нажатие кнопки — вызов API, который меняет статус в учётной системе: в Битрикс24 это шаг бизнес-процесса, в другой системе — запись в таблице заявок. Руководитель не переключается между приложениями, решение сохраняется там, где ему положено храниться, и не теряется в переписке.

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

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

Кому что показывать и как не устроить спам

Одно событие не должно приходить всем одинаково. Собственнику важны сделки выше определённого чека и системные сбои — просадка конверсии, остановка рекламы. Руководителю отдела продаж — новые сделки отдела и застрявшие на этапах. Менеджеру — только его клиенты: пришла оплата, клиент ответил после паузы, сделка стоит на этапе дольше нормы.

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

Первая версия такой прослойки обычно шлёт слишком много: каждая смена статуса, каждое обновление поля. Без ограничений лента в MAX за день становится нечитаемой. Мы ставим два механизма:

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

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

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

MAX — российский мессенджер с инфраструктурой в России. Для клиентского бота это часто довод маркетинговый, для внутреннего слоя с телефонами и суммами — вопрос соответствия закону о персональных данных. Мы закладываем это в архитектуру с начала проекта: технически отправка идёт через Bot API MAX тем же кодом, меняется адрес отправки.

Как мы это делаем

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

Начинаем с разбора: какие события важны собственнику, руководителю и менеджерам, где сейчас теряются согласования. После этого собираем бота MAX для команды, а согласования и сбор статусов связываем с автоматизацией бизнес-процессов. Вход — бесплатный созвон, после него присылаем план и смету.