ИИ контролирует менеджеров по работе с клиентами

Главное

У компании был SLA: клиент должен получить ответ за 15 минут. Такой норматив есть почти у всех. Вопрос в другом — кто-нибудь проверяет, как он соблюдается?

Проверить его исполнение до нас было нечем. Сто чатов за две недели — это тысячи сообщений, и открывать каждый, чтобы засечь паузы секундомером, не станет никто. Норматив существовал на бумаге, а объективных данных о том, как он соблюдается, в компании не было.

Мы сделали систему, которая читает все чаты сама и раз в неделю присылает отчёт: где качество коммуникации просело и у кого именно.

Первый отчёт показал:

• 27% ответов пришли клиенту позже 15 минут — каждый четвёртый
• самая долгая пауза между вопросом клиента и ответом менеджера — 26 часов
• 18% обращений остались нерешёнными
• есть чаты, где отвечали за 20 секунд, но вопрос клиента всё равно закрыт не был.

Последний пункт — самый важный. Скорость и качество это не одно и то же, и система видит оба.

Внедрение заняло 3 недели. Стоимость проекта — 1 500 000 ₽. Система работает в постоянном режиме.

В чём идея продукта

Мы измеряем качество коммуникации с клиентом. Оно складывается из трёх вещей, и все три система считает отдельно.

Первое — скорость ответа. Самая понятная часть. Есть SLA — 15 минут. Если менеджер систематически отвечает позже, это сигнал: он не справляется. Не «плохой сотрудник», а именно не справляется — перегружен, не хватает прав, не знает ответа, зашивается в пиковые часы. Разбираться надо с причиной, но сначала нужно увидеть факт.

Второе — довели ли вопрос до решения. Быстрый ответ, после которого проблема осталась, — это не хорошая работа. В отчёте есть чат, где среднее время ответа 20 секунд, а вопрос клиента закрыт не был. По одной скорости такой менеджер выглядел бы лучшим в компании.

Третье — не остался ли клиент без ответа вообще. Худший случай: человек написал, и ему не ответили. По скорости это никак не видно, потому что мерить нечего.

Всё это раньше нельзя было посчитать: разговоры живут в переписке обычными словами, а не в полях CRM. Читать переписку и понимать, о чём она и чем закончилась, — как раз работа для ИИ.

Клиент

— сервисная платформа для тех, кто закупает интернет-рекламу.

Простыми словами: есть команды, которые профессионально покупают рекламу и приводят людей рекламодателям. Им нужны рекламные кабинеты, карты для оплаты рекламы, готовые сайты и картинки для объявлений. Компания даёт всё это в одном месте — по их данным, 16 сервисов и больше 52 тысяч выданных рекламных кабинетов с 2019 года.

Из устройства бизнеса растёт и цена вопроса. Клиент компании — не человек, который выбирает товар и может подождать до завтра. Это команда, у которой прямо сейчас крутится реклама и тратятся деньги. Не пополнился баланс, не открылся доступ к кабинету — кампании стоят.

Поэтому 15 минут здесь не вежливость, а рабочая норма. А 26 часов — это сутки, которые клиент просидел без работы.

1. Постановка задачи

Заказчик обратился с задачей контроля качества клиентской коммуникации.

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

Что требовалось получить. Регулярный отчёт, который формируется автоматически и приходит руководителю без запроса. Периодичность — раз в три дня либо раз в неделю. Формат — готовый документ, а не панель, в которую нужно заходить.

Состав отчёта заказчик определил так:

1. Скорость реакции менеджеров — сколько времени проходит между обращением клиента и ответом сотрудника.
2. Задержки — случаи, когда пауза выходит за пределы норматива.
3. Обращения без ответа — запросы, оставшиеся без реакции.
4. Содержание обращений — с какими проблемами приходят клиенты и какие из них повторяются.
5. Результат — была ли проблема решена.
6. Разбивка по клиентам.

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

Постановка сформулирована в терминах результата, а не технологии — это удобная отправная точка. Наша задача на следующем шаге состояла в том, чтобы перевести перечисленные пункты в измеримые величины и зафиксировать их в техническом задании до начала разработки.

2. Что мы зафиксировали в задании

Мы не стали делать «отчёт вообще». Разложили просьбу на конкретные величины и согласовали их с заказчиком до начала работы.

Что система собирает. Все сообщения из доступных чатов за выбранный период — 3 дня или неделя, на выбор.

Что она считает по каждому чату:

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

Что делает ИИ. Читает текст сообщений и понимает: о чём вопрос, в чём суть проблемы, решили её или нет, какие темы повторяются чаще всего. Поиском по словам это не сделать: «не могу зайти», «доступ слетел» и «выкинуло из кабинета» — одна и та же проблема, написанная тремя разными людьми по-разному.

Что приходит на выходе. Готовый документ: общая статистика, разбивка по клиентам, показатели по каждому сотруднику, список проблем со статусом и отдельно — критические случаи. Приходит сам, в заданный канал: Telegram, почта или внутренняя система.

Одна правка в задании, которая оказалась главной

Заказчик просил среднее время ответа. Мы добавили в задание медиану — время ответа у «среднего» обращения, если выстроить все ответы по порядку.

Зачем: среднее легко испортить парой очень долгих случаев. Один ответ через сутки утянет вверх статистику целой недели. И наоборот — сотня быстрых ответов способна спрятать в среднем те самые сутки.

Первый же отчёт это подтвердил. Среднее — 7 минут 18 секунд, медиана — 5 минут. Разница почти в полтора раза.

Для контроля менеджеров это принципиально. По среднему в 7 минут кажется, что SLA в 15 минут соблюдается с запасом и претензий нет. На деле половина клиентов получает ответ за 5 минут, а четверть — позже нормы. Одно среднее число прячет ровно тех людей, ради которых норматив и вводился.

3. Что показал первый отчёт

Систему запустили на пилотной выборке — 100 чатов за две недели, отчёт собран 6 июля 2026 года.

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

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

Главное открытие: проблема не в том, что команда медленная

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

Медиана — 5 минут. Значит, половина клиентов получает ответ вдвое быстрее норматива. Среднее — 7 минут 18 секунд, тоже внутри SLA. По этим двум числам поддержка выглядит здоровой, и придраться не к чему.

А теперь третья: 27% ответов вне норматива, максимальная пауза 26 часов.

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

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

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

Как это читать руководителю

27% нарушений SLA. Каждый четвёртый клиент ждал дольше норматива. Это оценка процесса, а не приговор людям. Дальше отчёт показывает, где именно копится задержка.

26 часов. Сутки простоя у клиента, который платит за скорость. Поддержка работает посменно, включая вечер и ночь, так что длинная пауза почти всегда попадает в чью-то смену — списать её на «было нерабочее время» не получится.

44% критичных при 62% решённых. Вопросы в итоге закрываются, но дорого — через долгие ожидания и повторные напоминания клиента.

20 секунд и нерешённый вопрос. Тот самый чат, где по скорости всё идеально, а результата нет. Ради таких случаев в отчёте и стоит рядом со скоростью статус решения.

Что было дальше

Отчёт не остался бумагой. Руководитель пошёл с ним к менеджерам — не разбираться, а разговаривать: где тяжело, что мешает отвечать вовремя, что можно поменять.

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

Что мы нашли в собственной системе — и чиним

Первый прогон — пилот, а не финал. Мы прочитали отчёт так же въедливо, как читали бы чужой, и записали, что в нём не так. Список отдан в работу вторым этапом:

1. Самый тяжёлый случай периода не попал в список критических. В общей статистике максимальная пауза 26 часов, а в списке критических случаев максимум — 17 часов. Список собирается не по той же выборке.
2. Список критических случаев не отсортирован — тяжёлое вперемешку с мелким.
3. Порог «критично» не совпадает с SLA. Норма — 15 минут, а в критические попали паузы в полторы и четыре минуты.
4. В разделе «нерешённые проблемы» лежат решённые. Название раздела не совпадает с содержимым.
5. Темы считаются дважды. «Пополнение» и «balance top-up» — одна тема на двух языках, в отчёте идут разными строками. Значит, реальные цифры по темам выше.
6. Ноль в графе «среднее время ответа» у чата, где менеджер не отвечал вообще. Ноль читается как «отвечаем мгновенно», а означает обратное.
7. Дата проблемы не извлеклась у половины критических случаев.
8. В список сотрудников попал служебный бот. Его надо считать отдельно от людей.
9. Проценты по отдельным сотрудникам пока считать рано. На пилотной выборке приходится меньше четырёх чатов на человека — на таких числах доля решённых скачет и ничего не значит. Общие выводы по команде она выдерживает, персональные — нет. Нужен накопленный объём.
10. Учёт сменного графика. Сейчас паузы считаются подряд, без привязки к тому, чья была смена. Для персонального разбора это нужно.

Мы показываем этот список специально. Отчёт, который никто не перепроверял, опаснее отсутствия отчёта — особенно когда по нему собираются говорить с людьми.

Что это даёт бизнесу

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

Что появляется после запуска:

• SLA начинает работать. Записанная норма превращается в цифру, которую видно каждую неделю
• видно, где именно проседает качество — у кого, в какие часы, на каких типах вопросов
• видно быстрых, но безрезультатных. Менеджер, который отвечает за 20 секунд и не решает вопрос, по обычным отчётам выглядит отличником
• видно потерянных клиентов — тех, кому не ответили вообще
• видно, о чём спрашивают чаще всего. Это готовый список того, что надо починить в продукте или вынести в инструкцию, чтобы вопросов стало меньше
• появляется общий язык с командой. Разговор о качестве идёт по одному документу, а не по ощущениям
• всё это приходит само, раз в неделю, без участия человека.

Сроки и цена

Для технических специалистов

Сообщения выгружаются из чатов, где уже присутствует бот, пачкой за период. Разбор текста — языковая модель в облаке: классификация типа обращения, выделение сути проблемы, оценка статуса решения, сведение похожих формулировок в одну тему. Метрики времени считаются детерминированно, по парам «сообщение клиента → первое сообщение сотрудника»; модель к расчёту времени не подпускается. Отчёт собирается в документ и уходит в заданный канал по расписанию. Период отчётности, состав метрик и порог нарушения SLA вынесены в настройки — так и было заложено в задании.

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

Частые вопросы

Нужно ли что-то ставить в чаты? Если бот в чатах уже есть — нет. Мы работаем с той перепиской, которая уже собирается.

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

Можно ли по отчёту наказывать сотрудников? Можно, но мы советуем иначе. У отчёт стал поводом для разговора, а не для санкций, и это оказалось полезнее: причины задержек нашлись там, где их не искали. Цифра показывает, где смотреть, а разбираться всё равно человеку с человеком.

Переписку кто-то читает глазами? Систему настраивает человек, но еженедельный разбор идёт без участия людей. Читать сто чатов руками каждую неделю никто не будет — в этом и была задача.

За какой период считать? Раз в 3 дня или раз в неделю. Настраивается.

Куда приходит отчёт? В Telegram, на почту или во внутреннюю систему — куда удобнее.