ИИ для сортировки лидов и черновиков ответов в 2026

Разбираю, какие операции можно передать нейросети на первом контакте с клиентом, а где менеджеру нужно оставить решение за собой.

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

Что можно делегировать ИИ в первом касании

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

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

1. Намерение. Покупка, вопрос по действующему заказу, претензия, запрос документов или техническая проблема.
2. Сигналы сделки. Продукт, количество, бюджет, срок, регион и способ связи, если клиент их назвал.
3. Срочность. Есть ли дедлайн, остановилась ли работа, ожидает ли клиент ответ до конкретной даты.
4. Следующее действие. Уточнить параметр, отправить инструкцию, передать менеджеру или запросить номер заказа.

Не нужно заставлять модель пересказывать сообщение на 500 слов. Практичнее попросить короткий результат из 6 полей: категория, приоритет, факты, неизвестные данные, черновик ответа и причина передачи человеку. Пустые значения лучше обозначать словом «не указано», а не заполнять догадками.

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

Как устроить маршрут от сообщения до менеджера

Рабочая схема состоит из 5 этапов и 2 контрольных порогов: проверка полноты данных перед черновиком и проверка риска перед отправкой клиенту.

1. Получение и нормализация текста

Сообщение может содержать приветствие, вопрос, номер заказа и несколько тем сразу. Сначала модель отделяет факты от эмоциональных формулировок. Фраза «срочно спасите, всё сломалось» не объясняет проблему, пока не выяснено, что именно перестало работать и когда это произошло.

В запросе полезно задать формат:

Верни результат в 6 разделах:
категория;
приоритет от 0 до 2;
подтверждённые факты;
неизвестные данные;
черновик ответа;
причина передачи менеджеру.
Не придумывай сведения, которых нет в сообщении.

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

2. Определение намерения

Категорий должно быть меньше, чем кажется на старте. Для небольшой команды обычно достаточно 5–7 устойчивых классов. Если добавить 20 почти одинаковых меток, сотрудники начнут выбирать их по-разному, а статистика потеряет смысл.

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

3. Извлечение коммерческих сигналов

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

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

4. Расчёт приоритета

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

Для каждого признака можно назначить 0, 1 или 2 балла. Однако итоговая сумма не должна автоматически отправлять сообщение клиенту. Она лишь помогает выстроить очередь. Если клиент указал дедлайн через 2 часа, но просит юридически значимое подтверждение, обращение получает высокий приоритет и обязательную передачу человеку.

5. Подготовка и передача

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

Как настроить приоритет без ложной срочности

Приоритет лучше считать по 3 осям, а каждую ось оценивать от 0 до 2 баллов: ценность возможности, срочность и риск ошибки. Это даёт рабочую шкалу от 0 до 6, но итог всегда проверяет человек.

Ценность возможности

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

Срочность

Срочность связана с датой или последствием. Запрос «нужен ответ до 14:00» отличается от «ответьте, когда сможете». Сообщение о сбое действующего процесса требует отдельного маршрута, даже если коммерческой сделки в нём нет.

Риск ошибки

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 80 обращений в день. Если модель присвоит приоритет 6 сообщению без номера заказа, менеджер сначала проверит отсутствие ключевого поля, а не будет считать оценку доказанным фактом.

Как должен выглядеть полезный черновик ответа

Хороший черновик состоит из 3 блоков и обычно укладывается в 60–120 слов: подтверждение сути запроса, конкретный следующий шаг и один уточняющий вопрос.

Первый блок показывает клиенту, что его сообщение прочитали. Вместо «Ваш запрос принят в обработку» лучше написать: «Вы подбираете 10 лицензий для запуска в августе, верно?» Если число или срок не подтверждены, нужно использовать осторожную формулировку: «Я правильно понял, что речь примерно о 10 лицензиях?»

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

Третий блок содержит один главный вопрос. Когда в конце стоит 5 уточнений, клиент часто отвечает на одно и пропускает остальные. Последовательное уточнение помогает быстрее заполнить карточку и не перегружает первое сообщение.

Для примера: если клиент спрашивает о 3 вариантах тарифа и пишет, что запуск нужен через 2 недели, черновик может подтвердить задачу, попросить число пользователей и сообщить, что менеджер сравнит варианты после получения этого параметра. Модель не должна самостоятельно выбирать тариф, если правила выбора не заданы.

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

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

Какие проверки нужны перед внедрением

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

Проверка категории

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

Проверка фактов

Сверяйте каждое число, дату, название продукта и обещание. Если клиент написал «до конца месяца», модель не должна превращать это в «31 число», потому что календарная дата не была названа. Полезно считать число добавленных моделью фактов отдельно от числа пропущенных фактов.

Проверка тона

Согласуйте 5–7 правил: обращение на «вы», отсутствие давления, короткие абзацы, запрет на неподтверждённые обещания и понятное объяснение следующего шага. Тон проверяется на жалобах, отказах и запросах о цене, а не только на нейтральных вопросах.

Проверка передачи человеку

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

Гипотетический пример: команда из 8 менеджеров тестирует шаблон на 40 сообщениях в течение 2 недель. Если в 6 диалогах модель додумала срок или сумму, запускать автоматическую отправку нельзя, даже если категории распределены верно.

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

Что выбрать: ручную работу, черновики или автоответ

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

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

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

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

Как я бы принял решение на практике

Я бы оставил за ИИ сортировку, извлечение фактов и первый вариант текста, а за менеджером, цену, обязательства, спорные случаи и финальное решение. На старте я зафиксировал бы 6 полей результата, шкалу 0–6 и набор из 40 обезличенных сообщений.

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

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