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

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

Если у поддержки 30–100 обращений в день, даже 20 одинаковых вопросов быстро съедают рабочее время. Ответ на типовой запрос занимает 2–4 минуты: прочитать сообщение, уточнить контекст, вставить шаблон, поправить тон. Это 40–80 минут в день на одну категорию вопросов. При пяти таких категориях набегает половина смены. ИИ здесь полезен не как «замена отдела», а как фильтр и редактор, который ускоряет безопасные операции.

Что изменилось в обновлённой версии

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

Обновлённая схема строится вокруг трёх уровней:

  1. ИИ готовит черновик ответа, менеджер отправляет после проверки.
  2. ИИ отвечает сам только по утверждённым формулировкам и простым условиям.
  3. ИИ передаёт человеку всё, где есть деньги, конфликт, персональные данные, юридический риск или нестандартная просьба.

Для старта я обычно беру не весь поток, а выборку из 100–300 последних обращений. Этого хватает, чтобы увидеть повторяемость. Если в выборке 100 сообщений, а 35 из них про доставку, оплату и возврат, автоматизация уже имеет смысл. Если повторов меньше 10–15%, выгоднее сначала навести порядок в базе знаний и шаблонах.

Какие вопросы можно безопасно делегировать ИИ

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

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

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

Тип обращения Можно ли отдавать ИИ Какой режим безопаснее Пример
Частый вопрос по инструкции Да Автоответ или черновик «Как изменить пароль?»
Вопрос по статусу процесса Частично Черновик с проверкой «Когда будет готов документ?»
Возврат, компенсация, скидка Осторожно Только черновик «Верните оплату за прошлый месяц»
Жалоба и конфликт Нет Передача человеку «Я недоволен обслуживанием»
Персональные данные Нет Человек и регламент «Пришлите данные другого пользователя»
Техническая диагностика Частично Уточняющие вопросы «Не открывается файл»

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

Как собрать базу ответов без лишней бюрократии

База ответов не обязана быть большой. На первом этапе достаточно 20–50 карточек. Каждая карточка должна отвечать на один вопрос, а не на раздел целиком. «Возврат» как одна большая статья неудобен. Лучше разбить: «срок возврата», «какие товары нельзя вернуть», «как заполнить заявление», «когда поступят деньги», «что делать без чека».

Я использую такой формат карточки:

  • вопрос клиента простыми словами;
  • утверждённый короткий ответ на 3–6 предложений;
  • условия, при которых ответ нельзя отправлять автоматически;
  • ссылки на внутренние правила или публичную страницу;
  • дата последней проверки;
  • владелец карточки, например поддержка, бухгалтерия или продукт.

Дата проверки нужна не для красоты. Условия доставки, тарифы, лимиты, документы и сроки меняются. Если в базе 40 карточек, их реально пересмотреть за 1–2 часа раз в месяц. Если карточек 400 и за них никто не отвечает, нейросеть начнёт уверенно пересказывать устаревшие правила.

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

Где в этой схеме помогает SoftChat

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

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

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

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

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

Как измерять качество, а не верить ощущениям

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

Оценка может быть трёхуровневой:

  • 2 балла, ответ можно отправить без правок;
  • 1 балл, смысл верный, нужна редактура;
  • 0 баллов, ответ нельзя отправлять.

На выборке из 100 ответов уже видно, где проблема. Если 70 ответов получили 2 балла, 20 получили 1 балл и 10 получили 0 баллов, автоматизация в режиме черновиков выглядит рабочей. Если нулевых оценок 25–30, значит база знаний дырявая, промпт слишком широкий или тема не подходит для делегирования.

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

Модельный кейс: компания из сферы онлайн-образования, ~25 сотрудников, размечает 200 обращений за 2 недели и видит, что 48 вопросов касаются доступа к урокам. Команда делает 12 карточек ответов, запускает ИИ в режиме черновиков и через следующий контрольный период сравнивает не выручку, а долю правок: сколько ответов ушло без изменений, сколько пришлось переписать и где возникли ошибки.

Границы автоматизации: где человек всё ещё нужен

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

Я бы не отдавал ИИ финальное решение в таких ситуациях:

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

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

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

Пошаговый план внедрения на 14 дней

День 1–2. Выгрузите или вручную соберите 100–300 обращений. Уберите персональные данные. Разметьте темы: доставка, оплата, документы, доступ, возврат, техническая ошибка, жалоба.

День 3–4. Выберите 3 темы с максимальным числом повторов и низким риском. Не берите конфликты и деньги в первый спринт. Лучше начать скучно: инструкции, статусы, документы.

День 5–7. Напишите 20–30 карточек ответов. Каждую карточку проверьте у владельца правила. Если владелец не найден, карточку нельзя считать источником правды.

День 8–10. Запустите ИИ в режиме черновиков. Менеджеры не отправляют ответы вслепую. Они ставят оценку 0, 1 или 2 и фиксируют причину правки.

День 11–12. Разберите ошибки. Обычно находятся 3 причины: не хватает условий в базе, промпт разрешает домысливать, тема шире, чем казалась.

День 13–14. Оставьте рабочие темы, уберите рискованные, обновите карточки. Если по теме больше 80% черновиков получают оценку 1 или 2, её можно развивать. Если ниже, сначала чините базу.

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

Итог обновления

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

Начните с 100–300 обращений, выберите 3 безопасные темы, подготовьте 20–50 карточек и две недели меряйте качество по простой шкале. Если нейросеть стабильно готовит пригодные черновики, расширяйте сценарий. Если ошибается, не спорьте с моделью. Исправляйте источник правды, промпт и границы делегирования.