Уведомления из amoCRM и аналитики в MAX

Откуда берутся события

Нотификационный слой не читает базу CRM по расписанию — он подписан на события. У amoCRM для этого есть вебхуки: создание сделки, смена статуса, добавление платежа. У Bitrix24 — свои обработчики событий, логика та же, синтаксис другой. Вебхук прилетает на бэкенд, я нормализую payload и решаю, кому и в каком виде это показать.

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

Оба потока — CRM-события и аналитические аномалии — сходятся в одном месте: очереди уведомлений, откуда они уже уходят в MAX через Bot API. Разница источников для получателя не видна: он получает сообщение «сделка на 340 000 ₽ закрыта» или «конверсия в оплату за сутки упала на 30% против среднего за неделю» в одном канале, в одном формате.

Кому и что показывать

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

Маршрутизация строится на правилах, а не на ручной рассылке. Каждое событие несёт с собой контекст — сумму, отдел, ответственного, канал привлечения — и правило решает, в какой чат MAX и с каким текстом это уйдёт. Я завожу правила как конфигурацию: условие на входе, шаблон сообщения и получатель на выходе. Когда логика усложняется — например, крупная сделка должна идти и менеджеру, и собственнику, а рядовая только менеджеру — это по-прежнему код, который читает событие и по паре условий решает, куда его отправить, а не список инструкций для человека, который вручную решает, кому написать. Здесь и проявляется связь с настройкой сквозной аналитики: маршрутизация опирается на те же поля и группировки, что уже настроены в Roistat и DataLens — канал, сегмент клиента, воронка. Ничего не дублируется отдельной таблицей соответствий.

Как не превратить это в спам

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

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

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

Почему MAX, а не Telegram

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

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