AI-Воронщик: как собрать заявки из разных каналов в CRM
Клиент написал в мессенджер, отправил форму на сайте и продублировал письмо — для CRM это может выглядеть как три разных обращения.
Разбираю сценарий AI-Воронщик: он сводит входящие заявки к одному виду и передаёт их в CRM. Пакет пока не собран: внедрение идёт как отдельный проект под компанию, с подключением каналов и настройкой стыков.
Сначала подключаем источники
У заявки может быть несколько входов: форма на сайте, мессенджер через Wazzup, ВКонтакте или почта. Каждый канал подключается отдельно: у каждого свои доступы и настройки. Поэтому начинаем с тех источников, через которые компания действительно принимает обращения.
Когда заявка приходит, модель разбирает её на поля: имя, телефон, почта, суть обращения, канал и признак спама. Вместо сообщения в свободной форме появляются данные, с которыми дальше может работать CRM. Канал тоже сохраняется: это помогает видеть, откуда пришло обращение.
Затем телефон приводится к единому формату. Он служит ключом для поиска дублей. Без этого один и тот же номер, записанный по-разному, может не совпасть с уже существующим контактом. Нормализация проходит через внешний сервис.
Затем связываем заявку с CRM
Сценарий встраивается в Битрикс24 или amoCRM. Если контакт с таким телефоном уже есть, заявка привязывается к нему с пометкой канала. Если контакта нет, создаётся лид с каналом и источником. Менеджер получает уведомление с сутью обращения.
Последовательность простая: канал передал сообщение — модель разобрала поля — телефон привели к единому формату — CRM нашла контакт или создала лид — менеджер получил уведомление. На каждом шаге у заявки становится меньше шансов остаться просто письмом, сообщением в чате или строкой в таблице.
В подтверждённой схеме участвуют сайт, мессенджеры через Wazzup, ВКонтакте, почта и CRM. Телефония и 1С не входят в неё автоматически. Их подключение зависит от конкретного проекта: добавлять такие стыки можно, только если они действительно нужны и предусмотрены схемой внедрения.
Где работает модель и что происходит с данными
По умолчанию проект строится в закрытом контуре: данные заявок не покидают периметр. Облачную модель можно использовать только с письменного согласия. Какой вариант подходит, подтверждаем при внедрении.
Это нужно определить до подключения источников. От контура зависит, где обрабатывается обращение и какие доступы потребуются. Поэтому условия работы с данными согласуются для конкретного проекта, а не переносятся автоматически с одной компании на другую. Обещать больше, чем подтверждено для выбранного контура, нельзя.
Что меняется на практике и где нужен человек
Заявки из разных источников приводятся к общему формату. Повторное обращение по тому же телефону связывается с существующим контактом, а новый клиент попадает в CRM с каналом и источником. Менеджеру не нужно вручную перекладывать поля из каждого сообщения, чтобы понять, кто написал и откуда пришла заявка.
Но сценарий не принимает решение за менеджера и не разбирает спорные случаи самостоятельно: такие заявки проверяет человек. Каналы подключаются по одному, у каждого свои доступы. Нормализация телефона проходит через внешний сервис. Эти границы важны: входящие приводятся в порядок и передаются дальше, а оценка ситуации и следующий шаг по клиенту остаются за человеком.
С чего начинается внедрение
Сначала выбираем CRM и каналы, которыми компания уже пользуется. Затем проверяем доступы и согласуем контур обработки данных. После этого источники подключаются по одному, а сценарий настраивается так, чтобы разобрать заявку, найти контакт или создать лид и уведомить менеджера.
Смысл не в количестве подключённых каналов. Важно, чтобы путь от сообщения до карточки CRM совпадал с тем, как компания принимает обращения и работает с ними. Если клиент написал в несколько мест, в CRM появляется понятная запись с каналом и источником, а менеджер видит суть обращения и может продолжить работу.
Посмотреть, как выглядит разбор звонка за 24 часа, можно в примере отчёта Ревизора.