ИИ для отдела продаж: как автоматизировали оценку заявок перед звонком

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

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

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

Это не история про «ИИ-продавца», который сам ведёт переговоры. Здесь модель решает одну ограниченную задачу: помогает разобрать доступные данные до звонка.

Что происходило до автоматизации

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

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

Получалось сразу несколько проблем:

• одна и та же исследовательская работа повторялась для каждой новой заявки;
• качество первичной оценки зависело от опыта и внимательности менеджера;
• порядок работы определялся вручную и мог зависеть от субъективной оценки сотрудника;
• критерии перспективной заявки не были встроены в единый автоматизированный процесс.

Самый простой ответ — добавить в CRM поле «горячий / тёплый / холодный». Но кто и на основании чего должен его заполнять? Если это снова делает менеджер вручную, процесс почти не меняется.

Сначала нужны данные и единые критерии.

Почему автоматическая оценка — это не просто один балл

Скоринг лидов обычно воспринимают как число: например, заявка получила 82 балла и поэтому должна оказаться выше заявки с 57 баллами. Но само число пользы не даёт. Оно должно быть связано с понятными бизнес-признаками.

В системах lead scoring обычно разделяют как минимум два типа сигналов:

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

Такое разделение используется, например, в инструментах HubSpot: fit score оценивает соответствие профилю, engagement score — действия и взаимодействия, а итоговый результат можно применять в CRM-представлениях, отчётах и workflow.

Для этого проекта важен был ещё один слой — интерпретация информации, которую трудно свести к жёсткой формуле. Описание компании, содержание обращения и контекст предыдущих взаимодействий могут быть написаны свободным текстом. Здесь ИИ действительно полезен.

Но не во всём процессе.

Как устроили автоматизацию обработки заявок

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

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

1. Новая заявка запускает обработку

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

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

2. Обычные правила проверяют исходные данные

Перед обращением к модели стоит нормализовать контакты, проверить обязательные поля и определить, достаточно ли информации для оценки. Если не указан телефон, повреждён email или отсутствует критически важное поле, незачем просить ИИ «догадаться».

Такие проверки надёжнее выполнять обычным кодом или workflow. Результат однозначен: поле либо соответствует правилу, либо нет.

3. Данные из CRM и Sendsay собираются в единый профиль

Следующий шаг — обогащение карточки. Процесс объединяет сведения, доступные в CRM и Sendsay, чтобы оценка строилась не по одному полю формы, а по более полному контексту.

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

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

4. ИИ-модель оценивает неоднозначную часть

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

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

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

5. Бизнес-правила формируют очередь менеджера

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

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

Что поручили правилам, модели и человеку

Шаг процесса	Кто выполняет	Почему
Проверка телефона, email и обязательных полей	Правила	Результат можно определить однозначно
Поиск дублей и получение данных из систем	Workflow	Нужна предсказуемая интеграция
Проверка явных стоп-факторов	Правила	Критерии заранее известны
Интерпретация описания компании и текста заявки	ИИ-модель	Формулировки неоднозначны
Присвоение рабочего приоритета	Правила после оценки	Маршрут должен оставаться контролируемым
Решение о звонке и дальнейшей квалификации	Менеджер	Нужны ответственность и контекст разговора

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

Чем меньше действий у модели, тем проще проверить ошибку.

Когда нужен ИИ, а когда достаточно обычного скоринга

Если критерии полностью формализованы, ИИ может оказаться лишним. Допустим, компания работает только с определёнными регионами, минимальным объёмом заказа и конкретными отраслями. Тогда баллы можно рассчитать обычными условиями в CRM или workflow.

ИИ имеет смысл подключать, когда значимая информация находится в свободном тексте или требует интерпретации:

• клиент описывает задачу своими словами;
• профиль компании нельзя определить по одному справочнику;
• нужно сопоставить несколько слабых сигналов;
• ручные правила разрастаются и всё равно не покрывают реальные формулировки.

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

Например, Microsoft Dynamics 365 строит predictive lead scoring на исторических квалифицированных и дисквалифицированных лидах и требует минимальный объём размеченных записей для обучения модели. Конкретные пороги относятся к продукту Microsoft, но общий вывод переносим: если в CRM нет последовательной истории результатов, предиктивная модель будет учиться на шуме.

Для первого пилота малого или среднего бизнеса часто рациональнее начать проще:

1. согласовать критерии с руководителем продаж;
2. оставить однозначные признаки обычным правилам;
3. использовать ИИ только для разбора неструктурированного контекста;
4. собирать решения менеджеров для последующей проверки и улучшения.

Что происходит при ошибке

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

Поэтому рабочий workflow должен не скрывать ошибки, а фиксировать их и выбирать безопасный сценарий:

• повторить временно неудачный запрос;
• сохранить исходную заявку;
• не затирать предыдущие данные пустым ответом;
• отправить запись в ручную очередь;
• уведомить ответственного после нескольких неудачных попыток.

В документации n8n для производственных workflow отдельно предусмотрены обработка ошибок, повторные запуски и error workflow, который получает сведения о сбое. Конкретный инструмент может быть другим, но сама логика обязательна: отсутствие оценки лучше ошибочного «уверенного» приоритета.

Как проверять такой пилот

Оценивать проект только по средней величине балла бессмысленно. Нужны метрики самого процесса.

На пилоте стоит проверить:

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

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

Условие успеха здесь не «ИИ угадал всё». Условие успеха — команда получает более полезную очередь и тратит меньше ручных действий на её подготовку.

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

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

Команда быстрее видит приоритетные заявки. Это и есть подтверждённый результат кейса.

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

Когда такой подход не подойдёт

Проект не стоит начинать с ИИ-скоринга, если:

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

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

Модель не создаст порядок из данных, которым никто не доверяет.

Вывод

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

В этом кейсе такой операцией стало изучение потенциального клиента перед звонком. CRM, Sendsay и ИИ-модель объединили в один управляемый процесс: данные собираются, заявка оценивается, а менеджер видит приоритет и продолжает работу сам.

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

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

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

Что такое скоринг лидов?

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

Можно ли запустить оценку заявок без большой истории продаж?

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

Нужно ли показывать менеджеру точный балл?

Не обязательно. Для рабочего процесса могут быть полезнее категории приоритета и признаки, которые требуют внимания. Главное, чтобы результат помогал выбрать следующее действие, а не создавал ещё одно поле в CRM.

Можно ли автоматически отклонять заявки с низкой оценкой?

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