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

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

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

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

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

Для небольшого отдела поддержки уже 80–120 входящих писем в день создают ощутимую нагрузку. Если первичное чтение одного письма занимает 45–90 секунд, то на сортировку уходит от 1 до 3 часов чистого времени ежедневно. Это без ответов, уточнений и переключения между вкладками. Нейросеть снимает именно первый слой работы: понять, о чём письмо, куда его отправить, чего не хватает для ответа.

Типовая карточка после обработки может выглядеть так:

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

Такой формат хорош тем, что его легко проверить глазами за 10–15 секунд. Если модель ошиблась с тоном, оператор поправит. Если она пропустила номер заказа, это видно в карточке. Главное, команда больше не начинает с пустого экрана.

Архитектура решения: от входящего письма до черновика

Я обычно раскладываю процесс на 7 шагов. Сначала письма попадают в общий ящик или Helpdesk. Затем интеграция передаёт в ИИ тему, тело письма, вложения и историю цепочки, если она нужна. После этого модель возвращает структурированный результат: категорию, краткое резюме, приоритет, поля для CRM, черновик ответа и флаг «нужен человек».

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

Условный пример: если компания получает 300 писем в день и 35% из них относятся к трём повторяемым темам, «не пришёл чек», «не могу войти», «где заказ», то ИИ может заранее разложить около 105 обращений по понятным очередям. Это не означает 105 автоматических ответов. Это означает, что оператор открывает письмо уже с краткой выжимкой и предложенным следующим шагом.

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

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

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

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

Пример для иллюстрации:

«Ты помогаешь оператору поддержки сортировать письма. Прочитай сообщение клиента и верни результат строго по структуре: 1) категория из списка: оплата, доступ, доставка, возврат, техническая ошибка, документы, жалоба, другое; 2) краткая суть до 25 слов; 3) срочность: низкая, средняя, высокая; 4) какие данные уже есть; 5) каких данных не хватает; 6) черновик ответа до 90 слов; 7) нужна ли передача человеку, да или нет. Если информации мало, не додумывай факты».

В этом промпте есть 4 защитных элемента. Во-первых, закрытый список категорий. Во-вторых, лимит на резюме и черновик. В-третьих, явный запрет додумывать. В-четвёртых, поле «нужна ли передача человеку». Без последнего пункта модель иногда пытается отвечать там, где надо эскалировать.

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

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

Как оценивать качество сортировки

У ИИ в поддержке должны быть метрики, иначе команда быстро спорит на уровне ощущений. Я смотрю минимум на 6 показателей.

Первый, точность категории. Берём выборку из 100–200 писем и сравниваем разметку модели с разметкой старшего оператора. Для повторяемых тем хороший стартовый ориентир, 80–90% совпадений после настройки категорий. Второй, доля писем с корректным приоритетом. Здесь ошибки дороже: письмо с угрозой возврата или жалобой нельзя класть в обычную очередь.

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

Условный пример: на выборке из 150 писем команда может получить 132 верные категории, 11 спорных и 7 неверных. Это 88% точности по категориям. Но если 4 из 7 ошибок связаны с жалобами и возвратами, внедрение нельзя считать готовым. В поддержке одна неверно заниженная жалоба вреднее десяти неточно размеченных вопросов про график работы.

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

Где автоматизация помогает, а где опасна

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

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

Я не советую начинать с полной автоотправки писем. Здоровая первая версия выглядит так: ИИ сортирует, резюмирует и пишет черновик, оператор проверяет и отправляет. Через 2–4 недели можно выделить безопасные категории, где ответы почти не требуют правки. Например, запрос инструкции, подтверждение получения заявки, просьба прислать номер заказа. Даже там нужен журнал ошибок и кнопка быстрого отката шаблона.

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

Обновление про модели и инструменты

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

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

Для поддержки это полезно не как обещание идеального результата, а как защита от пустого ответа в момент разбора очереди. Когда оператор обрабатывает 40 писем подряд, сбой на одном сообщении не должен ломать ритм работы.

Практический план внедрения на 10 рабочих дней

День 1: выгрузите 100–200 писем за последний месяц. Уберите персональные данные, если тестируете процесс вне боевой среды. Разделите письма на категории вручную.

День 2: соберите список категорий. Не делайте 30 пунктов на старте. Обычно хватает 8–12: оплата, доступ, доставка, возврат, документы, техническая ошибка, жалоба, консультация, другое.

Дни 3–4: напишите промпт и прогоните первую выборку. Сравните разметку модели с ручной. Отдельно выпишите ошибки по жалобам и денежным вопросам.

День 5: добавьте правила эскалации. Например: «если клиент просит возврат больше 14 дней после покупки, не обещай возврат, передай человеку»; «если в письме есть угроза жалобы, высокий приоритет».

Дни 6–7: настройте формат черновика. Один стиль приветствия, один формат извинения, запрет на обещания без основания, обязательный запрос недостающих данных.

День 8: проверьте 50 новых писем, которых не было в обучающей выборке промпта. Это показывает, не подогнали ли вы инструкцию под старые примеры.

День 9: отдайте инструмент двум операторам и соберите пометки: где черновик помог, где мешал, где тон звучал сухо.

День 10: примите решение. Если точность категорий выше 85%, критичных ошибок нет, а больше половины черновиков требуют только лёгкой правки, можно запускать пилот на одной очереди.

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

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

Вторая ошибка, смешивать сортировку и финальное решение. Категория «возврат» не равна решению «вернуть деньги». Категория «ошибка» не равна признанию вины. Разделяйте ярлык письма, факты и действие.

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

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

Заключение: что изменилось в обновлённой версии

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

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