ИИ в поддержке и продажах: разбор обращений в 2026

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

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

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

Что именно сортирует нейросеть в обращениях

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

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

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

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

Как строится маршрут от входящего текста до очереди

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

Сначала обращение надо привести к читаемому виду. В письмах бывают подписи на 20 строк, вложенные переписки, цитаты старых сообщений, автоматические футеры. В чатах другая проблема: клиент пишет 4 коротких сообщения подряд, и каждое само по себе неполное. Нейросети проще работать, когда ей передают цельный фрагмент: вопрос, контекст, доступные данные, историю последних 2–3 реплик.

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

Условный пример: интернет-сервис с 6 категориями обращений может попросить модель вернуть JSON-подобную структуру с полями «категория», «срочность», «резюме», «нужен человек: да/нет». Такое описание уже легче проверять, чем длинный абзац. В пилоте на 200 исторических обращениях команда может сравнить метки модели с ручной разметкой и посчитать долю совпадений. Если совпадений меньше 80%, чаще виноваты расплывчатые категории, а не сама идея сортировки.

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

Где черновики ответов экономят время

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

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

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

В продажах черновики особенно полезны для повторяемых диалогов. Клиент спрашивает «чем отличается тариф на 5 пользователей от тарифа на 20», менеджеру нужен не красивый абзац, а ответ с уточняющим вопросом и понятным следующим шагом. Модель может подготовить 2 версии: короткую для мессенджера и более подробную для письма. Затем менеджер выбирает тон и добавляет данные из коммерческого предложения.

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

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

Качество держится на 3 барьерах: проверяемые источники, запрет на неподтверждённые обещания и выборочная ручная ревизия. Если контролировать хотя бы 50–100 ответов в неделю, быстро видно, где модель ошибается системно.

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

Второй барьер, тональность. В поддержке я часто прошу готовить ответ на уровне 7 из 10 по теплоте: без чрезмерных извинений, без сухого «ваше обращение принято». Для жалобы нужен другой тон, чем для вопроса «где чек». Это можно задать правилами: 2 предложения сочувствия максимум, 1 конкретное действие, 1 срок или честное отсутствие срока.

Третий барьер, разбор ошибок. Возьмите 100 обращений за прошлую неделю и разметьте 4 поля: правильная категория, правильный приоритет, пригодность черновика, фактологическая ошибка. Через 2–3 итерации обычно становится понятно, что надо менять: список категорий, промпт, базу знаний или правила эскалации. Образовательный принцип тот же, что в персональном обучении: модель полезнее, когда есть обратная связь, об этом я писал в материале про нейросети для саморазвития и обучения.

Что можно делать в SoftChat, а что не надо приписывать продукту

В SoftChat можно работать с текстовыми запросами в веб-чате, переключать модели в диалоге, хранить историю по организации и использовать системные промпты или ассистентов под разговор. Для пилота по поддержке этого хватает, чтобы за 1–2 дня проверить категории, шаблоны и черновики на исторических обращениях.

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

Практический пилот можно провести без сложной инфраструктуры. Возьмите 50–200 обезличенных обращений, удалите телефоны, почту, номера договоров и имена. Затем проверьте 2–3 варианта промпта: классификация, черновик ответа, резюме для менеджера. В SoftChat расширенные настройки чата помогают управлять креативностью, длиной ответа и разнообразием слов, если выбранная модель поддерживает такие параметры. Это удобно для сравнения: один и тот же запрос можно прогнать в более кратком и более развёрнутом стиле.

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

Какие метрики показывают реальную пользу

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

Время первой реакции измеряется просто: сколько минут проходит от обращения до первого осмысленного ответа. В некоторых командах целевой SLA равен 15 минутам для чата и 4–24 часам для почты, но реальные нормы зависят от отрасли. Время обработки показывает, сколько оператор тратит на один диалог от чтения до закрытия. Если черновик сокращает подготовку ответа с 4 минут до 2, это уже заметно при 100 обращениях в день.

Точность классификации лучше считать на старых данных. Команда вручную размечает 100–300 обращений, затем сравнивает результат модели. Для стабильного пилота я бы ждал 85% совпадений на простых категориях и отдельно отслеживал опасные ошибки: жалобу нельзя отправлять в низкий приоритет, а запрос на покупку нельзя терять в общей очереди.

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

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

С чего я бы начал на месте команды

Я бы начал с пилота на 2 неделях и 1 очереди, а не с полной перестройки поддержки. Такой масштаб даёт достаточно данных, обычно 100–500 обращений, и не ломает текущую работу.

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

Дальше подготовьте простой промпт: «определи категорию из списка, поставь срочность 1–3, сделай резюме в 1 предложение, предложи черновик ответа до 700 знаков, не выдумывай факты». Прогоните 50 обращений, поправьте категории, затем прогоните ещё 50. После 2 итераций обычно появляются первые правила: какие темы доверять модели, какие отправлять на ручную проверку, какие черновики запрещать без старшего специалиста.

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