ИИ для аналитики чатов группирует обращения по темам и показывает, почему клиент пишет снова. Такой анализ полезен, когда диалоги обезличены, метки проверены аналитиком, а команда готова исправлять причины повторов.
Единица анализа
Единица анализа здесь — цепочка обращений одного вопроса, а результат — список повторяющихся причин и очередь исправлений.
Начните с выгрузки чатов поддержки и продаж: время, канал, тема, статус, факт повторного обращения и текст сообщений. Один длинный чат может содержать несколько разных просьб; несколько чатов могут относиться к одной нерешённой задаче. Поэтому группировка только по числу диалогов завышает объём проблем. Аналитик задаёт правило связывания повторов по разрешённому идентификатору и проверяет его на выборке.
Перед передачей текста модели удалите прямые идентификаторы и проверьте свободные сообщения на косвенные признаки личности. Ключ связи с исходным диалогом храните отдельно в системе поддержки, с доступом только уполномоченным сотрудникам; модели передавайте случайный идентификатор цепочки. В управленческом отчёте показывайте агрегированные результаты.
- Обращение: какое действие клиент просил выполнить.
- Повтор: тот же вопрос вернулся после ответа или закрытия чата.
- Причина: пробел в базе знаний, задержка процесса, ошибка интерфейса либо сложная ситуация.
Оценка одного разговора отвечает на другой вопрос: насколько корректно сотрудник вёл диалог. Это подробно разобрано в материале о контроле звонков. Здесь итогом служит карта тем по массиву чатов и очередь изменений процесса.
Словарь тем
Составьте небольшой словарь тем из реальных формулировок клиентов. Названия должны описывать действие: «уточнить срок доставки», «вернуть товар», «изменить адрес». Общие ярлыки вроде «прочее» и «проблема» скрывают решение. Аналитик вручную размечает образцы, затем GigaChat или YandexGPT предлагает метки для следующих диалогов. Промпт требует указывать фразу, на которой основана метка, и оставлять спорные случаи для человека.
| Сигнал | Что ищет модель | Что проверяет аналитик |
|---|---|---|
| Тема | Запрос клиента в сообщениях | Корректность словаря |
| Повтор | Возврат к той же просьбе | Связь разных чатов |
| Причина | Упоминание задержки или пробела | Подтверждение в системе |
Фраза клиента «уже писал вчера» сама по себе слабо подтверждает повтор той же проблемы. Сверьте дату, предмет обращения и статус предыдущей заявки. Продажа тоже может выглядеть как повтор: покупатель уточнил размер, затем спросил про оплату. Такие разговоры лучше размечать отдельными темами и стадиями, иначе отчёт ошибочно запишет нормальный путь клиента в список сбоев.
На контрольной выборке сравните метки модели с решениями двух сотрудников. Разногласия помогают уточнить словарь: иногда причина повтора скрывается в сбое склада, который из текста чата виден косвенно. В отчёте разделяйте «модель предполагает» и «подтверждено в системе». Это сохраняет честную границу между текстовым анализом и проверкой фактов.
Причины возвращения
Постройте цепочки по одной задаче клиента: первое сообщение, ответ команды, следующее сообщение и итог. Отдельно считайте повтор после формального закрытия, поскольку такая метрика обнаруживает преждевременное завершение разговора. Затем проверьте, какие темы часто возвращаются после одинакового шаблона ответа. Там обычно полезнее изменить инструкцию или процесс, чем добавлять ещё один вариант вежливой фразы.
- Свяжите обезличенные диалоги по разрешённому ключу и периоду наблюдения.
- Попросите модель назвать тему, признак повтора и подтверждающую цитату.
- Сверьте несколько цепочек каждой крупной темы с исходными статусами.
- Запишите проверенную причину и владельца исправления.
- После изменения процесса сравните долю повторов по той же теме.
Условный пример: клиент спрашивает о сроке отгрузки, получает общий ответ и возвращается после обещанной даты. Классификатор видит повтор, но причину уточняет человек по данным логистики. Если склад задержал сборку, обновите способ сообщения статуса; если сотрудник выбрал неверный шаблон, правьте базу ответов. В обоих случаях метка «плохой чат» слишком груба для действия.
Сравнение с общей аналитикой компании помогает выбрать, где нужен текст, а где хватит обычных метрик CRM. У чатов есть уникальное преимущество: формулировка клиента показывает конкретный пробел в объяснении. Этим сигналом пользуйтесь после проверки фактической причины.
Если важна автоматическая разметка входящих обращений, автоматизация рабочих процессов связывает метки с задачами команды. Для отчёта достаточно выгрузки; для исправления нужен ответственный, срок и измеримый результат.
Очередь исправлений
Отчёт полезен, когда каждый крупный повтор превращается в задачу. Для темы зафиксируйте объём обращений, время ручной обработки в минутах, возможную причину и владельца изменения. Сначала берите случаи с высокой частотой и понятным действием: исправить карточку товара, добавить статус доставки, переписать инструкцию оператору. Редкие конфликтные ситуации оставляйте для персонального разбора.
- Пробел в ответе: дополните базу знаний подтверждённым правилом.
- Задержка операции: передайте задачу владельцу процесса и измените уведомление.
- Сложная претензия: сохраните передачу человеку и отметку об исходе.
- Ошибка классификации: обновите словарь и контрольную выборку.
Метрика после правки должна совпадать с причиной. Если обновили страницу возврата, отслеживайте повторные вопросы про возврат, отдельно от общего объёма чатов. При росте заказов абсолютное число обращений может вырасти даже при улучшении текста. Доля повторов по теме на сопоставимых потоках даёт более честную картину. Проверяйте также случаи, где клиент ушёл из чата без решения.
Руководителю нужна короткая очередь с причиной и статусом, а аналитику — возможность открыть цепочку и проверить метку. Уберите из управленческого отчёта цитаты, по которым можно узнать клиента. Такая схема сохраняет связь с фактом и ограничивает доступ к личным сведениям.
Для каждой задачи укажите дату правки и сотрудника, который проверит эффект на следующей выгрузке. Иначе очередь быстро устареет.
Если клиенты снова спрашивают о возврате после ответа бота, поручите владельцу страницы проверить правило и отметить исправление до следующей выгрузки.
Какие повторные вопросы ваши чаты скрывают сегодня?
Выборочный контроль
Соберите обезличенную выгрузку за один рабочий цикл и вручную проверьте цепочки по самым частым темам. Первую очередь составьте из исправлений, у которых есть владелец и измеримая доля повторов.
Пилот начинайте с одного канала, где диалоги доступны в едином формате. Опишите правила удаления личных сведений и период связывания обращений. Затем подготовьте эталонный набор: аналитик отмечает тему, наличие повтора и подтверждённую причину. Точность модели оценивайте по каждой метке отдельно. Иначе хорошие результаты на частой теме замаскируют ошибки на редких, но важных обращениях.
После запуска выбирайте для ручной проверки случайные диалоги и отдельную группу спорных классификаций. Аналитик правит словарь, а ответственный за поддержку меняет процесс. Записывайте версию словаря и дату отчёта: без этого сравнение двух периодов показывает сдвиг разметки, при отсутствии связи с эффектом исправления. При смене шаблонов ответов заново проверьте образцы чатов.
Стоимость такого контура зависит от объёма истории, качества выгрузки, правил обезличивания и числа систем, где заводятся задачи. В смете уточняйте, кто поддерживает словарь и проверяет спорные цепочки. Автоматизация отчёта без этого владельца быстро превращается в красивую диаграмму, без реальных изменений.
Разбор ошибок классификации удобно проводить вместе с теми сотрудниками, которые ежедневно отвечают клиентам: они быстрее замечают двусмысленные формулировки.