Бот в MAX для заявок: сценарий, проверка контактов и передача менеджеру

Проектирование короткого диалога, согласия на обработку данных, проверки полей и передачи заявки ответственному.

Лид: Проектирование короткого диалога, согласия на обработку данных, проверки полей и передачи заявки ответственному.

Бот в MAX для заявок: сценарий, проверка контактов и передача менеджеру

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

Почему MAX подходит для сбора заявок

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

Выбор в пользу MAX оправдан, если целевая аудитория уже использует этот мессенджер, а интеграция с корпоративными инструментами выполняется через открытое API. Альтернативой могут служить боты в Telegram, VK или WhatsApp, но для замкнутой корпоративной среды собственная платформа снижает зависимость от внешних ограничений.

Компоненты бота для заявок

Полный цикл обработки заявки включает несколько блоков:

Приветствие и описание цели. Первое сообщение объясняет, какие данные нужны и зачем.
Запрос имени. Бот задаёт открытый вопрос, сохраняет ответ в переменную состояния.
Запрос телефона. Предлагает ввести номер, затем проверяет формат регулярным выражением.
Согласие на обработку данных. Выводит текст политики и кнопку подтверждения или ссылку на полную версию.
Валидация полей. Проверяет, что имя не содержит цифр, телефон соответствует шаблону, согласие получено.
Формирование заявки. Собирает все поля в структурированный объект или строку.
Передача менеджеру. Отправляет POST-запрос в CRM, webhook или уведомление в канал менеджеров.
Подтверждение пользователю. Сообщает, что заявка принята, и сообщает примерное время ответа.

Проектирование сценария диалога

Сценарий удобно представить в виде конечного автомата с состояниями: start, awaiting_name, awaiting_phone, awaiting_consent, processing, done. Переход между состояниями происходит при получении сообщения от пользователя или при успешной валидации. Каждый шаг сохраняет данные в сессии — это может быть объект в памяти, запись в Redis или таблица в базе данных.

Пример структуры состояний

Состояние	Действие бота	Ожидаемый ввод	Следующее состояние
start	Приветствие, запрос имени	Текст имени	awaiting_name
awaiting_name	Сохранение имени, запрос телефона	Номер телефона	awaiting_phone
awaiting_phone	Валидация телефона, запрос согласия	Подтверждение согласия	awaiting_consent
awaiting_consent	Проверка согласия, формирование заявки	—	processing
processing	Отправка в CRM, уведомление менеджеру	—	done
done	Подтверждение пользователю, сброс состояния	—	start

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

Запрос согласия на обработку данных

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

Согласие фиксируется в базе вместе с отметкой времени и идентификатором пользователя. Это позволяет доказать легитимность обработки при проверке регуляторами. Если пользователь отказывается, бот благодарит за время и завершает диалог без сохранения данных.

Валидация контактных полей

Проверка формата снижает количество некорректных заявок. Для имени достаточно правила: не менее двух символов, отсутствие цифр и специальных знаков. Телефон проверяется регулярным выражением, например ^\+?[78][\d\s\-()]{9,14}$ для российских номеров. Если формат не совпадает, бот отвечает: «Пожалуйста, введите номер в формате +7 XXX XXX-XX-XX» и остаётся в состоянии ожидания.

Email, если он требуется, проверяется регулярным выражением ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$. Важно помнить, что regex не гарантирует существование адреса, но отсекает очевидные опечатки. Для глубокой проверки можно отправить тестовое письмо с кодом подтверждения, но это увеличивает длину диалога.

Отправка сообщений через MAX API

Документация MAX API описывает метод отправки сообщений и структуру запроса. Типичный POST-запрос включает токен авторизации в заголовке, идентификатор чата, текст сообщения и опционально кнопки или вложения. Пример структуры:

POST https://platform-api2.max.ru/messages?chat_id=12345
Authorization: <access_token>
Content-Type: application/json

{
  "text": "Как вас зовут?"
}

Токен получается при регистрации бота в панели разработчика MAX. Его необходимо хранить в переменных окружения или секретах CI/CD, не публиковать в репозитории. Каждый запрос проходит аутентификацию, и при компрометации токена злоумышленник получает доступ к отправке сообщений от имени бота.

Интеграция с CRM и уведомление менеджера

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

Параллельно бот отправляет уведомление в групповой чат менеджеров или на email. Уведомление содержит имя, телефон, время заявки и ссылку на карточку лида в CRM. Это позволяет отделу продаж реагировать быстрее, чем при проверке CRM вручную каждые полчаса.

Пример структуры заявки

{
  "lead": {
    "name": "Иван Петров",
    "phone": "+79991234567",
    "source": "MAX Bot",
    "created_at": "2026-10-03T14:22:00Z",
    "consent": true
  }
}

Если CRM временно недоступна, бот сохраняет заявку в очередь сообщений (например, RabbitMQ или Redis Streams) и повторяет отправку через несколько минут. Пользователю выводится сообщение: «Заявка принята, менеджер свяжется с вами в течение часа». Это предотвращает потерю лидов при сбоях внешних систем.

Обработка ошибок и граничных случаев

Типичные ошибки включают:

Пользователь отправляет голосовое сообщение вместо текста. Бот отвечает: «Пожалуйста, введите ответ текстом».
Ввод спецсимволов в имени. Валидация возвращает ошибку и просит повторить.
Отказ от согласия на обработку данных. Бот благодарит и завершает диалог.
Тайм-аут: пользователь не отвечает 10 минут. Состояние сбрасывается, следующее сообщение начинает диалог заново.
Дублирование заявки. Проверка по номеру телефона в CRM: если лид с таким номером создан менее часа назад, бот сообщает, что заявка уже зарегистрирована.

Логирование всех шагов диалога помогает анализировать, на каком этапе пользователи чаще всего бросают заполнение. Если 40% отваливаются на запросе телефона, возможно, формулировка вызывает недоверие или пользователи не понимают формат ввода.

Безопасность и защита данных

Персональные данные должны шифроваться при передаче и хранении. Используйте HTTPS для всех API-запросов, TLS 1.2 или выше. В базе данных телефоны и имена можно хранить в зашифрованном виде, ключ держать в защищённом хранилище (например, HashiCorp Vault).

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

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

Проверка работы бота перед запуском

Тестирование включает прогон всех веток сценария:

Успешное заполнение всех полей с первого раза.
Ввод некорректного телефона, затем исправление.
Отказ от согласия на обработку данных.
Прерывание диалога на середине, повторный запуск.
Отправка голосового сообщения, стикера, фото вместо текста.
Ввод SQL-инъекции в поле имени для проверки фильтрации.
Одновременная работа нескольких пользователей для проверки изоляции состояний.
Недоступность CRM: заявка должна попасть в очередь.

Автоматизированные тесты можно написать на Python с библиотекой pytest, эмулируя отправку сообщений в бота и проверяя ответы. Каждое изменение кода проходит через CI/CD pipeline с прогоном тестов перед деплоем в продакшн.

Оптимизация пользовательского опыта

Короткие диалоги повышают процент завершённых заявок. Если можете обойтись только именем и телефоном — не запрашивайте email и адрес. Добавляйте подсказки: «Введите телефон в формате +7 900 123-45-67» вместо абстрактного «Введите телефон».

Кнопки быстрых ответов снижают количество ошибок ввода. Например, для согласия на обработку данных предложите кнопки «Согласен» и «Подробнее», вместо того чтобы просить напечатать «да». Используйте emoji умеренно: ✅ рядом с «Согласен» делает кнопку заметнее, но избыток смайликов выглядит несерьёзно.

После отправки заявки покажите примерное время ответа: «Менеджер свяжется с вами в течение 30 минут в рабочие часы (с 9:00 до 18:00 МСК)». Это управляет ожиданиями и снижает количество повторных обращений.

Чек-лист настройки бота для заявок

Зарегистрирован бот в панели разработчика MAX, получен токен авторизации.
Реализован конечный автомат с состояниями: start, awaiting_name, awaiting_phone, awaiting_consent, processing, done.
Написаны регулярные выражения для валидации имени, телефона, email (если требуется).
Добавлен запрос согласия на обработку данных с кнопками подтверждения.
Настроена интеграция с CRM через API или webhook.
Реализована очередь сообщений для повторной отправки при недоступности CRM.
Настроено уведомление менеджеров в групповой чат или на email.
Логирование всех шагов диалога без записи полных персональных данных в открытые логи.
Тайм-аут сброса состояния после 10 минут неактивности.
Счётчик попыток ввода: после трёх ошибок предложить связь с оператором.
Проверка дублирования заявок по номеру телефона в CRM.
Защита от спама: лимит заявок на пользователя в час.
Шифрование передачи данных через HTTPS, хранение токена в секретах.
Автоматизированные тесты всех веток сценария.
Документация для менеджеров: как выглядит заявка, куда приходит уведомление.

Масштабирование и мониторинг

При росте числа пользователей критичны скорость ответа и стабильность. Разместите бота на сервере с запасом по CPU и памяти, используйте горизонтальное масштабирование через балансировщик нагрузки. Состояния сессий храните в Redis, чтобы несколько инстансов бота могли обрабатывать запросы одного пользователя без конфликтов.

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

Регулярно анализируйте логи на предмет новых типов ошибок ввода. Если пользователи часто пишут номер без плюса, добавьте автоматическое исправление формата. Если спрашивают «А зачем вам телефон?», включите пояснение в текст запроса.

Интеграция с аналитикой и CRM-отчётами

Каждая заявка помечается источником «MAX Bot», что позволяет в CRM строить отчёты по конверсии из бота в сделку. Сравнивайте эффективность бота с веб-формой на сайте и заявками из других каналов. Если конверсия бота ниже, проверьте длину диалога, ясность формулировок и скорость ответа менеджеров.

Подключите систему аналитики (например, Google Analytics через Measurement Protocol или собственный трекер) для фиксации событий: начало диалога, ввод имени, ввод телефона, согласие, отправка заявки. Воронка покажет, на каком шаге теряется наибольшая доля пользователей.

Частые вопросы

Как хранить состояние диалога между сообщениями?

Состояние можно хранить в оперативной памяти (словарь Python), Redis, базе данных или в самом объекте пользователя в MAX, если платформа предоставляет поле для метаданных. Redis предпочтительнее для продакшн-систем: данные переживают перезапуск бота, и несколько инстансов могут обращаться к одному хранилищу.

Нужно ли дублировать заявку в email?

Дублирование на email менеджера повышает скорость реакции, но создаёт избыточность. Лучше настроить уведомление в корпоративный мессенджер или CRM с push-уведомлениями. Email оправдан, если менеджеры работают удалённо и не имеют постоянного доступа к CRM.

Как проверить, что номер телефона реальный?

Полная проверка требует отправки SMS с кодом подтверждения. Это увеличивает длину диалога и затраты на SMS-шлюз. Для большинства задач достаточно проверки формата регулярным выражением и последующего звонка менеджера. Если номер не отвечает, менеджер помечает лид как недозвон.

Можно ли использовать MAX API бесплатно?

Условия доступа к MAX API и наличие бесплатного тарифа уточняйте в официальной документации на дату использования. По состоянию на 2026-10-03 документация MAX API описывает методы авторизации и работы с сообщениями, но коммерческие условия публикуются отдельно.

Как обрабатывать одновременные заявки от одного пользователя?

Если пользователь отправляет два сообщения подряд, состояние может перезаписаться. Используйте блокировку на уровне сессии: при получении сообщения устанавливайте флаг обработки, игнорируйте новые сообщения до завершения текущего шага, затем снимайте флаг. Альтернатива — очередь сообщений FIFO.

Стоит ли добавлять капчу в бота?

Текстовая капча в мессенджере раздражает пользователей. Эффективнее ограничение частоты запросов: один пользователь — максимум три заявки в час. Если спам продолжается, подключите проверку номера телефона через SMS или модерацию первой заявки от нового пользователя.

Практический вывод

Бот для сбора заявок в MAX строится на цепочке состояний, валидации пользовательского ввода и интеграции с CRM. Ключевые элементы — запрос согласия на обработку данных, проверка формата контактов регулярными выражениями и надёжная передача заявки ответственному менеджеру. Используйте официальную документацию MAX API для настройки отправки сообщений, храните токены в секретах, тестируйте все ветки диалога перед запуском. Мониторинг метрик и анализ логов покажут узкие места, которые снижают процент завершённых заявок. Такой подход позволяет автоматизировать первичный контакт с клиентом, сократить нагрузку на операторов и ускорить передачу лидов в отдел продаж.