директор и машина · контроль качества · запись № 051 · 27 августа 2026 · Давид Герштейн

Как нейросеть научили оценивать звонки менеджеров: от калибровки до расхождений с ручной проверкой

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Старший менеджер отдела контроля качества — назовём её Ира — слушала звонки ушами. Тридцать в день, больше физически не помещалось: прослушать, сверить со скриптом, выставить оценку, записать замечание. В отделе продаж — восемь менеджеров, суммарно они закрывают порядка 120 звонков в день (около 2600 в месяц при 22 рабочих днях) — то есть Ира физически успевает разобрать примерно четверть общего потока, и не из-за лени отдела ОКК, а потому что на большее не хватает рук ни у кого. Так родилась идея ИИ-оценки звонков менеджеров: пусть нейросеть проверяет все разговоры, а не только четверть потока вручную.

Цена необнаруженной ошибки здесь не абстрактная. Один сорванный контракт с ключевым дистрибьютором — менеджер на этапе согласования условий обещал не то, что было в прайсе, и это никто не услышал вовремя — обходится, по грубой оценке, до 2,4 млн ₽ (около 27% месячного оборота условной компании — оценка, легенда). А сама Ира тратит на прослушивание около четырёх часов в день — при ставке 1000 ₽/час и 22 рабочих днях это около 88 часов и 88 000 ₽ в месяц (оценка), которые уходят на то, чтобы просто услышать разговор, а не на то, чтобы что-то с ним сделать. Формула для прикидки на своих цифрах простая: часы прослушивания в день × рабочие дни в месяце × ставка контролёра = сколько компания платит за ту долю покрытия, которую физически вытягивает один человек.

Экран, которому никто не верил

Первый вариант контроля выглядел как таблица в Excel: дата, менеджер, тема звонка, оценка от 1 до 10, комментарий. Заполняла её Ира вручную, после прослушивания. Экран честный, но узкий: он показывал мнение одного человека о четверти звонков компании. Остальные три четверти существовали только в записи на сервере телефонии — если вообще существовали, потому что часть звонков не сохранялась из-за сбоев интеграции.

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

Что было не так: три причины, по которым цифры не сходились

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

Первая — не тот звонок. «Проблема любой ИИ, которая связана с любой CRM, заключается в том, что как система должна понять, что это именно тот звонок, который нужно оценить», — и это не риторика. Первый звонок клиенту может быть холостым (не дозвонились), следующий система может не захватить, а менеджер переводит сделку на нужный этап нерегулярно — значит, привязка «оценивать звонок при переходе на этап» ловит не всё и не всегда.

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

Третья — нестабильность самой модели. «Оценка, она не всегда адекватна» — и это подтвердилось: один и тот же звонок при повторной обработке мог получить разные баллы. Для чек-листа с чёткими критериями (сказал/не сказал, спросил/не спросил) это не должно происходить, но происходило — из-за температуры генерации по умолчанию и из-за того, что модель иногда достраивала контекст там, где расшифровка была неоднозначной.

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

Как теперь нейросеть оценивает звонки: пересборка конвейера

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

1. Триггер выгрузки — не переход по этапам, а обязательное поле. Вместо того чтобы заставлять менеджеров дисциплинированно двигать сделку по воронке, систему перестроили: аудиозапись прикрепляется к обязательному полю на этапе «встреча проведена» (или отмечается по факту завершения разговора для звонков). Именно заполнение этого поля — триггер для выгрузки, а не факт смены статуса сделки.
2. Выгрузка с уникальными идентификаторами. Каждый звонок выгружается из CRM с тройкой: ID сущности (сделки), менеджер, время звонка. Это позволяет системе не путать, какой из нескольких звонков по одному клиенту нужно оценивать, и анализировать контекст предыдущих разговоров с этим же клиентом перед оценкой встречи.
3. Определение менеджера и типа звонка. Нейросеть по записи определяет, кто говорит (по имени, названному в разговоре) и к какому из десяти типов относится звонок: первичный звонок лида, звонок продаж, вторичный звонок, встреча и так далее. Тип определяет, какой чек-лист применить — единого чек-листа «на все звонки» не бывает.
4. Транскрибация с защитой от обрезки. В таблицу теперь попадает краткий фрагмент расшифровки плюс ссылка на полный текст, хранящийся отдельно (в Google Drive). Модель, оценивающая звонок, всегда обращается к полному тексту по ссылке, а не к обрезанному фрагменту в ячейке.
5. Оценка по релевантному чек-листу и запись в личный кабинет руководителя. Результат — оценка, ключевые нарушения и цитаты из разговора — попадает в отчёт, доступный руководителю отдела продаж без ручной обработки.

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

ИИ-связка целиком: промпты и обвязка

Схема конвейера: Bitrix24 (сделка, этап «встреча проведена», аудиозапись) → вебхук выгружает запись и метаданные (ID сделки, менеджер, время) → сервис транскрибации (Whisper API) кладёт полный текст в Google Drive и краткий фрагмент + ссылку — в Google Sheets → LLM-классификатор определяет тип звонка → LLM-оценщик берёт чек-лист под этот тип и выставляет баллы с цитатами → результат пишется обратно в таблицу и подтягивается в личный кабинет руководителя.

Модель для транскрибации — дешёвая по определению (Whisper), она не «думает», а переводит звук в текст. Для классификации типа звонка и для оценки по чек-листу мы берём тоже недорогую модель (уровня GPT-4o-mini) — задача формализована чек-листом, дорогая модель почти не даёт прироста точности, зато счёт за токены растёт кратно при объёме в сотни звонков в месяц.

Ты — асессор отдела контроля качества оптовой компании.
Тебе передан транскрипт телефонного звонка менеджера с клиентом.

Данные:
- call_id: {{call_id}}
- manager_name: {{manager_name}}
- call_type: {{call_type}}  // first_call | sales_call | repeat_call | meeting
- transcript: {{transcript_full_text}}
- checklist: {{checklist_json}}  // список пунктов чек-листа для этого call_type

Задача:
1. Проверь, соответствует ли содержание звонка заявленному call_type.
   Если нет — укажи расхождение в поле call_type_match.
2. Оцени звонок строго по пунктам checklist. Каждый пункт — 0, 0.5 или 1.
3. Для каждого пункта укажи цитату из транскрипта, на основании которой
   поставлена оценка. Если подтверждения в тексте нет — ставь 0.
4. Посчитай итоговый балл: сумма баллов / максимум * 100.
5. Если транскрипт выглядит обрезанным (обрывается на полуслове или
   длина текста заметно меньше ожидаемой для длительности звонка) —
   верни "incomplete_transcript": true и не выставляй итоговую оценку.

Верни строго JSON без пояснений вне него.

Пример ответа модели:

{
  "call_id": "CL-88231",
  "manager_name": "Светлана К.",
  "call_type_detected": "sales_call",
  "call_type_match": true,
  "checklist_score": 7.5,
  "checklist_max": 10,
  "score_percent": 75,
  "incomplete_transcript": false,
  "flags": ["не назвал сроки доставки", "не уточнил объём партии"]
}

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

Тебе передан список звонков одного менеджера за месяц с двумя оценками:
автоматической (ai_score) и ручной от контроля качества (human_score),
а также баллы по отдельным пунктам чек-листа с обеих сторон.

Данные (Google Sheets, построчно):
call_id | manager_name | checklist_item | ai_score | human_score | delta

Задача:
1. Посчитай средний модуль дельты по каждому пункту чек-листа.
2. Найди 2-3 пункта с наибольшим системным расхождением
   (не случайным, а повторяющимся из звонка в звонок).
3. Сформулируй гипотезу, почему именно эти пункты расходятся
   (двусмысленная формулировка критерия, зависимость от интонации,
   которую не видно в тексте, и т.д.).
4. Предложи, что поправить: формулировку пункта чек-листа
   или инструкцию модели.

Верни ответ в виде краткого списка гипотез, без общих фраз.

Инженерная обвязка простая, без экзотики: скрипт на Google Apps Script по расписанию (раз в сутки) тянет новые записи из Bitrix24 по вебхуку, кладёт файлы в Drive, дёргает API транскрибации и LLM, пишет результат в Sheets. При сбое любого шага — сообщение в Telegram-канал отдела контроля качества с call_id и текстом ошибки, а не тихий пропуск строки. Ретраи ограничены тремя попытками на звонок: без этого ограничения легко повторить чужую историю, где ошибка в коде вызвала циклический запрос на 40 долларов за одну ночь — разбор этого случая есть в статье о реальных счетах за ИИ.

Калибровка: 66 звонков, дельта и разговор с Ирой

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

Именно на этом массиве стало видно то, что нельзя было увидеть на единичных примерах: расхождение не было равномерным. По формальным пунктам (назвал ли сроки, представился ли, уточнил ли объём) ИИ и человек почти всегда сходились. По пунктам, завязанным на тон и эмпатию — «проявил ли менеджер заинтересованность», «снял ли возражение мягко» — расхождение было заметно чаще. Это ожидаемо: такие критерии субъективны даже для двух живых оценщиков, не только для модели.

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

На диаграмме — охват звонков контролем до внедрения ИИ и после.

До: 660 звонков в месяц из ~2600 проверяла вручную Ира. После: все 2600 звонков проходят через ИИ-оценку, часть — с выборочной сверкой ОКК.

Экран сегодня: что показывает отчёт руководителю

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

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

После настройки компания планирует сократить минимум две штатные единицы контроля качества. Но это решение про штат, а не про сам инструмент — экономику ИИ-оценки я считаю отдельно, ниже.

Экономика: что это стоит и что даёт

Внедрение. Настройка конвейера — не разовая задача на день: она шла четвёртый месяц с постоянными доработками (новый тип звонка, отсутствие менеджера в записи, обрезка транскрипта). По грубой оценке — это 60–80 часов работы специалиста по автоматизации, при ставке около 1500 ₽/час — 90 000–120 000 ₽ (оценка, легенда).

Эксплуатация. При объёме около 120 звонков в день (порядка 2600 в месяц) транскрибация Whisper API стоит примерно $0,006 за минуту звучания — для среднего звонка 5–7 минут это около $0,04 за звонок. Классификация типа и оценка по чек-листу дешёвой моделью (уровня GPT-4o-mini) добавляют ещё $0,02–0,04 за звонок (оценка: точная сумма зависит от длины транскрипта и промпта). Итого — около $0,06–0,08 на звонок, или при 2600 звонках в месяц — $150–210, то есть примерно 15 000–20 000 ₽ (оценка, курс ~100 ₽/$).

Экономия. Ставка специалиста контроля качества в легенде — около 70 000 ₽ в месяц с налогами. Два освобождающихся места — это около 140 000 ₽ в месяц ФОТ, которые компания перестаёт платить за прослушивание вручную. Разовые затраты на внедрение (90–120 тыс. ₽) окупаются меньше чем за месяц такой экономии, а ежемесячные 15 000–20 000 ₽ за токены и транскрибацию — это около 10–15% от прежних затрат на ручной контроль.

Если считать по стоимости одного звонка, разница нагляднее. Ручная проверка при охвате 25% (660 звонков в месяц из общего потока) обходилась в 88 000 ₽ ÷ 660 ≈ 133 ₽ за звонок. Автоматическая оценка при охвате 100% (2600 звонков) — это 15 000–20 000 ₽ ÷ 2600 ≈ 6–8 ₽ за звонок. То есть каждый проверенный звонок стал примерно в 15–20 раз дешевле, а число проверенных звонков выросло вчетверо.

Формула для своего случая: возьмите объём звонков в месяц, умножьте на стоимость транскрибации и оценки одного звонка (обычно доли цента — несколько центов у дешёвых моделей), сравните с тем, что сейчас платите за ставки контролёров, умноженные на долю звонков, которую они физически успевают прослушать. Если разница в разы — есть смысл считать дальше; если нет, вероятно, объём звонков слишком мал, чтобы настройка конвейера окупилась.

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

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

Сколько звонков нужно, чтобы проверить точность ИИ-оценки?

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

Почему нейросеть по-разному оценивает один и тот же звонок?

Две причины: модель по умолчанию недетерминирована (нужно фиксировать температуру и делать контрольные повторные прогоны), и обрезанный транскрипт — если текст обрывается на середине из-за лимита ячейки таблицы, ИИ оценивает неполный разговор.

Можно ли сразу отказаться от ручного контроля качества после внедрения ИИ?

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

#ии и нейросети #контроль и надёжность #аналитика и отчётность