директор и машина · контроль качества · запись № 006 · 14 июня 2026 · Давид Герштейн

Как оценивать звонки: пять критериев вместо полусотни пунктов

Отдел настраивал систему оценки звонков четвёртый месяц. Десять вариантов чек-листов под разные сценарии — первичный звонок, звонок продаж, вторичный контакт, встреча. Каждый месяц — доработки. Не потому что систему делали плохо. Потому что чек-лист оценки звонка — это не документ на одну страницу, а живая настройка, которая ломается на реальных звонках чаще, чем кажется на этапе презентации.

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

Почему пятьдесят пунктов не работают

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

Человек физически не может держать в голове пятьдесят критериев, слушая живой разговор. Он либо сваливается в формальную галочку («вроде было»), либо тратит на один звонок пятнадцать минут вместо пяти. А 25% охвата вручную — это уже потолок ресурса, а не вопрос качества работы контролёров. В отделах с большей нагрузкой на менеджера этот потолок проседает и до 10% — предел зависит от общего потока звонков и штата контроля, а не от желания людей проверять больше.

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

Чек-лист оценки звонка: пять пунктов, которые реально работают

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

Здесь нет пункта «улыбался ли голосом». Есть проверяемые вещи. Тип звонка либо определён, либо нет. Срок молчания либо нарушен, либо нет. Скрипт для этапа либо соблюдён, либо нет. Это бинарные или почти бинарные критерии — именно поэтому ИИ на них не «гуляет» между прогонами.

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

Инженерная связка: как модель понимает, какой звонок оценивать

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

Рабочая схема конвейера выглядит так (на диаграмме — пять шагов, от вебхука Bitrix24 до финальной оценки чек-листа):

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

Промпт: разделение на дешёвую и дорогую модель

Классификация типа звонка — задача с 3–4 вариантами ответа, глубокий контекст не нужен. Для неё хватает дешёвой модели уровня GPT-4o-mini — она быстрая и почти не влияет на счёт за месяц даже при полном охвате звонков. Финальная оценка по чек-листу требует понимания контекста разговора, нюансов возражений и связи с предыдущими звонками — здесь оправдана более дорогая модель уровня GPT-4 с расширенным окном контекста.

Структура входных данных для второго шага (передаётся из Google Sheets, куда предварительно попадают ID звонка, менеджер, тип и ссылка на транскрипт):

Ты — контролёр качества звонков отдела продаж.
На входе:
- тип_звонка: {{тип из шага классификации}}
- менеджер: {{имя менеджера}}
- транскрипт: {{текст или ссылка на полный текст, если обрезан}}
- чек_лист: {{пять критериев для этого типа звонка}}

Задача:
1. Оцени звонок по каждому критерию чек-листа: 1 (выполнено), 0 (не выполнено),
   null (невозможно определить из транскрипта — не придумывай).
2. Для критерия "тон и эмпатия" верни короткую цитату-пример,
   только если есть явное нарушение.
3. Укажи, зафиксирован ли результат звонка в CRM (да/нет) и какой именно.
4. Не оценивай то, чего нет в тексте. Если данных не хватает — верни null,
   а не догадку.

Ответ верни строго в формате JSON без пояснений вне JSON.

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

{
  "call_id": "d-88213",
  "manager": "M-07",
  "call_type": "звонок продаж",
  "checklist_scores": {"type_ok": 1, "sla_ok": 1, "script_ok": 0, "tone_flag": null, "crm_fixed": 1},
  "tone_quote": null,
  "comment": "Пропущен блок отработки возражения по цене, шаг 3 скрипта"
}

Так выглядит итоговый отчёт руководителя после полного охвата — не выборка, а поток всех звонков за день:

Инженерная обвязка держится не на скрипте-энтузиасте, а на трёх правилах. Где крутится: серверная часть — Google Apps Script или облачная функция, дёргающая Bitrix24 REST API по расписанию раз в сутки; результаты падают в Google Sheets, из которого руководитель забирает выгрузку в личный кабинет. Как перезапускается: при обрыве на шаге транскрибации задание уходит в очередь повторных попыток с экспоненциальной задержкой, а не падает молча. Как сообщает об ошибке: в Telegram-канал руководителя автоматизации уходит алерт с ID звонка и кодом ошибки — тем же ботом, что шлёт алерты о задержках ответов менеджеров.

Технический капкан, который стоил месяца доверия

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

Калибровка: без разговора с менеджером чек-лист мёртв

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

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

Экономика: сколько стоит проверка и что она даёт

Возьмём условный отдел из 8 менеджеров продаж, каждый закрывает в среднем 15–20 звонков в день — то есть от 120 до 160 звонков по отделу; для расчёта возьмём середину диапазона, 140 звонков в день. Ручная проверка одного звонка по расширенному чек-листу занимает 10–15 минут — усреднённая цифра из практики контроля качества, для расчёта возьмём середину, 12 минут (оценка).

Формула для ручного 100% охвата словами: звонков в день × минут на проверку одного звонка ÷ 60 = часы, которые нужно закрыть контролёрам. На наших числах: 140 × 12 / 60 = 28 часов в день. При восьмичасовой смене это 28 / 8 = 3,5 ставки контролёра — с запасом на отчётность округляем до 4.

Текущий охват в 25% (35 звонков в день из потока 140) укладывается ровно в одну смену: 35 × 12 / 60 = 7 часов — это и есть тот самый контролёр, который «физически не успевает больше». Чтобы закрыть оставшиеся 75% потока руками, нужны ещё 3 ставки. При условной ставке специалиста контроля качества (ориентировочная рыночная ставка для такой позиции) это 8 часов × 3 ставки × 22 рабочих дня — то есть дополнительно три полных ставки в месяц только на то, чтобы прослушивать, без учёта написания отчётов и обучения; в пересчёте на эксплуатацию модели это кратно больше стоимости обработки того же потока звонков автоматикой.

Читателю, который хочет прикинуть свой случай: формула та же — поток звонков в день × минуты на ручную проверку ÷ 60 = часы; часы ÷ длительность смены = недостающие ставки; ставки × часы смены × своя ставка в час × число рабочих дней = ежемесячная стоимость закрытия разрыва руками. Подставьте свои цифры вместо 140 и 12 — порядок величины будет тем же.

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

Речевая аналитика с автоматической классификацией и оценкой снимает потолок ручного охвата: 100% вместо выборочных 25% (в некоторых отделах — вместо 10%), без роста штата контроля. Экономический эффект здесь не в замене одного контролёра ИИ — это отдельный организационный шаг, который в разных компаниях планируют делать поэтапно и после проверки методологии, минимум за 3 месяца параллельной работы. В одной из практик по итогам такого перехода планируют отказаться минимум от двух штатных единиц контроля качества — но это управленческое решение после проверки методологии, а не автоматический результат внедрения чек-листа. Вклад именно чек-листа и оценки — в том, что охват растёт без пропорционального роста затрат на контроль, а не в том, что штат сокращается автоматически в день внедрения.

На диаграмме — до и после внедрения речевой аналитики:

Охват контроля вырос с 25% звонков (35 из 140 в день, проверяемых вручную) до 100% при автоматической оценке — без увеличения штата контролёров.

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

Стандарты обслуживания по телефону: что стоит за цифрами

Сроки — часть любого чек-листа, но их легко занизить или завысить без реальных данных. В одной компании средний ответ на сообщение клиента — 8 часов, включая нерабочее время и сон, что требует отдельной проверки на честность метрики: если считать только рабочие часы, реальная скорость реакции может выглядеть иначе. Максимальный допустимый срок тишины — две недели, но ответ внутри рабочего дня требуется всегда. Это конкретные, измеримые нормативы — не «отвечать быстро», а число, которое можно проверить автоматически через тот же вебхук, что выгружает звонки.

Отдельное правило для повторных касаний: если клиент молчит больше 24 часов после первого контакта — повторное сообщение через 4 часа, а если ответа нет и после этого — прописан следующий шаг сценария (вторая попытка, эскалация), а не открытый разбор без решения. Это тоже часть чек-листа, только не по звонку, а по цепочке коммуникации целиком.

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

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

• Выписать 2–3 реальных типа звонков в своей воронке — не десять, а именно те, что реально повторяются.
• Взять пять критериев из таблицы выше и адаптировать формулировки под свой скрипт продаж.
• Настроить выгрузку звонков из CRM по уникальным ID (сущность, менеджер, время), а не полагаться на ручные отметки этапов.
• Прогнать выборку в 50–70 звонков через ИИ и через ручную оценку, посчитать дельту отклонения.
• Провести калибровочную сессию хотя бы с одним менеджером на каждый тип звонка.
• Только после совпадения оценок в 80–90% случаев — расширять охват и снижать долю ручного контроля.

Это медленнее, чем «внедрить ИИ за неделю». Зато к моменту, когда систему используют для решений о премиях или увольнениях, она уже проверена, а не работает на веру.

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

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

Пять-семь, привязанных к типу звонка. Больше — и оценка превращается в формальность, которую никто не читает.

Как проверить, что ИИ-оценка звонков адекватна?

Сравнить с ручной оценкой на выборке 50–70 звонков и посчитать дельту отклонения, прежде чем убирать людей из контроля.

Что делать, если ИИ по-разному оценивает один и тот же звонок?

Это сигнал, что чек-лист сформулирован нечётко. Переписывать критерии, пока повторная обработка не даёт одинаковый результат.

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