Как спроектировать автоматизацию заявок с сайта: от формы до задачи менеджеру

Исходная задача и условный пример

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

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

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

Что должно измениться в процессе

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

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

Важно, что финальное решение о качестве лида и дальнейших действиях всегда остаётся за человеком. Автоматизация только ускоряет доставку данных и снижает вероятность потери информации.

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

Какие данные, материалы и доступы потребуются

Для проектирования нужны поля из формы на сайте: имя, телефон, электронная почта, текст комментария, дополнительные параметры (например, размеры изделия). Также потребуется список возможных категорий запросов и правила назначения ответственных.

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

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

В условном примере мебельной компании форма передаёт имя, телефон, желаемые габариты шкафа и комментарий. Эти данные маппятся на соответствующие поля лида.

Пошаговый сценарий от события до результата

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

Для каждой новой заявки создайте уникальный request_id и сохраняйте его при повторной доставке этой же заявки. До обращения к CRM сохраните заявку в надёжную очередь и атомарно зарегистрируйте её идентификатор с уникальным ограничением: два обработчика не должны одновременно начать создание одного лида. Повтор с уже обработанным request_id получает сохранённый результат. Совпадение телефона или даты само по себе не доказывает дубль: новый запрос того же клиента получает новый идентификатор и обрабатывается отдельно.

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

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

Роль искусственного интеллекта и его границы

ИИ используется только для анализа текста комментария из формы. Он может предложить категорию запроса (например, «кухня», «шкаф-купе», «офисная мебель») или подсказать ключевые слова. Эти подсказки передаются менеджеру внутри задачи.

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

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

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

Способ соединения систем

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

Соединение с CRM выполняется через её REST API. Перед внедрением проверьте, поддерживают ли ваша CRM, тариф и права пользователя создание нужных сущностей и поиск для сверки результатов. Например, документация Битрикс24 описывает метод crm.lead.add, принимающий поля лида и возвращающий его ID; создание связанной задачи требует отдельной проверки документации. Посредник может преобразовать формат данных, но не добавляет отсутствующие возможности API. Если подходящего интерфейса нет, согласуйте поддерживаемый импорт или ручной этап.

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

В условном примере данные формы отправляются на сервер компании, который затем создаёт лид и задачу в используемой CRM.

Документация: Битрикс24: создание лида через REST API.

Возможные ошибки и способы защиты

Основные риски — создание дублей лидов при повторных попытках записи, потеря заявок при сбое API и утечка конфиденциальных данных. Чтобы избежать дублей, всегда проверяйте наличие записи по request_id до создания новой. При тайм-ауте сначала сверяйте сохранённый идентификатор, а не повторяйте запрос вслепую.

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

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

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

План запуска и приёмки

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

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

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

Для условной мебельной компании можно подготовить десять тестовых заявок. Среди них должны быть две разные заявки одного клиента, повтор одной заявки с тем же request_id, одновременные повторы, тайм-аут после фактической записи и отказ модели. Ожидаемый результат каждого сценария запишите заранее; после теста сравните число лидов и задач с ожидаемым. Это план проверки, а не сведения о проведённом внедрении.

Как измерять эффект и расходы

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

Бюджет складывается из разовой разработки и регулярных расходов: поддержки, сервера, лицензии CRM или сервиса интеграции, API модели и хранения данных. Для условного расчёта затрат ИИ возьмите 300 заявок в месяц, по 500 входных и 100 выходных токенов на классификацию. Получится 150 000 входных и 30 000 выходных токенов; умножьте эти объёмы на текущие тарифы выбранной модели и добавьте запас на повторы. Эти числа — пример расчёта, а не прогноз реальной нагрузки.

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

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