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

Когда входящих больше 30–40 в день, ручная сортировка начинает съедать утро. Сначала менеджер открывает письмо, потом ищет номер заказа, затем вспоминает SLA, затем пишет почти тот же ответ, что вчера. Через 2 часа очередь стала короче на 8 сообщений, а новые 12 уже пришли. Я вижу в таких задачах не магию, а нормальную редакторскую механику: дать нейросети правила, запретить домыслы, заставить её отделять факты от предположений и показывать, чего не хватает для ответа.

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

Разбор входящего обращения4 шага, которые снижают шум и не поощряют домыслы1КлассP1, P2, P3 или P42Фактысрок, сумма, объект3Пробелычто нужно уточнить4Черновикответ без обещанийПравило проверки: если факта нет в тексте, ответ помечает пробел, а не придумывает деталь
Инфографика

Почему входящие быстро превращаются в очередь без конца

Если в день приходит 80 обращений, а первичный разбор одного занимает 2 минуты, команда тратит 160 минут только на сортировку. При 5 рабочих днях это уже 13 часов в неделю, без учёта ответов, уточнений и повторных касаний.

Проблема редко в одном письме. Одно обращение может содержать 6 сущностей: имя клиента, номер заказа, дату, канал оплаты, проблему, желаемый срок. Менеджер держит это в голове, переключается между вкладками и легко пропускает одно поле. При 100 сообщениях в день даже ошибка в 3% даёт 3 обращения, где клиент получит неточный ответ или уйдёт в неверную очередь.

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

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

Что именно ИИ может сделать с письмом или заявкой

Рабочее место менеджера с карточками приоритетов для разбора входящих обращений

Для одного обращения нейросеть может выполнить 5 полезных операций: определить тему, поставить приоритет, извлечь факты, сжать суть до 2–4 строк и подготовить черновик ответа. На пачке из 50 сообщений это уже не «помощь с текстом», а фильтр, который экономит первый час смены.

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

Условный пример: заявка «оплатили счёт 15 июля, доступ не включился, завтра старт группы на 27 человек» должна получить приоритет P1 или P2, потому что есть дата, оплаченная услуга и риск срыва для 27 участников. Черновик ответа в таком случае не должен обещать «решим за 10 минут», если этого нет в правилах команды. Правильнее написать: «Проверю оплату и статус доступа, вернусь с подтверждением до 14:00».

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

Слабое место многих внедрений в том, что ИИ просят сразу «ответить красиво». Я бы начинал с короткой выжимки. Формат на 4 строки: что случилось, кто пишет, что уже известно, что нужно сделать. После такой выжимки менеджер за 20–30 секунд понимает суть без чтения длинной переписки.

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

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

Сначала задайте закрытые классы. Не «важное» и «обычное», а P1, P2, P3, P4 с коротким правилом для каждого уровня. P1: сервис недоступен, деньги списаны дважды, событие сегодня, юридический риск. P2: оплата, доступ, перенос сроков, повторное обращение за 24 часа. P3: обычный вопрос, документ, консультация. P4: спам, дубль, нерелевантное сообщение.

Затем попросите извлечь факты. Не выводы, а именно факты из текста. Хороший формат выглядит так:

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

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

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

Где проходит граница между чатом и автоматизацией

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

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

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

Если команда впервые переносит такую работу в ИИ-контур, лучше не начинать с полной автоматизации. Сначала 7 дней ручного пилота, затем 100 размеченных обращений, затем правила приоритета, затем проверка на новой выборке. Этот путь хорошо сочетается с практикой из материала как внедрить нейросети в рабочие процессы: маленький повторяемый сценарий быстрее даёт пользу, чем большой проект без метрик.

Подход Подходит при объёме Что получает менеджер Риск
Ручной разбор без ИИ до 20 обращений в день полный контроль много рутины, нет единого формата
Чат с шаблоном 20–50 обращений в день выжимку, приоритет, черновик нужно копировать данные вручную
Полуавтоматический контур 50–200 обращений в день очередь, единые классы, контроль качества нужен владелец процесса
Автоматическая маршрутизация от 200 обращений в день быстрый первичный фильтр ошибки правил бьют по SLA

Как измерять качество разбора входящих

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

Точность приоритета проверяется просто: человек ставит эталон P1–P4, затем сравнивает с выводом нейросети. Если из 100 обращений 8 получили завышенный приоритет, это неприятно, но не катастрофа. Если 3 срочных запроса попали в P3, это уже риск для SLA. Ошибка вниз дороже ошибки вверх.

Полнота фактов измеряется по полям. Взяли 100 писем, где в 64 есть номер заказа. Модель нашла 60 номеров, 4 пропустила, 1 придумала. Последний случай самый опасный. В рабочем процессе лучше терпеть «нет данных», чем красивый номер, которого не было в письме.

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

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

Практический финал: как я бы запускал это на месте менеджера

Я бы начал с 7 дней и 100 реальных обращений, без интеграций и сложной архитектуры. Цель первого этапа одна: понять, какие классы, поля и запреты дают стабильный разбор хотя бы в 80–90 случаях из 100.

Мой рабочий порядок был бы таким. В первый день собрать 30–50 типичных сообщений и руками разметить P1–P4. На второй день написать промпт с таблицей полей и запретом на домыслы. На третий день прогнать новую пачку и выписать ошибки. На четвёртый и пятый день разделить ошибки на 3 группы: неверный приоритет, пропущенный факт, лишнее обещание в ответе. На шестой день поправить правила. На седьмой день дать схему второму менеджеру и посмотреть, повторяется ли результат без автора промпта.

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