Чат-бот для сбора заявок: поля, квалификация и передача в CRM

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

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

Чат-бот для сбора заявок: поля, квалификация и передача в CRM

Чат-бот для сбора заявок должен задать минимум вопросов, проверить корректность телефона или email, получить согласие на обработку и передать данные в CRM с правильным статусом. Главная задача — собрать достаточно информации для квалификации лида без лишних шагов, сохранить её в структурированном виде и направить ответственному сотруднику. Ниже — рабочая последовательность от постановки цели заявки до передачи в систему учёта.

Цель заявки и набор полей

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

Для большинства B2B-заявок достаточно имени, телефона, email и названия компании. Если продукт требует квалификации по отрасли или бюджету, добавьте одно-два поля выбора. Для записи на услугу нужны дата, время и описание задачи. Для загрузки материалов обычно хватает имени и email.

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

Цель заявки	Обязательные поля	Дополнительные поля
Запрос КП	Имя, телефон, компания	Email, отрасль, срок
Запись на консультацию	Имя, телефон, дата, время	Email, описание задачи
Демо продукта	Имя, email, компания	Должность, размер команды
Обратный звонок	Имя, телефон	Удобное время
Загрузка материалов	Имя, email	Компания, должность

Сценарий диалога и последовательность вопросов

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

После выбора цели бот запрашивает обязательные поля по одному. Каждое сообщение должно содержать один вопрос и краткое пояснение формата, если это необходимо. Например: «Укажите телефон в формате +7 900 123-45-67» или «Напишите рабочий email для отправки КП».

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

Условный пример диалога

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

Бот: Здравствуйте! Помогу записаться на консультацию или рассчитать стоимость аудита. Выберите вариант.
Пользователь: Консультация.
Бот: Как к вам обращаться?
Пользователь: Алексей.
Бот: Укажите телефон для связи в формате +7 900 123-45-67.
Пользователь: +7 921 555-10-20.
Бот: Напишите название компании.
Пользователь: ООО «Импульс».
Бот: Опишите коротко задачу или оставьте поле пустым.
Пользователь: Нужен аудит закупок.
Бот: Спасибо! Менеджер свяжется с вами в течение часа. Согласие на обработку данных подтверждаете?
Пользователь: Да.

Бот передаёт в CRM запись: имя «Алексей», телефон «+79215551020», компания «ООО «Импульс»», комментарий «Нужен аудит закупок», статус «Новая заявка», источник «Сайт — виджет чата», согласие получено, временная метка.

Валидация контактов в диалоге

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

Для телефона проверяйте наличие кода страны, длину номера и допустимые символы. Регулярное выражение для российского номера в международном формате: ^\+7\d{10}$ или с разделителями ^\+7 \d{3} \d{3}-\d{2}-\d{2}$. Если пользователь ввёл номер без +7, бот может спросить: «Это российский номер?» и добавить код автоматически.

Для email проверяйте наличие символа @, домена и зоны. Простое выражение: ^[^\s@]+@[^\s@]+\.[^\s@]+$. Если адрес не проходит проверку, попросите ввести ещё раз и укажите пример: primer@domen.ru.

Если бот поддерживает отправку кода подтверждения по SMS или email, добавьте этот шаг после ввода контакта. Это повысит качество базы, но удлинит диалог. Применяйте подтверждение только для высокочековых продуктов или когда важна точность контакта для автоматической отправки документов.

Получение согласия на обработку данных

Перед передачей заявки в CRM необходимо получить согласие на обработку персональных данных. В России это требование закона 152-ФЗ. Согласие можно запросить в конце диалога отдельным вопросом или показать чекбокс со ссылкой на политику конфиденциальности.

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

Факт согласия фиксируйте в CRM отдельным полем с временной меткой. Это упростит аудит и защитит при проверках.

Квалификация лида в диалоге

Квалификация помогает отсеять нецелевые заявки и передать ответственному только готовых к диалогу клиентов. Базовые критерии: соответствие целевой аудитории, наличие потребности, готовность обсуждать условия.

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

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

Пример квалификационных вопросов

Какая у вас должность? (выбор: владелец, руководитель, специалист, другое)
Сколько человек в компании? (выбор: до 10, 10–50, 50–200, более 200)
Когда планируете начать? (выбор: в течение месяца, в течение квартала, изучаю варианты)
Какой бюджет рассматриваете? (текст или выбор диапазонов)

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

Передача заявки в CRM

Передача данных в CRM выполняется через API, веб-хук или интеграционную платформу. Для большинства систем учёта достаточно HTTP POST-запроса с JSON-телом, содержащим поля заявки и метаданные.

Обязательные параметры запроса: уникальный идентификатор заявки, временная метка, источник (канал и кампания), контактные данные, статус. Статус по умолчанию — «Новая заявка» или «Необработанная». Если CRM поддерживает воронки, укажите этап воронки, соответствующий типу заявки.

После успешной отправки бот должен сохранить идентификатор сделки или контакта из ответа CRM. Это позволит связать последующие обращения пользователя с существующей заявкой и избежать дублей.

Пример структуры данных для передачи

{
  "lead_id": "uuid-12345",
  "timestamp": "2026-10-03T14:23:00Z",
  "source": "website_chat",
  "campaign": "autumn_promo",
  "contact": {
    "name": "Алексей",
    "phone": "+79215551020",
    "email": "",
    "company": "ООО «Импульс»"
  },
  "fields": {
    "service": "audit",
    "comment": "Нужен аудит закупок",
    "consent": true,
    "consent_timestamp": "2026-10-03T14:25:00Z"
  },
  "status": "new",
  "assigned_to": ""
}

Маршрутизация и назначение ответственного

Правила маршрутизации определяют, какому сотруднику или отделу передать заявку. Простейший вариант — round-robin (по очереди) среди свободных менеджеров. Более сложный — по параметрам: регион, отрасль, размер компании, источник.

Если CRM поддерживает автоматическое назначение, настройте правила внутри системы. Если нет, бот может сам выбрать ответственного на основе таблицы правил и передать его идентификатор в поле assigned_to.

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

Обработка ошибок передачи

API CRM может быть недоступен, вернуть ошибку аутентификации или отклонить запрос из-за некорректных данных. Бот должен обработать все типовые ошибки и сохранить заявку в резервное хранилище.

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

Если CRM отклонил запрос из-за дубля (контакт уже существует), обновите существующую запись или создайте новую задачу для менеджера с пометкой «Повторное обращение».

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

Безопасность и управление рисками

Чат-боты для сбора заявок работают с персональными данными и интегрируются с внутренними системами. Согласно NIST AI Risk Management Framework, управление рисками должно быть связано с целями организации и допустимым уровнем риска. Для бота это означает защиту данных, предотвращение несанкционированного доступа и контроль автономности.

Проект OWASP Top 10 для LLM-приложений перечисляет риски, актуальные для ботов на больших языковых моделях: prompt injection, утечки обучающих данных, чрезмерная автономность и неограниченное потребление ресурсов. Если ваш бот использует генеративную модель, учитывайте эти угрозы.

Типичные ошибки при проектировании

Частая ошибка — слишком длинный диалог. Каждое дополнительное поле снижает конверсию на 5–15 %. Собирайте только данные, необходимые для первого контакта.

Вторая ошибка — отсутствие валидации. Некорректные телефоны и email загрязняют базу и снижают эффективность обзвона. Проверяйте формат до передачи.

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

Четвёртая ошибка — игнорирование согласия на обработку данных. Это нарушение законодательства и повод для штрафа.

Пятая ошибка — отсутствие резервного канала. Если API CRM недоступен, заявка теряется. Сохраняйте данные локально и повторяйте отправку.

Проверка работы интеграции

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

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

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

Проверьте маршрутизацию: отправьте несколько заявок с разными параметрами и убедитесь, что они попали к правильным ответственным.

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

Определены цели заявки и минимальный набор полей.
Сценарий диалога состоит из 3–5 вопросов.
Валидация телефона и email настроена и протестирована.
Получение согласия на обработку данных встроено в диалог.
Квалификационные вопросы (если нужны) не перегружают диалог.
Структура данных для API CRM задокументирована и согласована с командой.
Правила маршрутизации и назначения ответственного настроены.
Обработка ошибок передачи реализована, резервное хранилище работает.
Шифрование, токены доступа и ограничение прав проверены.
Полный цикл от диалога до CRM протестирован на тестовых данных.
Логирование попыток передачи и ошибок включено.
Инструкция для менеджеров по работе с заявками из бота подготовлена.

Метрики эффективности сбора заявок

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

Измеряйте долю корректных контактов: сколько телефонов и email оказались рабочими при первом обзвоне. Если доля ниже 80 %, усильте валидацию или добавьте подтверждение кодом.

Отслеживайте скорость обработки заявки: время от отправки до первого контакта менеджера. Если задержка превышает допустимую (обычно 1 час для горячих лидов), проверьте маршрутизацию и доступность менеджеров.

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

Метрика	Целевое значение	Способ измерения
Конверсия в завершённую заявку	60–80 %	Завершённые / начавшие диалог
Доля корректных контактов	≥ 80 %	Рабочие телефоны / все заявки
Время до первого контакта	≤ 1 час	Временная метка CRM − timestamp заявки
Доля дублей	≤ 5 %	Дубли / все заявки
Доля ошибок передачи	≤ 1 %	Неуспешные запросы / все попытки

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

Сколько полей можно запросить без потери конверсии?

Безопасное число — три-четыре обязательных поля. Каждое следующее снижает конверсию. Если нужно больше данных, собирайте их после передачи заявки: менеджер уточнит детали по телефону или отправит анкету по email.

Нужно ли подтверждать телефон кодом из SMS?

Подтверждение повышает качество базы, но удлиняет диалог и снижает конверсию на 20–30 %. Применяйте его для дорогих продуктов или когда автоматически отправляете документы по указанному контакту.

Как обрабатывать повторные обращения?

Если пользователь оставил заявку ранее, бот должен обновить существующую запись в CRM или создать новую задачу для менеджера с пометкой «Повторное обращение». Не создавайте дубли контактов. Для распознавания используйте телефон или email как уникальный ключ.

Что делать, если CRM не отвечает?

Сохраняйте заявку в резервное хранилище (база данных, файл, очередь сообщений) и повторяйте попытку отправки каждые 5–10 минут. Пользователю покажите сообщение о принятии заявки без упоминания ошибки. Настройте уведомление техподдержке при длительной недоступности API.

Как передать заявку конкретному менеджеру?

Если в CRM есть поле ответственного, передавайте идентификатор сотрудника в assigned_to. Выбор менеджера можно делать по правилам (регион, отрасль, источник) или методом round-robin. Если правила сложные, храните их в отдельной таблице и обновляйте без изменения кода бота.

Нужно ли логировать все диалоги?

Логируйте все попытки передачи в CRM, коды ответов и ошибки. Полные тексты диалогов сохраняйте, если это необходимо для аналитики или обучения модели, но соблюдайте требования к хранению персональных данных: шифрование, ограничение доступа, срок хранения.

Как считать ROI бота для сбора заявок?

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

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

Чат-бот для сбора заявок работает эффективно, если вы чётко определили цель, минимизировали число полей, проверили контакты перед передачей и настроили надёжную интеграцию с CRM. Валидация, обработка ошибок и резервное хранилище предотвращают потерю лидов. Квалификация и маршрутизация направляют заявки нужным сотрудникам без задержек. Фиксация согласия на обработку данных и следование принципам безопасности защищают компанию от юридических и технических рисков. Измеряйте конверсию на каждом шаге, долю корректных контактов и скорость обработки, чтобы находить узкие места и улучшать диалог. Проверьте полный цикл перед запуском, подготовьте инструкцию для менеджеров и отслеживайте метрики регулярно. Это даст вам управляемый инструмент сбора заявок, который не требует постоянного внимания и масштабируется вместе с ростом трафика.