Оценку звонков нейросетью легко описать одной фразой: каждый звонок под контролем. Сервис забирает запись, расшифровывает разговор, проверяет его по чек-листу и кладёт в CRM карточку с оценкой. Мы разобрали 2 567 таких карточек из колл-центра сети медицинских центров и сверили их с тем, как устроена проверка. Нашли семь мест, где оценка расходится с разговором. Почти ни одно из них не видно в первые недели: оценки приходят, и система выглядит исправной.
Как устроена проверка
Как систему внедряли, мы рассказывали в кейсе. Коротко: у каждого типа звонка свой чек-лист. Модель сначала выбирает тип разговора по описанию, затем проверяет каждый пункт чек-листа этого типа и пишет ответ "ДА" или "НЕТ" с причиной. Оценку модель не ставит: её считает формула.
Слабые места нашлись на каждом шаге этой цепочки. Ни одно из них не связано с тем, насколько умна модель: все семь - в настройке и обвязке вокруг неё.
1. Запасная категория забирает почти все звонки
Чек-листы пишут под типы звонков: запись на приём проверяют по одним пунктам, вопрос о цене - по другим. Тип модель выбирает по короткому описанию, какие звонки к нему относятся. Чтобы звонок не остался без оценки, заводят запасную категорию с общим чек-листом. В разобранном проекте она называется "Иные звонки".
| Категория | Звонков | Средняя оценка |
|---|---|---|
| Иные звонки | 2 319 | 6,9 |
| Неудачные звонки | 238 | 9,8 |
| Запись на лазерную коррекцию | 5 | 10 |
Запасная категория забрала 90% звонков, прицельный чек-лист записи на лазерную коррекцию сработал пять раз. Причин может быть две: описания прицельных категорий не узнают настоящие звонки или таких категорий почти не осталось. В обоих случаях почти весь поток проверен по общим пунктам вроде приветствия и прощания.
Что делать. Проверять описания категорий на настоящих записях до запуска: взять звонки, тип которых известен заранее, и посмотреть, куда их отнесла модель. После запуска держать долю запасной категории на виду. Растёт - описания пора переписывать.
2. Пункт засчитывается, если ситуации не было
В общем чек-листе есть пункт "Проработка возражений". Его критерий заканчивается фразой: пункт считается выполненным, если таких ситуаций не было.
Модель делает ровно то, что написано. В разборе звонка это выглядит так:
Оператор ничего не сделал, а пункт ушёл в зачёт и поднял оценку. Хуже другое: по этому пункту нельзя посчитать, как часто операторы работают с возражениями. Ответ "ДА" смешивает два случая: возражение отработано и возражения не было.
У категории "Неудачные звонки" средняя оценка 9,8 из 10. Похоже на ту же причину, но текста этого чек-листа мы не видели и утверждать не будем.
Что делать. Дать пункту третий ответ: "не применимо". Такой пункт не идёт ни в числитель, ни в знаменатель. Звонок без возражений оценивается по остальным пунктам, а доля "ДА" по возражениям считается только по звонкам, где они были.
3. Модель читает только начало разговора
Модели отдают первые 5 000 знаков расшифровки: так дешевле и быстрее. По нашей прикидке это около пяти минут разговора.
Звонок в клинику обычно заканчивается главным: оператор называет дату и время приёма, повторяет договорённость, прощается. В длинном разговоре эта часть в проверку не попадает. Модель не видит итога и ставит пункту "НЕТ" или пропускает его, а пропущенный пункт формула тоже считает невыполненным. Под удар попадают как раз длинные разговоры.
Что делать. Отдавать модели весь текст разговора. Если длину приходится ограничивать ради цены, ограничение ставить так, чтобы конец звонка в проверку попадал всегда.
4. Разборов тысячи, а посчитать по ним нечего
Разбор по пунктам лежит в карточке текстом комментария. Одну карточку читать удобно. А вопрос руководителя "как часто операторы не называют цену" по 2 500 разборам не решается: в CRM нет полей под пункты, есть только текст.
Конструктор чек-листа поля под ответы предусматривает: у каждого пункта можно выбрать поле для "ДА/НЕТ" и поле для причины (на скриншоте выше это "Флаг" и "Комментарий"). Но поля необязательные, и без них система работает. Поэтому их легко пропустить при запуске и спохватиться, когда разборов накопились тысячи.
Что делать. Заводить поле под каждый пункт чек-листа с первого дня. Тогда долю "НЕТ" по пункту, оператору и месяцу считает отчёт в Битрикс24 или обычная выгрузка в таблицу.
5. Руководителю нужна сводка по колл-центру
Карточка отвечает на вопрос "как прошёл этот звонок". У руководителя колл-центра вопросы другие: какой пункт операторы пропускают чаще всего, кто просел за месяц, что изменилось после обучения. На них отвечает только сводка по всем звонкам за период.
Сводку легко отложить на второй этап: карточки идут, система выглядит работающей. Но собрать сводку потом можно, только если под пункты есть поля, - это предыдущий раздел. Поэтому отчёт и поля проектируем вместе, до запуска.
6. Сменили расшифровку - оценка тихо встала
Расшифровку перевели с отдельного сервиса на встроенный ИИ Битрикс24. На этом портале он после десятка звонков упирался в лимит, и новые карточки перестали появляться.
Ошибки такая остановка не даёт. Сервис проверки работает, просто расшифровка не приходит, и карточек не становится больше. Пустой список не похож на аварию, поэтому остановку замечает только тот, кто специально проверяет. Разбор нашёл паузу в полтора месяца.
Что делать. Поставить сторож на число оценок: звонки за день были, а новых карточек нет - сообщение ответственному. В цепочке из записи, расшифровки и модели остановиться может любое звено, а сторож один на всех.
7. Оценки разных периодов нельзя сравнивать напрямую
| Период | Средняя оценка | Чем расшифровывали |
|---|---|---|
| Апрель 2025 | 8,4 | отдельный сервис |
| Октябрь 2025 | 7,0 | отдельный сервис |
| Два прогона 2026 года | 5,4 и 6,8 | встроенный ИИ Битрикс24 |
Хочется прочитать это как "операторы стали работать хуже". Но между периодами менялась расшифровка, а возможно, и чек-листы. Другая расшифровка даёт другой текст на входе: другие ошибки распознавания, другую разбивку по спикерам. Модель оценивает текст, поэтому тот же разговор после смены расшифровки может получить другую оценку.
Что делать. Хранить рядом с каждой оценкой версию чек-листа и способ расшифровки. При любой смене прогонять один и тот же набор звонков по старой и новой схеме и сравнивать оценки. Только после этого разница в средней говорит про операторов.
Что закладываем в новые проекты
Ни один из семи пунктов не требует модели умнее. Требуется обвязка, которую легко отложить, пока оценки приходят. В новых проектах оценки звонков закладываем её с первого дня:
- →в проверку идёт весь текст разговора, конец звонка не обрезается;
- →у пункта три ответа: да, нет, не применимо;
- →под каждый пункт чек-листа - поле в CRM;
- →сводный отчёт по колл-центру входит в первый этап вместе с карточками;
- →доля запасной категории видна с первой недели;
- →сторож пишет ответственному, если звонки идут, а новых оценок нет;
- →рядом с оценкой хранится версия чек-листа и способ расшифровки;
- →первые 150-200 звонков оценивают и нейросеть, и контролёр, расхождения разбираем до запуска на весь поток.
Сверка с контролёром на старте показывает, какие пункты модель понимает не так, как человек, и где чек-лист написан двусмысленно. Без неё оценке верят на слово.
