Нейросеть в поддержке и продажах: обращения в 2026
Нейросеть помогает разложить входящие письма, чаты и заявки по смыслу, срочности и следующему действию, чтобы оператор не начинал каждый раз с пустого экрана.
В поддержке и продажах первая реакция часто дороже самого ответа. Если клиент ждёт 2 часа вместо 10 минут, он успевает написать повторно, уйти к конкуренту или нагрузить второй канал связи. В B2B-продажах похожая картина: заявка с формулировкой «хочу счёт сегодня» и вопрос «какие у вас условия» требуют разного темпа, хотя обе выглядят как обычные входящие.
Я разбираю эту задачу не как магию автоматизации, а как редакторскую и операционную систему. Нейросеть читает обращение, выделяет признаки, предлагает класс, ставит приоритет и собирает черновик ответа. Человек остаётся в контуре: проверяет тон, факты, обещания и спорные случаи. Такой подход хорошо сочетается с тем, что уже описано в статье про внедрение нейросетей в рабочие процессы: начинать надо с узкого сценария, а не с лозунга «автоматизируем всё».
Что именно классифицирует нейросеть в обращениях
Нейросеть раскладывает входящий поток минимум на 4 слоя: тема, намерение, срочность и следующий шаг. Для очереди из 100 обращений это даёт не 100 отдельных решений, а 10–20 повторяемых маршрутов.
Первый слой, тема. Клиент пишет про оплату, доставку, доступ, ошибку, подбор тарифа, возврат, договор или счёт. Вручную оператор тратит 20–40 секунд только на чтение короткого письма, а длинная переписка на 8–12 сообщений легко забирает 3–5 минут до первого действия.
Второй слой, намерение. Фраза «не могу войти» может означать восстановление доступа, ошибку авторизации, блокировку аккаунта или проблему с браузером. Нейросеть полезна тем, что вытаскивает глагол действия: «восстановить», «проверить», «передать инженеру», «уточнить данные». Если команда только знакомится с такими сценариями, полезно сначала пройти базовые принципы из материала про нейросети и чат-боты в повседневных задачах, а затем переносить их в очередь поддержки.
Третий слой, срочность. Здесь нейросеть ищет слова и факты: «не работает оплата», «клиент ждёт счёт», «дедлайн сегодня», «ошибка у 50 пользователей», «не проходит заказ». Срочность нельзя определять только по эмоциям. Сообщение с капслоком не всегда критично, а спокойная фраза «касса не пробивает чеки с 9:20» может быть инцидентом продаж на весь магазин.
Четвёртый слой, следующий шаг. Хорошая классификация заканчивается действием: ответить шаблоном, задать 1 уточняющий вопрос, передать специалисту, открыть инцидент, поставить задачу менеджеру. Без этого тег «срочно» превращается в цветную наклейку, а не в управление очередью.
Как нейросеть выделяет срочные случаи
Рабочая схема держится на 5 сигналах: деньги, доступ, массовость, срок и риск потери клиента. Если в обращении есть хотя бы 2 сигнала, заявка должна всплыть выше обычных вопросов в пределах 1–3 минут после поступления.
Деньги: не проходит оплата, нужен счёт, завис возврат, не сходится сумма в закрывающих документах. Доступ: пользователь не может войти, не видит оплаченный сервис, потерял права администратора. Массовость: проблема затронула 10, 50 или 500 пользователей, либо клиент прямо пишет «у всей смены». Срок: «до 15:00», «сегодня отгрузка», «через час встреча». Риск: «если не решим, отменяем заказ», «переносим закупку», «пишу второй раз».
Модельный кейс: компания из сферы логистики, ~200 сотрудников, получает 600 обращений в неделю, из них 12–18% связаны с задержками документов и оплатой. Если нейросеть заранее помечает такие письма как «деньги» и «срок», старший оператор видит 70–110 потенциально дорогих заявок отдельно от вопросов вроде «где скачать акт за прошлый месяц».
Ошибки в приоритизации неизбежны. Поэтому я не советую сразу отдавать нейросети право закрывать обращения без проверки. Начните с режима подсказки: модель предлагает приоритет, оператор подтверждает или меняет его. Через 2 недели можно посчитать расхождения: например, сколько заявок с пометкой «обычная» человек поднял до «срочной» и сколько «срочных» оказались шумом.
| Этап обработки | Вручную | С нейросетевой подсказкой | Метрика контроля |
|---|---|---|---|
| Первичное чтение письма | 30–180 секунд | 5–20 секунд на проверку класса | Время до первого действия |
| Разметка темы | Зависит от опыта оператора | Единый набор из 10–20 категорий | Доля исправленных тегов |
| Выделение срочности | Часто по эмоциям текста | По 5 сигналам риска | Ошибки приоритета за неделю |
| Черновик ответа | С чистого листа или шаблона | 1 черновик с нужным тоном | Доля ответов без правки фактов |
| Передача дальше | После ручного разбора | После извлечения темы и намерения | Время до назначения владельца |
Как появляются черновики ответов
Черновик должен состоять из 6 блоков: приветствие, признание проблемы, краткая суть, действие, срок, следующий контакт. Если хотя бы 1 блок отсутствует, клиент чаще задаёт повторный вопрос.
Нейросеть не должна сочинять то, чего нет в данных. Её задача, собрать аккуратный первый вариант: «вижу, что оплата прошла, но доступ не открылся», «нужно уточнить номер заказа», «передаю запрос специалисту по документам». Для текстовых черновиков пригодится тот же принцип, который я разбирал в статье про нейросеть для генерации текста и проверку результата: сначала структура, потом факты, затем тон.
Условный пример: входящее сообщение «счёт нужен до 16:00, иначе закупку перенесут на август» можно превратить в черновик из 4 предложений. Первое подтверждает запрос. Второе уточняет недостающие реквизиты, если их нет. Третье называет действие менеджера. Четвёртое фиксирует следующий контакт до конкретного времени. Такой черновик оператор проверяет быстрее, чем пишет заново.
В SoftChat для такой работы можно вести диалог с языковой моделью, переключать модель в текущем чате и настраивать параметры ответа, например «Креативность» и «Длина ответа», если выбранная модель их поддерживает. Для повторяемых задач помогают системные промпты и пользовательские ассистенты на уровне беседы. Я бы не превращал это в замену CRM или службы поддержки, если такая интеграция отдельно не настроена во внешнем контуре. Зато как место для отработки формулировок, правил разметки и проверки черновиков веб-чат подходит естественно.
Качество промпта здесь влияет сильнее, чем название модели. Формулировка «ответь клиенту» слишком широкая. Рабочий запрос задаёт роль, формат, ограничения, тон и запрет на выдумывание фактов. Если команда часто получает расплывчатые ответы, начните с приёмов из разбора правильных запросов для нейросетей.
Где проходит граница между подсказкой и автоматизацией
Я делю внедрение на 3 уровня: подсказка оператору, полуавтоматический маршрут и автоматический ответ для низкого риска. На первом уровне риск минимален, потому что 100% внешних сообщений проверяет человек.
Подсказка оператору подходит для старта. Нейросеть ставит тему, срочность, краткое резюме и предлагает черновик. Человек правит и отправляет. Этот режим полезен уже на 50–100 обращениях в день, потому что даже экономия 40 секунд на одном письме даёт 33–66 минут в сутки.
Полуавтоматический маршрут включают, когда категории стабилизировались. Например, вопросы про документы уходят группе бухгалтерии, проблемы доступа видит технический специалист, новые коммерческие заявки попадают менеджеру. Тут надо измерять не «ощущение скорости», а 6 чисел: время первой реакции, долю просроченных SLA, долю ошибочных маршрутов, повторные обращения, долю правок в черновиках и удовлетворённость после закрытия.
Автоматический ответ разумен только для простых случаев: статус заявки, ссылка на инструкцию, запрос недостающего номера заказа, подтверждение получения. Даже тогда нужны стоп-слова. Если клиент пишет «юрист», «претензия», «расторжение», «не оплатим», «ошибка у всех пользователей», ответ без человека может ухудшить ситуацию.
Что измерять после запуска
Первые 14 дней измеряйте не меньше 6 показателей: медиану первой реакции, 90-й процентиль ожидания, точность категории, точность срочности, долю правок и повторные обращения. Среднее время само по себе обманывает, потому что 5 тяжёлых заявок могут испортить день всей смене.
Я начинаю с простого журнала проверок. Оператор видит предложение нейросети и отмечает одно из 4 состояний: «верно», «ошибка темы», «ошибка срочности», «нельзя отправлять черновик». Через 200–300 размеченных обращений уже видно, какие категории надо разделить, а какие склеить.
Гипотетический пример: интернет-магазин с 80 обращениями в день делит поток на 12 тем и 3 уровня срочности. Через 10 рабочих дней команда получает около 800 проверенных записей. Этого хватает, чтобы заметить, что «возврат» надо разделить на «статус возврата», «спор по сумме» и «юридическая претензия», потому что риск и нужный ответ разные.
Ещё один показатель, доля черновиков без фактической правки. Если оператор меняет только стиль в 60–70% случаев, промпт и контекст работают приемлемо. Если факты приходится исправлять в каждом втором ответе, модель получает мало данных или инструкция разрешает ей додумывать.
Что бы я сделал на вашем месте за 30 дней
Я бы начал с 2 очередей: входящие продажи и поддержка по оплате или доступу. За 30 дней можно пройти путь от ручной разметки до устойчивых правил без риска сломать весь сервис.
В первую неделю соберите 200–300 последних обращений без персональных данных, если это возможно по вашим правилам безопасности. Разметьте темы, намерения и срочность вручную. Не делайте 40 категорий: для старта хватает 10–15, иначе операторы начнут спорить о названиях вместо скорости ответа.
Во вторую неделю напишите промпт для классификации и отдельный промпт для черновика. В каждом задайте формат ответа: тема, приоритет, причина приоритета, недостающие данные, черновик. Проверьте 50–100 обращений и посчитайте ошибки. Не спорьте с каждым промахом модели, ищите повторяющийся тип ошибки.
В третью неделю подключите режим подсказки для части смены. Пусть 2–3 оператора отмечают, где модель помогла, а где мешала. В четвёртую неделю обновите категории, добавьте стоп-слова и решите, какие 2–3 сценария можно ускорять дальше.
Финальное правило простое: нейросеть должна сокращать путь от входящего сообщения до первого осмысленного действия. Если она просто добавляет ещё одно окно и ещё один спор о правильном теге, процесс надо упрощать, а не масштабировать.