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

Когда заявок мало, ручная обработка кажется нормальной: открыть письмо, скопировать имя, телефон, город, товар, комментарий, поставить статус, назначить ответственного. На 5 заявках в день это терпимо. На 50 уже появляются задержки, дубли, потерянные вложения и странные карточки вида «Иван, срочно, перезвонить». Я отношусь к обработке заявок как к конвейеру данных, а не как к «магии нейросети». Если разложить путь заявки на шаги, становится видно, где языковая модель действительно экономит время, а где нужны обычные правила, валидация и контроль.

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

Где теряется время менеджера

Входящая заявка редко приходит в идеальном формате. В форме на сайте клиент может заполнить поле «Комментарий» так: «Нужны 3 комплекта, доставить в Казань, счёт на ООО, звонить после 15». В почте он добавит вложение с реквизитами. В мессенджере отправит голосовую расшифровку, два сообщения подряд и исправление: «Не Казань, а Набережные Челны».

Ручная работа распадается на несколько мелких действий. Их трудно автоматизировать одним правилом, потому что язык живой. Менеджер читает текст, понимает намерение, отделяет контакт от пожеланий, ищет срочность, проверяет, не дубль ли это, потом переносит всё в CRM. Даже если на одну заявку уходит 3 минуты, 40 заявок дают 2 часа чистого копирования и проверки в день. Это не учёт звонков, уточнений и ошибок.

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

Как устроен конвейер обработки заявки

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

Этап Что делает система Пример результата Где нужен контроль
Приём Забирает текст из формы, письма или сообщения «Нужна доставка 3 комплектов в Казань» Кодировка, вложения, дубли
Очистка Убирает подписи, цитаты переписки, лишний шум Остаётся последнее сообщение клиента Длинные цепочки писем
Извлечение Выделяет поля: имя, телефон, город, товар, срок город: «Казань», количество: 3 Неявные формулировки
Нормализация Приводит значения к единому виду телефон в одном формате, дата в ISO Опечатки и неполные даты
Классификация Назначает тип, приоритет, тему «новая продажа», «высокий приоритет» Граница между срочным и обычным
Запись Передаёт данные в CRM или промежуточную таблицу создана карточка лида Права доступа и конфликт дублей

Здесь нейросеть чаще всего работает на трёх этапах: очистка, извлечение, классификация. Передача в CRM обычно делается через API, встроенный коннектор, сценарий автоматизации или промежуточную очередь. Это уже инженерная часть. Модель не должна сама «решать всё», ей лучше дать узкую задачу: превратить текст заявки в проверяемый JSON со списком полей и уровнем уверенности.

Что именно извлекать из заявки

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

Для примера: сообщение «Здравствуйте, хочу узнать цену на монтаж 12 камер в офисе, Москва, нужно до конца месяца, пишите в WhatsApp» можно превратить в такую структуру: тип услуги, количество объектов, город, дедлайн, предпочтительный канал связи. Часть данных точная, часть требует уточнения. Бюджета нет, поэтому поле лучше оставить пустым, а не выдумывать значение.

Хорошая схема извлечения всегда хранит неясность. Я прошу модель возвращать не просто поле, а статус: «найдено», «не найдено», «требует уточнения». Для CRM это критично. Пустое поле «бюджет» и поле «бюджет не указан» выглядят похоже, но управляются по-разному: во втором случае менеджер понимает, что нужно задать вопрос.

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

Промпт для извлечения: что в нём должно быть

Слабый промпт звучит так: «Разбери заявку и занеси в CRM». В нём нет схемы, нет формата, нет правил для пропусков. Модель может ответить красивым абзацем, но автоматизации такой ответ не поможет.

Рабочая инструкция должна задавать формат результата. Например: верни JSON, используй только поля из списка, не добавляй неизвестные поля, не придумывай отсутствующие данные, для спорных значений ставь confidence от 0 до 1, сохрани исходную цитату, на основании которой извлечено значение. Последняя часть особенно полезна при разборе ошибок. Если модель указала город «Казань», менеджер или тестировщик видит фрагмент, откуда это взято.

Гипотетический пример: заявка «Нужны окна в новый дом, 8 штук, участок под Зеленоградом, телефон в подписи» после обработки может получить confidence 0,95 для количества, 0,75 для локации и 0 для бюджета. Это честнее, чем заполнить все поля ради красивой карточки.

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

Формы, почта и мессенджеры: чем отличаются источники

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

Почта сложнее. В письмах есть подписи, пересланные цепочки, вложения, старые цитаты. Если не очистить письмо, модель может взять номер телефона из подписи менеджера, а не клиента. Поэтому перед извлечением нужен этап отсечения служебного текста: убрать блоки «Отправлено с телефона», старые ответы, юридические подписи и рекламные баннеры. Для длинных писем я предпочитаю сначала попросить краткое резюме фактов, затем извлекать поля из резюме и исходника.

Мессенджеры дают самый живой язык. Клиент может писать частями: «Добрый», «по доставке», «у нас 20 коробок», «адрес потом скину». Здесь нужна группировка сообщений в одну сессию. Если каждое сообщение обрабатывать отдельно, получится четыре неполные заявки. Практически это решают окном времени, например объединяют сообщения одного контакта за 10–20 минут, пока не появится явный признак завершения.

Как проверять качество извлечения

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

Условный пример: на выборке из 200 исторических заявок команда может вручную разметить правильные значения, затем сравнить их с результатом модели. Если телефон извлечён правильно в 196 случаях, а бюджет только в 70, это не провал. Возможно, бюджет в текстах почти не указывали. Тогда для бюджета нужна категория «не указан», а не попытка угадать.

Я бы закладывал ручную проверку на первых неделях. Не потому, что нейросети нельзя доверять, а потому что бизнес-словарь у каждой компании свой. «Комплект», «точка», «объект», «линия», «пакет» в разных нишах означают разные сущности. После 100–300 размеченных заявок обычно становится понятно, какие поля стабильны, а какие требуют уточняющих вопросов.

Как связать результат с CRM без хаоса

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

В CRM лучше передавать не весь ответ модели, а нормализованный объект. Например: contact_name, phone, city, request_type, requested_product, deadline, priority, source_text, confidence. Поле source_text нужно для аудита. Когда менеджер видит исходную фразу клиента, он быстрее понимает контекст и не спорит с «чёрным ящиком».

Не все данные должны сразу попадать в основные поля. Для спорных значений удобнее завести блок «предложено нейросетью» или служебный комментарий. Если confidence ниже порога, запись можно отправить на проверку. Практичный порог часто задают отдельно по полям: для телефона 0,9 и выше, для темы обращения 0,75, для приоритета 0,65. Это пример настройки, а не универсальная норма.

Где здесь место SoftChat

Я использую чат на ранней стадии проектирования: собрать список полей, написать инструкцию для извлечения, прогнать 20–30 обезличенных заявок, найти неоднозначности. В SoftChat для такого сценария есть веб-чат с потоковыми ответами, история диалогов, шаблоны промптов и сохранённые ассистенты, которые можно подключать к открытому чату. Это удобно, когда один ассистент играет роль аналитика заявок, другой проверяет формат JSON, а третий критикует схему полей.

Настройки чата помогают подстроить ответ под задачу: для текста доступны понятные параметры вроде «Креативность» и «Длина ответа», а набор настроек зависит от выбранной модели. Я бы ставил низкую креативность для извлечения данных, потому что здесь ценится предсказуемость. Для генерации вариантов уточняющих вопросов можно дать больше свободы.

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

Частые ошибки при запуске

Первая ошибка, слишком широкая задача. Команда просит модель «вести заявку», хотя ей нужно только извлечь 10 полей. Чем уже задача, тем проще тестировать качество.

Вторая ошибка, отсутствие эталонной разметки. Если нет 100–200 примеров с правильными ответами, спор о качестве превращается во вкусовщину. Один менеджер скажет, что приоритет высокий, другой поставит средний. Поэтому критерии нужно описать словами и примерами.

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

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

Что бы я сделал на вашем месте

Я бы начал не с интеграции, а с инвентаризации входящих заявок за последние 2–4 недели. Выгрузил бы тексты, убрал персональные данные для тестов, выделил 10 полей, которые реально нужны менеджеру, и разметил хотя бы 100 примеров. После этого можно писать промпт, проверять точность и решать, какие поля готовы к автоматической записи.

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

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