Боты для MAX: три слоя, которые они закрывают в бизнесе

Клиентский слой — приём заявок и общение с клиентами

Первое, что делает бот в MAX, — принимает обращение и заводит его в CRM. Клиент пишет вопрос, бот квалифицирует его по нескольким полям (что интересует, бюджет, регион), создаёт сделку в amoCRM или Bitrix24 и назначает ответственного. Дальше — по воронке: менеджер видит контекст диалога прямо в карточке сделки, а не выясняет его заново по телефону.

Я собираю такие сценарии на API amoCRM и Bitrix24, а не через no-code конструкторы — потому что клиентский диалог часто ветвится: бот должен проверить статус клиента в базе, подтянуть историю заказов, обработать нетиповой вопрос через переключение на менеджера. Визуальный билдер сценариев такое тянет до первой развилки, а дальше превращается в нечитаемое дерево условий. Код и прямые запросы к API дают контроль над тем, что происходит на каждом шаге, и не ломаются при обновлении API мессенджера.

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

Про то, как я собираю ботов для MAX под приём и обработку заявок, — на странице услуги.

Внутренний слой — уведомления команде, боты для процессов

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

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

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

Нотификации — события из CRM и сквозной аналитики в MAX

Третий слой — техническая связка систем. Сквозная аналитика (у меня это обычно Roistat или связка ClickHouse + Yandex DataLens) считает деньги: какая заявка сколько стоила, какой канал окупается, где просела конверсия. Само по себе это дашборд, в который надо зайти и посмотреть. Бот в MAX превращает эти цифры в события, которые приходят сами: просела конверсия по каналу — сообщение собственнику, стоимость заявки выросла выше порога — сообщение маркетологу, закрылась крупная сделка — сообщение в общий чат с суммой и источником.

Технически это скрипт, который дёргает API Roistat или делает запрос к ClickHouse по расписанию, сравнивает значение с порогом и, если условие сработало, отправляет сообщение через API MAX. Никакой магии — обычная интеграция, которая раньше присылала бы уведомление в почту или Slack, а теперь идёт туда, где команда реально читает сообщения в течение дня.

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

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