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

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

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

Где автоматизация заявок окупается быстрее всего

Лучшие кандидаты для старта, это повторяемые входящие сообщения с похожей структурой. Например, формы обратной связи, письма с коммерческими запросами, заявки на демо, обращения в поддержку, ответы на рассылку и входящие от партнёров. Если в потоке 30–50 сообщений в день, ручная сортировка уже забирает заметное время. На 200–300 сообщений в день без правил качества обычно растёт очередь, а менеджеры начинают заводить сделки по-разному.

Условный пример: компания из сферы B2B-услуг получает 120 писем в день, из них 45 относятся к новым лидам, 30 к текущим клиентам, 15 к счетам и актам, остальное к рассылкам и нерелевантным обращениям. Если человек тратит на первичный разбор 40 секунд, только сортировка занимает около 80 минут в день. ИИ-классификатор в таком сценарии не обязан отвечать клиенту. Его задача скромнее и полезнее: пометить тип письма, вытащить 6–12 полей и передать данные в следующий шаг.

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

Базовая схема: от письма до карточки в CRM

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

Шаг Что делает система Что проверять Типичная ошибка
1. Приём Забирает письмо или форму Источник, дата, вложения Потеря пересланного текста
2. Очистка Убирает подписи, цитаты, мусор Остался ли основной запрос Модель читает старую переписку
3. Классификация Назначает тип обращения Метка и уверенность Все письма становятся «новыми лидами»
4. Извлечение Достаёт поля Телефон, почта, компания, тема Поле взято из подписи другого человека
5. Нормализация Приводит формат Телефон, сумма, дата, город Дата «в пятницу» не преобразована
6. Проверка Решает, можно ли писать в CRM Обязательные поля и дубли Создана пустая сделка
7. Запись Создаёт или обновляет сущность ID операции и ответ API Дубликат клиента вместо обновления

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

Классификация: не делайте слишком много классов

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

Для примера: минимальный набор меток может включать 6 классов, «новый лид», «действующий клиент», «документы», «поддержка», «партнёрство», «мусор». Этого достаточно, чтобы разделить создание сделки, обновление контакта, постановку задачи и игнорирование письма. Более детальная таксономия понадобится позже, когда появится статистика ошибок.

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

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

Извлечение данных: схема важнее красивого ответа

После классификации начинается извлечение. Здесь нейросеть должна вернуть структурированный объект, например: тип обращения, имя, компания, должность, телефон, почта, город, продуктовый интерес, бюджет, срок, комментарий, источник. Для части полей допустимо значение null. Это лучше, чем выдуманная почта или «примерный» бюджет.

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

Условный пример: письмо «Добрый день, хотим рассчитать внедрение для отдела продаж на 25 человек, бюджет обсудим после созвона, Анна, ООО Ритм» лучше превратить не в краткое резюме, а в объект: компания, «ООО Ритм»; контакт, «Анна»; потребность, «расчёт внедрения для отдела продаж»; размер команды, 25; бюджет, null; следующий шаг, «созвон». Маркер null помогает системе не записывать в CRM несуществующую сумму.

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

Как связать ИИ и CRM без участия человека

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

Перед записью в CRM нужны проверки. Минимальный набор: валидность почты, формат телефона, наличие обязательных полей, поиск дубля по почте и телефону, запрет записи при низкой уверенности, журнал ошибок. Для B2B-сделок я бы добавил нормализацию названий компаний: «ООО Ромашка», «Ромашка ООО» и «Romashka» часто относятся к одному контрагенту, но модель не должна принимать финальное решение без правил сопоставления.

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

Выбор подхода: правила, ИИ или гибрид

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

Подход Когда подходит Сильная сторона Ограничение
Правила и регулярные выражения Формы с фиксированными полями, одинаковые письма Быстро, прозрачно, легко тестировать Плохо работает со свободным текстом
ИИ-классификация Разные формулировки, пересланные письма, смешанные темы Понимает смысл и контекст Нужны примеры, пороги и контроль ошибок
Гибрид Большинство CRM-сценариев ИИ читает смысл, код валидирует поля Сложнее запуск, требуется журналирование
Ручная очередь после ИИ Высокая цена ошибки, сложные сделки Менеджер видит готовую выжимку Не даёт полной автономности на старте

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

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

Метрики качества: что измерять до автозаписи

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

На старте хватит разметки 200–500 старых писем, если поток однотипный. Для сложной B2B-переписки выборку лучше расширять и обновлять: новые продукты, сезонные акции и изменения в форме заявки быстро меняют язык клиентов. После запуска я бы смотрел не только общую точность, а матрицу ошибок. Если «документы» иногда путаются с «новым лидом», это терпимо при ручной проверке. Если «действующий клиент» уходит в «мусор», маршрут опасен.

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

Промпт для извлечения: рабочий каркас

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

Роль: ты классифицируешь входящие сообщения для CRM.
Задача: верни только структурированный объект по заданной схеме.
Классы: новый лид, действующий клиент, документы, поддержка, партнёрство, мусор.
Если данных нет, ставь null. Не придумывай телефон, бюджет, компанию и имя.
Если уверенность ниже 0.75, поставь needs_review: true.
Если письмо содержит несколько тем, выбери основной класс и перечисли вторичные.
Проверь, что ответ можно передать в API без ручного редактирования.

После этого добавляются 10–20 примеров. Не абстрактные, а похожие на реальные письма: короткие заявки, пересланные цепочки, письма без подписи, сообщения с двумя контактами, запросы с вложениями. Хорошие примеры снижают число пограничных ошибок сильнее, чем длинное вступление в промпте.

Если нужно глубже про работу с текстовыми черновиками, полезен материал про генерацию текста и проверку результата. В CRM-автоматизации проверка ещё строже: результат должен быть пригоден для машины, а не просто читабелен для человека.

Контроль рисков: когда человека нельзя убирать сразу

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

Практичный порог выглядит так: автозапись разрешена, если класс входит в безопасный список, уверенность выше заданного уровня, обязательные поля заполнены, дубликат не найден или найден однозначно. Всё остальное уходит в очередь «проверить». Эта очередь не провал автоматизации. Она защищает CRM от ошибок и даёт материал для дообучения процесса через новые примеры.

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

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

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

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

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