Обновлено: июнь 2026. Я переписал статью под текущую практику анализа обратной связи: меньше общих промптов, больше схемы работы с массивом из 100–300 обращений, проверкой выводов и быстрыми улучшениями.

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

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

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

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

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

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

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

Подготовьте данные: 30 минут, которые экономят часы

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

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

Условный пример: из 200 обращений получилось 247 отдельных фрагментов, потому что 38 писем содержали по две или три проблемы. Это нормально. Считать лучше не письма, а смысловые жалобы. Тогда частотность становится честнее: проблема с оплатой не исчезает внутри длинного письма про доставку.

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

Промпт для первого прохода: темы, частота, цитаты

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

Рабочая формулировка выглядит так:

«Проанализируй массив клиентских обращений. Раздели сообщения на темы недовольства. Не объединяй разные причины в одну общую категорию. Для каждой темы укажи количество фрагментов, примерную долю, 2–3 короткие цитаты без персональных данных, предполагаемый этап пути клиента и команду, которая может повлиять на проблему. Если данных мало, пометь вывод как гипотезу».

Я не прошу модель сразу «сделать красиво». Сначала нужна грубая карта. На этом этапе допустимы 8–15 тем. Если их 30, классификация слишком мелкая. Если их 3, она слишком грубая. Хороший результат даёт картину вроде: «задержка ответа в поддержке», «непонятные условия возврата», «ошибка оплаты», «неясный статус доставки», «сложная навигация после регистрации».

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

Второй проход: найдите 5 главных причин, а не 15 тем

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

Для второго прохода я беру таблицу тем и прошу модель выделить 5 причин с максимальным сочетанием частоты и влияния. Здесь нужна не чистая математика. Жалоба, которая встречается 40 раз и раздражает клиента на этапе выбора, может быть менее дорогой, чем 12 жалоб после оплаты, если они приводят к возвратам и нагрузке на поддержку.

Условный пример: в массиве из 220 фрагментов тема «поддержка отвечает долго» встречается 31 раз, а «ошибка в сумме при оплате» встречается 9 раз. Приоритет может оказаться выше у оплаты, потому что проблема возникает ближе к деньгам и блокирует заказ. Частота важна, но место в клиентском пути меняет вес.

Я использую шкалу из трёх оценок: частота от 1 до 5, влияние на клиента от 1 до 5, простота исправления от 1 до 5. Быстрые улучшения ищу там, где влияние высокое, а исправление не требует квартального проекта. Например, переписать письмо о возврате, добавить подсказку рядом с полем оплаты, изменить текст статуса заказа, обновить шаблон ответа поддержки.

Как работать в SoftChat и не смешивать всё в один диалог

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

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

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

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

Таблица приоритизации: что чинить первым

После двух проходов нужна короткая таблица для решения. Не отчёт на 20 страниц, а список из 5–7 строк, который поймёт руководитель поддержки, продуктовый менеджер и маркетолог. Я обычно использую такой формат:

Причина недовольства Доля фрагментов Этап клиента Влияние Быстрое улучшение Владелец
Непонятные условия возврата 14% После покупки Высокое Переписать письмо и страницу возврата Поддержка, контент
Нет статуса доставки 11% Ожидание заказа Среднее Добавить понятный текст статуса Логистика, продукт
Ошибка оплаты не объяснена 4% Оплата Высокое Показать причину отказа и следующий шаг Продукт
Шаблонные ответы операторов 9% Обращение в поддержку Среднее Обновить макросы ответов Поддержка

Это не финальная истина. Это рабочая карта. По каждой строке нужно открыть 5–10 исходных фрагментов и проверить, не перепутана ли причина. Если модель пишет «клиенты недовольны ценой», а цитаты говорят «непонятно, что входит в тариф», проблема не в цене. Проблема в объяснении ценности и состава предложения.

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

Как проверить выводы модели

Проверка занимает 20–30 минут, но без неё анализ опасен. Я беру каждую из пяти главных причин и смотрю исходные фрагменты. Минимум: 5 цитат на причину. Если цитаты однотипные, вывод устойчивее. Если цитаты разъезжаются, тему надо разделить.

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

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

Что делать после анализа

Хороший финал анализа, это список быстрых изменений на 1–2 недели и список более крупных гипотез. Быстрые изменения: поправить текст письма, добавить подсказку, переписать макрос ответа, изменить название кнопки, обновить страницу с условиями. Крупные гипотезы: перестроить процесс возврата, изменить логику статусов, доработать оплату, пересобрать онбординг.

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

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

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

Обновлённый подход сводится к простой дисциплине: не просить нейросеть «найти инсайты», а дать ей чистый массив, формат таблицы, правила группировки и требование подтверждать выводы цитатами. За 1–2 часа можно получить карту тем, 5 главных причин недовольства и список улучшений, которые команда способна обсудить уже на ближайшем планировании.

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