# Директор и машина — Контроль качества: полные тексты

Направление: Контроль качества — оценка звонков · стандарты сервиса · работа с жалобами
Хаб направления: https://davidgerstein.pro/kachestvo/
Материалов в файле: 6 из 6 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json

## Как построить систему контроля качества звонков: от записи до отчёта руководителю
URL: https://davidgerstein.pro/kachestvo/kontrol-kachestva-zvonkov-mehanika/
Дата: 2025-01-20
Направление: Контроль качества
Цифры: 25%→100% охват · 66 звонков сверки · 10 чек-листов
Коротко: Ручной контроль в среднем закрывает 25% звонков отдела продаж — остальное руководитель не слышит вообще. ИИ-скоринг с калибровкой на 66 сверочных звонках поднимает охват до 100% и обходится дешевле одной ставки контролёра. В гайде — все узлы системы: выгрузка, транскрибация, чек-листы, калибровка, экономика и промпты, которые можно скопировать в свою CRM.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Я прошёл этот путь целиком — от «слушаю выборочно, когда есть время» до конвейера, который оценивает каждый разговор. Ниже то, что я бы хотел знать в начале: где именно ломается, сколько стоит и почему первые оценки машины нельзя показывать команде. Полная механика контроля качества звонков: от чек-листов до дашборда. Если вы собираетесь ставить это у себя — здесь весь путь, включая цифры и места, где мы спотыкались. Как работает контроль качества звонков на ИИ Ручной контроль закрывает в среднем 25% разговоров — остальное руководитель не слышит вообще. Машинный конвейер поднимает охват до 100% и обходится дешевле одной ставки контролёра: около $300 в месяц на весь поток. Доверять оценкам можно только после калибровки: отдел контроля качества сверил 66 звонков вручную и получил разрыв с машиной в 25,5 процентных пункта . Без такой сверки цифры выглядят убедительно и означают не то, что кажется. Почему «прослушать пару разговоров» — это не контроль Проверьте свою ситуацию: сколько процентов разговоров у вас слушает хоть кто-нибудь? Если меньше половины, вы не контролируете качество, вы делаете выборочные замеры настроения. Контроль качества звонков — это система, которая проверяет каждый (а не выборочный) разговор менеджера с клиентом на соответствие скрипту, полноту работы с возражениями и соблюдение регламента, и превращает это в оценку, отчёт и обратную связь. Пока контроль выборочный — вы видите не качество работы отдела, а качество работы тех 10–25% сделок, которые случайно попали в выборку контролёра. Старший менеджер по контролю качества Ира слушала звонки ушами, пока их было тридцать в день. При таком объёме это работало: она успевала прогнать через себя весь пул за смену. Как только звонков стало в разы больше, а отдел вырос до 8 менеджеров, тридцать в день превратились в полторы сотни — и ручной контроль физически перестал закрывать больше четверти потока. Это не история про лень или недостаток квалификации: одна пара ушей просто не масштабируется. 25% было 100% стало На диаграмме — охват звонков контролем: ручная прослушка одним контролёром закрывала около четверти потока отдела из 8 менеджеров, автоматическая выгрузка и ИИ-скоринг после калибровки доводят охват до полного объёма. Где ломается. Одна пропущенная ошибка в контроле качества может стоить дороже, чем весь годовой бюджет системы контроля: сорванный крупный контракт, испорченные отношения с клиентом, юридический риск из-за незафиксированного обещания менеджера. Разбор одной такой ошибки и того, во что она обошлась, — дальше, в разделе про чек-лист из пяти критериев. Дальше в статье — не про то, «как приятно, когда всё автоматизировано», а про то, из каких узлов реально собирается система, где она чаще всего рвётся и сколько это стоит на цифрах условной компании: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 тыс. ₽, цикл сделки ~6 недель. Из чего физически состоит система Пять элементов. Посмотрите, что из этого у вас уже есть — обычно половина. Рабочая система контроля качества звонков — это не одна нейросеть, а конвейер из шести узлов: выгрузка и идентификация записи, транскрибация, классификация типа звонка, оценка по чек-листу, сведение с ручной проверкой на калибровке и выдача отчёта руководителю. Выпадение любого узла делает всю цепочку бесполезной — оценка на неполном тексте так же вредна, как оценка звонка, который вообще не тот, что нужно было оценивать. Узел Что делает Частая поломка Выгрузка и идентификация Достаёт запись из CRM и привязывает к сделке, менеджеру, этапу Система не понимает, какой звонок из серии — целевой Транскрибация Превращает аудио в текст Обрезается по лимиту символов ячейки, текст режется на середине фразы Классификация Определяет тип: первичный лид, продажа, вторичный звонок, встреча Один и тот же промпт применяется ко всем типам без разбора Оценка по чек-листу Выставляет баллы по релевантному именно этому типу чек-листу Один чек-лист на полсотни пунктов вместо пяти релевантных критериев Калибровка Сверяет оценку модели с ручной оценкой человека Калибровку пропускают, чтобы быстрее «запустить» Отчёт Собирает баллы в личный кабинет руководителя Отчёт есть, но по нему нельзя провалиться в конкретный звонок Так выглядит финальный отчёт, в который стекаются результаты всех узлов конвейера — от выгрузки до калибровки: Отчёт: контроль качества звонков 2 600 звонков в месяц 100% звонков под контролем 66 звонков сверки ИИ/человек Менеджер Ср. балл Статус Менеджер 4 7/10 есть red flags Менеджер 2 9/10 норма Дальше разберу каждый узел отдельно — потому что именно на стыках между ними компании теряют месяцы на настройку. Выгрузка и идентификация У нас на этом шаге ушла неделя: телефония отдавала записи без привязки к сделке, и мы сначала не понимали, чей это звонок. Правильная выгрузка — это не «слушать всё подряд», а автоматическая привязка каждой записи к сделке по уникальному ID, менеджеру и времени, с триггером на нужном этапе воронки, а не на ручном действии менеджера. Первая версия почти всегда строится на допущении «менеджер переведёт сделку на промежуточный этап, и мы поймём, что звонок целевой». Это допущение не работает: менеджер переводит этапы непостоянно, первый звонок может оказаться холостым, а следующий за ним система вообще не захватывает. Рабочее решение — выгружать все звонки из CRM с уникальными идентификаторами (ID сущности, менеджер, время звонка), а триггером для оценки встречи делать не ручной перевод этапа, а заполнение обязательного поля с аудиозаписью на этапе «встреча проведена». Перед оценкой конкретной встречи система дополнительно поднимает контекст предыдущих звонков с тем же клиентом — иначе оценка получится обрывочной, как будто менеджер начал разговор с чистого листа. Где ломается. «Проблема любой системы, которая связана с любой CRM, — как понять, что это именно тот звонок, который нужно оценить» — с этого вопроса начинается почти любой проект контроля качества, и на нём же чаще всего стопорится на месяц-два. Транскрибация: изнанка, о которую всё разбивается Здесь вас ждёт первая настоящая проблема, и она не про ИИ: если запись обрывается, вы получите уверенную оценку неполного разговора. Транскрибация — самое незаметное звено конвейера, и именно оно чаще всего портит итоговую оценку: если текст обрезан, модель оценивает не звонок, а его обрывок, и делает это уверенно, не сигнализируя об ошибке. Классический сценарий: транскрипт заливают прямо в ячейку таблицы, а у ячейки есть лимит символов. Длинный звонок обрезается на середине фразы, ИИ получает неполный текст и неправильно оценивает качество разговора — причём внешне отчёт выглядит абсолютно рабочим, никаких ошибок и алертов. Именно с недоверия к таким «плывущим» оценкам на обрезанных транскриптах Ира начала пересматривать весь конвейер: если бы она не сверяла оценку модели с тем, что реально было в разговоре, расхождение так и осталось бы незамеченным. Рабочее решение простое: вместо вставки полного текста в таблицу система сохраняет краткий фрагмент и добавляет ссылку на полный текст в отдельном хранилище, где его можно открыть при разборе. Подробнее про эту и другие технические ловушки — в разборе про транскрибацию, которая обрывается на полуслове . Сколько критериев вам реально нужно Короткий ответ: пять. Всё, что больше, ваши люди перестанут заполнять честно. Рабочий чек-лист — это 5 критериев под конкретный тип звонка, а не 50 универсальных пунктов на все случаи сразу: чем длиннее список, тем ниже согласованность между тем, как оценивает его человек, и тем, как оценивает его модель. Готовые системы контроля качества на рынке обычно предлагают один универсальный чек-лист на все звонки. Это не работает: первичный звонок лида, звонок в рамках сделки и вторичный контакт с уже действующим клиентом требуют разных критериев — то, что критично на первом касании (выявить потребность), не имеет смысла проверять на встрече, где клиент уже подписывает договор. Рабочий вариант — набор из отдельных чек-листов под тип звонка (в проверенных конфигурациях их обычно около десяти), а внутри каждого — пять критериев вместо полусотни. Разбор, почему пять критериев дают более честную оценку, чем громоздкий универсальный список, и во сколько может обойтись пропущенная в чек-листе ошибка, — в материале про пять критериев вместо полусотни пунктов . ИИ-скоринг против ручной оценки Ваш способ проверить, можно ли доверять машине, — калибровка: параллельные оценки и разбор расхождений. Без этого вы просто верите, а вера в управлении плохой инструмент. ИИ-скоринг звонков нельзя запускать на полный охват без калибровки: модель систематически «плывёт» — по одному и тому же звонку при повторной обработке может выдать разные баллы, и без сверки с человеком это расхождение никто не заметит, пока не станет дорогим. Рабочая практика — параллельный прогон: за контрольный период (в проверенной конфигурации — 66 звонков) оценка идёт одновременно у модели и у живого контролёра, по каждому звонку считается дельта отклонения. Если дельта стабильно небольшая — можно постепенно передавать модели больше объёма. Если дельта скачет — проблема либо в чек-листе (слишком общие формулировки), либо в промпте (модель не понимает контекст), либо в самой транскрибации. Именно на этом этапе руководители чаще всего произносят вслух то, что раньше держали при себе: «оценка не всегда адекватна» — и это нормальная, рабочая стадия проекта, а не повод его закрыть. Полная механика калибровки — от первой сверки до расхождений с ручной проверкой — разобрана в материале про то, как нейросеть научили оценивать звонки менеджеров . Где ломается. Компания без доказанной эффективности рискует автоматизировать контроль на цифрах, в которые никто не верит: «я не готов автоматизировать контроль качества, потому что не понимаю, работает ли методология и сколько это будет стоить» — типичная позиция руководителя до калибровки, и это правильная осторожность, а не сопротивление прогрессу. Контроль переписок и SLA ответа: где теряются деньги, пока все смотрят только на звонки Контроль качества нельзя ограничивать звонками: часть сделок сгорает не в разговоре, а в паузе между сообщениями в мессенджере — и эту паузу видно только через отдельный слой мониторинга, а не через прослушку. Рабочая связка здесь двухуровневая. Первый уровень — оперативный, Telegram-бот с алертами, если менеджер не ответил клиенту дольше установленного норматива. Второй — ежемесячный аналитический отчёт про недостатки эмпатии и деловой коммуникации в переписке, на основе которого строится точечное обучение. В зафиксированной практике средний ответ на сообщение держался на уровне 8 часов — но это число нужно проверять отдельно от рабочего времени: 8 часов с учётом ночи и 8 часов в рабочий день — принципиально разные результаты. Отдельное правило для тишины клиента: если ответа нет больше 24 часов после первого касания, отправляется повторное сообщение через 4 часа, а если и на него нет реакции — включается прописанный сценарий эскалации, а не тишина с обеих сторон. Все переписки при этом должны идти через фиксируемые каналы (открытые линии CRM), а не через личный WhatsApp менеджера — иначе при споре с клиентом компании нечем подтвердить свою позицию. Саботаж менеджеров: почему система контроля вызывает сопротивление и как его снять Менеджеры сопротивляются контролю качества не потому, что им есть что скрывать, а потому что оценку, которую они не понимают и с которой не могут поспорить, воспринимают как произвол — и это сопротивление снимается не приказом, а прозрачностью процедуры. Рабочий инструмент — калибровочная сессия «глаза в глаза» с каждым менеджером: руководитель разбирает одну реальную встречу, показывает автоматическую оценку и чек-лист, вслух проговаривает точки согласия и расхождения. Смысл не в том, чтобы менеджер согласился со всеми баллами, а в том, чтобы он видел логику модели и мог указать на её слепые зоны — это одновременно и обучение системы, и снятие тревоги команды. Пропуск этого шага — самый частый способ получить формально работающую систему контроля и фактически саботирующий её отдел продаж. Подробный разбор, как внедрить контроль звонков и не остаться без отдела продаж, — в материале про менеджеров против прослушки . С чего начать: минимальный контур за одну неделю Минимальный рабочий контур на неделю — это не внедрение полной системы, а ручная сверка на небольшой выборке звонков в Google Таблице, чтобы получить первые цифры до того, как тратить деньги на интеграцию. Выгрузить вручную 15–20 звонков за неделю из CRM (или попросить менеджера по автоматизации настроить разовую выгрузку по API) в Google Drive. Прогнать их через транскрибацию (любой доступный сервис распознавания речи) и вставить в Google Таблицу — сразу с учётом лимита символов ячейки, короткий фрагмент плюс ссылка на полный текст. Составить один чек-лист на 5 критериев под самый частый тип звонка в отделе (обычно это первичный звонок лида). Оценить эти же звонки вручную и параллельно прогнать через ИИ по тому же чек-листу. Посчитать дельту между оценками — это и есть ваша стартовая метрика доверия к будущей автоматизации. Этого достаточно, чтобы через неделю принести на планёрку не мнение «наверное, стоит попробовать нейросети», а таблицу с конкретными цифрами расхождения. Похожий путь — от 25% ручного охвата до 100% через нейросеть — уже проходили на другом отделе продаж, где итог считали в оценках и деньгах: 7139 оценок в месяц при затратах около $300 и всего одном негативном отзыве команды на весь запуск — детали в разборе контроля качества без штатного ОКК . Три промпта под три задачи контроля Мы пришли к этому не сразу: первый универсальный промпт давал усреднённую оценку, которая никого не устраивала. Один промпт не закрывает весь контроль качества: классификация типа звонка, оценка по чек-листу и анализ переписки на эмпатию — три разные задачи с разной ценой ошибки, и под них нужны разные модели. Промпт 1. Классификация типа звонка (дешёвая модель, например gpt-4o-mini). Используется как первый фильтр перед подключением тяжёлого промпта оценки. Вход — транскрипт, полученный по вебхуку из Bitrix24 при смене статуса сделки. Пример ответа модели: Промпт 2. Оценка звонка по релевантному чек-листу (дорогая модель, например GPT-4o или Claude Sonnet). Подключается после классификации, использует контекст предыдущих звонков с тем же клиентом. Вход — из amoCRM API: транскрипт, тип звонка (из промпта 1), история предыдущих касаний. Пример ответа модели: Промпт 3. Анализ переписки на эмпатию и деловую коммуникацию (дешёвая модель, ежемесячный batch-прогон). Вход — выгрузка чатов за месяц из Google Sheets, куда стекаются диалоги из открытых линий CRM. Пример ответа модели: Экономика: сколько стоит и когда окупается Наши цифры даю как ориентир — считайте на своём потоке и своей ставке контролёра. На отделе из 8 менеджеров с оборотом 9 млн ₽/мес и чеком 180 тыс. ₽ система контроля качества окупается в течение 1–2 месяцев после завершения калибровки — но первые три месяца параллельного прогона придётся платить дважды: за ручной контроль и за ИИ одновременно. Разовая настройка интеграции (выгрузка из CRM, классификация, чек-листы, личный кабинет) — это в среднем 2-3 недели работы программиста или подрядчика. Дальше — ежемесячная стоимость обработки: при 8 менеджерах и примерно 15 звонках в день на человека набегает около 2600 звонков в месяц, обработка каждого (транскрибация + классификация + оценка) через связку дешёвой и дорогой модели обходится примерно в 19 ₽ за звонок, а в сумме выходит около 50 000 ₽ в месяц — раскладка ниже в таблице. Статья Сумма (легенда, оценка) Комментарий Разовая настройка интеграции 150 000 ₽ Выгрузка из CRM, классификация, чек-листы, кабинет Обработка звонков ИИ, ежемесячно 50 000 ₽/мес ~2600 звонков × ~19 ₽ (транскрибация + скоринг) Доп. время ОКК на калибровку (3 мес.) 40 000 ₽/мес ~40 часов ручной сверки по ставке 1000 ₽/час Экономия ФОТ после отказа от 1 ставки контролёра 60 000 ₽/мес При переходе на 100% автоматический охват Снижение риска сорванных сделок 450 000 ₽/мес ~2,5 спасённые сделки из ~50/мес при чеке 180 тыс. ₽ Сделок в месяц ≈ оборот / средний чек = 9 000 000 / 180 000 = 50. Если 10% сделок зависает из-за пропущенных ошибок в звонках (не выявлено возражение, забыт follow-up) — это 5 сделок под риском, то есть риск в деньгах ≈ 5 × 180 000 = 900 000 ₽/мес до внедрения контроля. Если контроль спасает половину из них — выгода ≈ 450 000 ₽/мес (оценка). посчитайте на своих цифрах оборот в месяц, ₽ % зависших сделок % спасаемых контролем экономия ≈ {X} ₽ в месяц формула: оборот × доля зависших сделок × доля спасаемых контролем; оценка сверху Что мы не считаем эффектом: время, которое контролёр качества освобождает при переходе на выборочную ручную проверку, — если эти часы просто перераспределяются на другие задачи, а не сокращают ФОТ, в деньги их не переводим. Итог: ежемесячные расходы на систему (50–90 тыс. ₽ на калибровочной фазе) многократно перекрываются экономией на ФОТ и спасёнными сделками ещё до конца первого квартала эксплуатации. Похожую экономику, но в конкретных цифрах чужого внедрения — 7139 оценок в месяц за $300 — уже показывали выше, в разборе про контроль качества без штатного ОКК , на примере отдела без штатного ОКК. Важно не путать эффект: экономия здесь — результат именно контроля качества звонков, а не всего комплекса автоматизации отдела продаж. Где ломается. Ошибка в коде интеграции может обходиться дорого даже на этапе тестов: зафиксированный случай — циклический запрос за одну ночь съел 40 долларов. Это немного в абсолютных числах, но это сигнал: система должна работать с лимитами и алертами на аномальный расход с первого дня, а не после первого инцидента. Зрелость по уровням: где вы сейчас Найдите свой уровень и посмотрите, что делает следующий — это и есть ваша ближайшая задача. Зрелость системы контроля качества измеряется не количеством купленных инструментов, а долей звонков под контролем и тем, насколько команда доверяет оценке — на старте это обычно 25% и недоверие, через год — 100% и встроенное в регламент обучение. Уровень Охват звонков Что уже работает Старт (недели 1–4) ~25%, вручную Ручная сверка на выборке (в проверенной практике — 66 звонков), 1 базовый чек-лист, первые цифры дельты между человеком и моделью Квартал (мес. 2–3) 50–80%, параллельный прогон 10 чек-листов под разные типы звонков, калибровочные сессии с каждым менеджером, классификация типа звонка автоматическая Год 100%, полностью автоматически Отказ от отдельной штатной единицы контроля, речевая аналитика переписок, SLA-бот по мессенджерам, отчёт по эмпатии ежемесячно Набор из 10 чек-листов под разные сценарии — не избыточность, а следствие того, что разные типы звонков реально проверяются разными критериями; как это выглядит в готовой конфигурации — уже разбирали в разделе про калибровку выше. Чек-лист на первый понедельник Прогнать пять шагов минимального контура из раздела выше: выгрузка, транскрибация, чек-лист на 5 критериев, ручная плюс ИИ-оценка, дельта. Назначить дату калибровочной сессии с одним менеджером — на разбор реальной встречи. Проверить, где сейчас хранится переписка с клиентами: если в личном WhatsApp — начать перевод в фиксируемый канал CRM. Начните не с техники, а с одного вопроса своему руководителю отдела: сколько звонков он послушал на прошлой неделе и что после этого изменилось. Ответ покажет, нужна ли вам автоматика или сначала нужна привычка разбирать. Как собрать контур целиком — в бесплатном курсе для руководителей . Что мы поняли за три месяца эксплуатации Мы построили этот контур и получили красивые цифры охвата. А потом я обнаружил, что оценки почти не превращаются в разговоры с менеджерами: система работала, управление — нет. Навык, который тут вырастает и которого раньше не было ни у кого в отделе: судить о качестве чужого разговора по записанному правилу, а не по впечатлению. Я сам долго думал, что это интуиция руководителя и её нельзя формализовать. Оказалось, можно — и первый же чек-лист показал, что мы с руководителем отдела оценивали одни и те же звонки по-разному на четверть. Мой личный вывод после года с этим контуром: техническая часть здесь занимает от силы треть усилий. Остальное — привычка руководителя отдела разбирать результаты и менять по ним скрипты. Без этой привычки вы получите самый дорогой в мире генератор отчётов.

## Оценка работы менеджера по звонкам: как нейросеть разбирает весь поток и где она расходится с человеком
URL: https://davidgerstein.pro/blog/ai-call-scoring/
Дата: 2026-08-27
Направление: Контроль качества
Цифры: 66 звонков сверки · 25%→100% охват · 10 чек-листов
Коротко: Оценка работы менеджера строится не «вообще», а по чек-листу конкретного типа разговора — нейросеть разбирает звонок именно по нему; чтобы ей можно было доверять, нужна калибровка на выборке из 66 звонков с параллельной ручной оценкой и разбор расхождений с каждым менеджером. Без этого автоматика либо врёт, либо её саботируют.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Есть отчёт, которому никто не верит. У вас такой наверняка тоже есть — дашборд, который сделали, показали на планёрке и с тех пор не открывают. Наш был про качество звонков. Разбираю честно: почему цифрам не верили, что мы пересобрали и чем это кончилось. Если вы будете строить у себя оценку разговоров — здесь весь путь, включая места, где мы потеряли время. Старший менеджер отдела контроля качества — назовём её Ира — слушала звонки ушами. Тридцать в день, больше физически не помещалось: прослушать, сверить со скриптом, выставить оценку, записать замечание. В отделе продаж — восемь менеджеров, суммарно они закрывают порядка 120 звонков в день (около 2600 в месяц при 22 рабочих днях) — то есть Ира физически успевает разобрать примерно четверть общего потока, и не из-за лени отдела ОКК, а потому что на большее не хватает рук ни у кого. Так родилась идея ИИ-оценки звонков менеджеров: пусть нейросеть проверяет все разговоры, а не только четверть потока вручную. Цена необнаруженной ошибки здесь не абстрактная. Один сорванный контракт с ключевым дистрибьютором — менеджер на этапе согласования условий обещал не то, что было в прайсе, и это никто не услышал вовремя — обходится, по грубой оценке, до 2,4 млн ₽ (около 27% месячного оборота условной компании — оценка, легенда). А сама Ира тратит на прослушивание около четырёх часов в день — при ставке 1000 ₽/час и 22 рабочих днях это около 88 часов и 88 000 ₽ в месяц (оценка), которые уходят на то, чтобы просто услышать разговор, а не на то, чтобы что-то с ним сделать. Формула для прикидки на своих цифрах простая: часы прослушивания в день × рабочие дни в месяце × ставка контролёра = сколько компания платит за ту долю покрытия, которую физически вытягивает один человек. Оценка работы менеджера по звонкам: как это устроено Оценка работы менеджера по звонкам — это разбор его разговоров, а не отчёт по плану. Машина получает транскрипт, определяет тип разговора и оценивает его по чек-листу именно этого типа — с цитатой из разговора под каждым пунктом. В отделе продаж на восемь менеджеров таких чек-листов десять — по одному на каждый тип разговора. Доверять оценкам можно только после калибровки: 66 звонков отдел контроля качества оценил параллельно машиной и человеком и разобрал каждое расхождение. Это подняло охват контроля с 25% потока до 100% — при том, что человек физически успевал слушать четверть. посчитайте на своих цифрах часов прослушивания в день рабочих дней в месяце ставка контролёра, ₽/час ручное прослушивание ≈ {X} ₽ в месяц формула: часы прослушивания в день × рабочие дни × ставка контролёра Экран, которому никто не верил Если у вас есть отчёт, который вы сами не открываете неделями, — история дальше про вас. Первый вариант контроля выглядел как таблица в Excel: дата, менеджер, тема звонка, оценка от 1 до 10, комментарий. Заполняла её Ира вручную, после прослушивания. Экран честный, но узкий: он показывал мнение одного человека о четверти звонков компании. Остальные три четверти существовали только в записи на сервере телефонии — если вообще существовали, потому что часть звонков не сохранялась из-за сбоев интеграции. Когда решили автоматизировать оценку нейросетью, первая версия отчёта тоже не внушала доверия — уже по другой причине. ИИ оценивал звонки, но результат не с чем было сверить. Руководитель отдела прямо сформулировал условие: «Я не готов автоматизировать контроль качества, потому что не понимаю, работает ли методология, и не понимаю, сколько это будет стоить. Пока нет цифр, пока нет доказанной эффективности, я не готов». Похожий разрыв между «технически запустилось» и «реально работает» я разбирал в статье о том, почему внедрение ИИ не работает, хотя технически всё запустилось . Здесь это и стало задачей — не просто запустить оценку, а построить экран, на котором видно, где ИИ прав, а где нет. Что было не так: три причины Проверьте свои отчёты на эти три вещи — если найдёте хотя бы одну, вашим цифрам тоже не верят, просто вам об этом не говорят. Прежде чем сравнивать ИИ с человеком, пришлось понять, почему сама автоматическая оценка «плавала». Причины оказались разными, и чинить их пришлось по одной. Первая — не тот звонок. «Проблема любой ИИ, которая связана с любой CRM, заключается в том, что как система должна понять, что это именно тот звонок, который нужно оценить», — и это не риторика. Первый звонок клиенту может быть холостым (не дозвонились), следующий система может не захватить, а менеджер переводит сделку на нужный этап нерегулярно — значит, привязка «оценивать звонок при переходе на этап» ловит не всё и не всегда. Вторая — обрезанный транскрипт. Технически это выглядело так: расшифровку звонка вставляли в ячейку Google-таблицы, а у ячейки есть лимит на количество символов. Длинный разговор обрезался, и нейросеть оценивала неполный текст — соблюдение скрипта проверить по обрывку на середине фразы невозможно. Ира заметила это первой: несколько раз оценка ИИ по одному и тому же менеджеру резко расходилась с её собственной, и при разборе оказалось, что модели просто не хватило текста. Третья — нестабильность самой модели. «Оценка, она не всегда адекватна» — и это подтвердилось: один и тот же звонок при повторной обработке мог получить разные баллы. Для чек-листа с чёткими критериями (сказал/не сказал, спросил/не спросил) это не должно происходить, но происходило — из-за температуры генерации по умолчанию и из-за того, что модель иногда достраивала контекст там, где расшифровка была неоднозначной. Готового решения на все три проблемы на рынке не нашлось: «Нет ни одной системы на рынке, которая готова была бы оценивать вначале тип звонка, дальше его сегментировать и подключать к каждому типу отдельный промпт» — пришлось собирать конвейер самостоятельно, а не покупать коробочный сервис. Оценка работы менеджера после пересборки: что считает машина Схема, которую вы можете повторить. Ничего экзотического: запись, транскрипт, определение типа разговора, чек-лист под тип, оценка с обоснованием. Решение по каждой из трёх проблем было отдельным, но вместе они сложились в конвейер из пяти шагов. Триггер выгрузки — не переход по этапам, а обязательное поле. Вместо того чтобы заставлять менеджеров дисциплинированно двигать сделку по воронке, систему перестроили: аудиозапись прикрепляется к обязательному полю на этапе «встреча проведена» (или отмечается по факту завершения разговора для звонков). Именно заполнение этого поля — триггер для выгрузки, а не факт смены статуса сделки. Выгрузка с уникальными идентификаторами. Каждый звонок выгружается из CRM с тройкой: ID сущности (сделки), менеджер, время звонка. Это позволяет системе не путать, какой из нескольких звонков по одному клиенту нужно оценивать, и анализировать контекст предыдущих разговоров с этим же клиентом перед оценкой встречи. Определение менеджера и типа звонка. Нейросеть по записи определяет, кто говорит (по имени, названному в разговоре) и к какому из десяти типов относится звонок: первичный звонок лида, звонок продаж, вторичный звонок, встреча и так далее. Тип определяет, какой чек-лист применить — единого чек-листа «на все звонки» не бывает. Транскрибация с защитой от обрезки. В таблицу теперь попадает краткий фрагмент расшифровки плюс ссылка на полный текст, хранящийся отдельно (в Google Drive). Модель, оценивающая звонок, всегда обращается к полному тексту по ссылке, а не к обрезанному фрагменту в ячейке. Оценка по релевантному чек-листу и запись в личный кабинет руководителя. Результат — оценка, ключевые нарушения и цитаты из разговора — попадает в отчёт, доступный руководителю отдела продаж без ручной обработки. Настройка этого конвейера заняла не одну итерацию — на момент последнего разбора она шла уже четвёртый месяц и продолжает дорабатываться: то всплывает новый тип звонка, для которого нет чек-листа, то CRM возвращает запись без указания менеджера. ИИ-связка целиком: промпты и обвязка Схема конвейера: Bitrix24 (сделка, этап «встреча проведена», аудиозапись) → вебхук выгружает запись и метаданные (ID сделки, менеджер, время) → сервис транскрибации (Whisper API) кладёт полный текст в Google Drive и краткий фрагмент + ссылку — в Google Sheets → LLM-классификатор определяет тип звонка → LLM-оценщик берёт чек-лист под этот тип и выставляет баллы с цитатами → результат пишется обратно в таблицу и подтягивается в личный кабинет руководителя. Модель для транскрибации — дешёвая по определению (Whisper), она не «думает», а переводит звук в текст. Для классификации типа звонка и для оценки по чек-листу мы берём тоже недорогую модель (уровня GPT-4o-mini) — задача формализована чек-листом, дорогая модель почти не даёт прироста точности, зато счёт за токены растёт кратно при объёме в сотни звонков в месяц. Пример ответа модели: Второй промпт нужен не для оценки конкретного звонка, а для калибровочной сессии — он собирает расхождения между ИИ и человеком по менеджеру за период и ищет системные закономерности. Инженерная обвязка простая, без экзотики: скрипт на Google Apps Script по расписанию (раз в сутки) тянет новые записи из Bitrix24 по вебхуку, кладёт файлы в Drive, дёргает API транскрибации и LLM, пишет результат в Sheets. При сбое любого шага — сообщение в Telegram-канал отдела контроля качества с call_id и текстом ошибки, а не тихий пропуск строки. Ретраи ограничены тремя попытками на звонок: без этого ограничения легко повторить чужую историю, где ошибка в коде вызвала циклический запрос на 40 долларов за одну ночь — разбор этого случая есть в статье о реальных счетах за ИИ . Калибровка: 66 звонков и разговор с контролёром Это этап, который вы захотите сократить. Не сокращайте: без него вы не сможете ответить менеджеру на вопрос «а почему машина решила, что я плохо отработал возражение». Здесь обязан сказать про себя, иначе получится, что я умный задним числом. Я и сам долго считал калибровку перестраховкой: чек-лист формальный, модель читает текст — что там сверять. Обрезанный транскрипт нашёл не я. Его заметила Ира, и заметила ровно тем способом, который я считал лишним: её ручная оценка не сошлась с машинной, и она пошла разбираться. Так что если вам сейчас кажется, что месяц двойной работы можно проскочить, — это не глупость и не лень. Это нормальная первая мысль. Просто она дорогая: я на ней потерял время, которое мог потратить на доработку чек-листов. Прежде чем доверять автоматической оценке, отдел на протяжении месяца вёл параллельный учёт: каждый звонок оценивался и ИИ, и вручную — Ирой или другим специалистом контроля качества. Набралось 66 звонков с двумя оценками рядом. По каждому считалась дельта — разница между баллом ИИ и баллом человека. Именно на этом массиве стало видно то, что нельзя было увидеть на единичных примерах: расхождение не было равномерным. По формальным пунктам (назвал ли сроки, представился ли, уточнил ли объём) ИИ и человек почти всегда сходились. По пунктам, завязанным на тон и эмпатию — «проявил ли менеджер заинтересованность», «снял ли возражение мягко» — расхождение было заметно чаще. Это ожидаемо: такие критерии субъективны даже для двух живых оценщиков, не только для модели. Дальше — калибровочная сессия с каждым менеджером: руководитель разбирает одну его встречу, показывает автоматическую оценку и чек-лист, обсуждает точки согласия и расхождения. Смысл не в том, чтобы менеджер «принял» оценку, а в том, чтобы он помог её донастроить — указал, где чек-лист не учитывает специфику разговора. Без этого шага автоматику саботируют молча: соглашаются на словах, а по факту продолжают считать её несправедливой. Похожий сценарий тихого сопротивления команды разобран в статье о том, как внедрить контроль звонков и не остаться без менеджеров . Показатель До После Охват контролем звонков максимум 25% 100% Кто оценивает 1 специалист ОКК вручную ИИ + выборочная сверка ОКК Чек-листов на все типы звонков 1 универсальный 10, по типу звонка Транскрипт для оценки обрезался лимитом ячейки краткий фрагмент + ссылка на полный текст Проверено на расхождение с ручной оценкой — 66 звонков за месяц Срок параллельного запуска (человек + ИИ) — минимум 3 месяца На диаграмме — охват звонков контролем до внедрения ИИ и после. 25% до 100% после До: 660 звонков в месяц из ~2600 проверяла вручную Ира. После: все 2600 звонков проходят через ИИ-оценку, часть — с выборочной сверкой ОКК. Экран сегодня: что видит ваш руководитель отдела Правило, которое мы вывели: если для понимания «что делать сегодня» нужно больше двух кликов, отчётом пользоваться не будут. Ваш дашборд должен отвечать на вопрос, а не показывать данные. Личный кабинет руководителя теперь показывает не список случайных оценок, а срез по каждому менеджеру: тип звонка, балл по чек-листу, отмеченные нарушения с цитатой из разговора, и — отдельным столбцом на период калибровки — дельта с ручной оценкой. Провалиться в конкретный звонок можно одним кликом: открывается полный транскрипт по ссылке, а не обрезанный кусок. Личный кабинет руководителя · оценка звонков 2 600 звонков в месяц оценено 100% охват после внедрения 66 звонков сверки ИИ/человек Менеджер Тип звонка Балл Дельта с ОКК Менеджер 1 sales_call 75% 0.5 Менеджер 2 meeting 60% 2.0 Менеджер 3 first_call 90% 0.0 Похожую задачу — построение отчёта, который выдерживает придирчивый взгляд руководителя, а не просто «красиво выглядит» — я разбирал в материале о контроле звонков без отдела ОКК : там другая механика и другие цифры, но принцип тот же — сначала считать расхождение, потом доверять. После настройки компания планирует сократить минимум две штатные единицы контроля качества. Но это решение про штат, а не про сам инструмент — экономику ИИ-оценки я считаю отдельно, ниже. Экономика: что это стоит и что даёт Прикиньте свою: сколько у вас звонков в месяц, сколько из них слышит хоть кто-нибудь и во что вам обошёлся последний случай, когда менеджер пообещал клиенту то, чего не мог. Внедрение. Настройка конвейера — не разовая задача на день: она шла четвёртый месяц с постоянными доработками (новый тип звонка, отсутствие менеджера в записи, обрезка транскрипта). По грубой оценке — это 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 раз дешевле, а число проверенных звонков выросло вчетверо. Формула для своего случая: возьмите объём звонков в месяц, умножьте на стоимость транскрибации и оценки одного звонка (обычно доли цента — несколько центов у дешёвых моделей), сравните с тем, что сейчас платите за ставки контролёров, умноженные на долю звонков, которую они физически успевают прослушать. Если разница в разы — есть смысл считать дальше; если нет, вероятно, объём звонков слишком мал, чтобы настройка конвейера окупилась. Показатель Значение (оценка, легенда) Разовые затраты на внедрение 90 000–120 000 ₽ (60–80 часов × ~1500 ₽/час) Ежемесячная эксплуатация ИИ (транскрибация + оценка) 15 000–20 000 ₽ при ~2600 звонках в месяц Стоимость одного звонка вручную (охват 25%) ≈133 ₽ (88 000 ₽ ÷ 660 звонков) Стоимость одного звонка через ИИ (охват 100%) ≈6–8 ₽ (15–20 тыс. ₽ ÷ 2600 звонков) Экономия ФОТ после сокращения 2 ставок ОКК ≈140 000 ₽ в месяц Срок окупаемости разовых затрат меньше месяца экономии ФОТ — но не раньше окончания 3-месячного параллельного запуска риск, который легко упустить Три месяца параллельного запуска — это период, когда компания платит дважды: и за автоматику, и за ставки тех же специалистов, которые пока проверяют её выводы. Экономика начинает работать только после того, как параллельный контроль закончен и решение о сокращении штата принято по факту, а не на веру. Ира теперь не слушает тридцать звонков в день руками — она разбирает расхождения и калибрует модель. Работа не исчезла, она сместилась туда, где действительно нужен человек: не выявить нарушение по формальному пункту чек-листа, а понять, почему модель и человек по-разному слышат одну и ту же интонацию. И вещь, которую стоит назвать вслух. Умение сверить машину с человеком и предъявить цифру расхождения — это отдельный управленческий навык, такой же базовый, как чтение отчёта о продажах. Руководитель, который может показать менеджеру дельту в 0,5 балла и объяснить, из какого пункта чек-листа она взялась, управляет качеством. Руководитель, который умеет только сказать «нейросеть поставила 60%», управляет ощущением качества. Разницу между ними видно на первой же планёрке, где менеджер начинает спорить. Я этот навык осваивал уже по ходу внедрения, отдельно ему меня никто не учил. Если вы будете собирать похожий конвейер, начните не с промптов, а с калибровки: тридцать-шестьдесят звонков, оценённых параллельно машиной и человеком, покажут вам, каким пунктам можно доверять сразу, а какие держать под ручной проверкой. Без этого шага вы получите красивые цифры, которым не верит ни один менеджер. Остальные узлы контура — выгрузка записей, транскрибация, чек-листы, экономика — собраны в полном разборе механики контроля звонков . Полная механика с разбором расхождений — в бесплатном курсе для руководителей .

## Транскрибация звонков обрывается на полуслове: техническая изнанка
URL: https://davidgerstein.pro/blog/speech-analytics-fails/
Дата: 2026-08-27
Направление: Контроль качества
Цифры: 66 звонков/мес сверки · дельта оценок · лимит символов в ячейке
Коротко: Речевая аналитика в этом кейсе ошибалась не потому, что подвела модель, а потому что транскрипт звонка обрезался техническим лимитом ячейки таблицы ещё до того, как его увидел ИИ. Решение — хранить полную расшифровку отдельно по ссылке, а не в самой таблице, и проверять оценки ИИ ручной сверкой: за первый месяц так перепроверили 66 звонков.

Если вы купили речевую аналитику и она не окупилась — вы не одиноки, и дело почти наверняка не в вендоре. Разбираю на своём примере, где именно теряется смысл. Речевая аналитика в CRM должна была снять с Иры рутину прослушивания звонков — и почти сняла, пока не начала путать несделанную работу с сделанной. Ира на планёрке кладёт на стол распечатку одного звонка и говорит: «Я не понимаю, за что ему поставили тройку. Он же весь скрипт отработал». Смотрим оценку ИИ — действительно тройка, комментарий модели: «менеджер не выявил потребность, не назвал цену». Слушаем запись — потребность выявлена на второй минуте, цена названа на седьмой. Звонок на девять минут. Значит, дело не в звонке. Ира почти три года слушала звонки ушами — сначала по тридцать в день, потом меньше, когда добавились текстовые каналы. Она первая сказала фразу, которая потом стала поводом для отдельного разбора: «оценка плывёт», когда транскрипт какой-то… короткий. Мы сначала подумали, что дело в качестве записи — шум, обрыв связи. Оказалось, дело не в записи. Цифры, с которых всё стало понятно Прежде чем разбирать причину, три числа для масштаба. Контролёр успевала слушать около 30 звонков в день — это примерно 25% потока при 120 разговорах ежедневно. Средняя длина разговора — 8–12 минут, то есть на прослушивание уходило до 4 часов рабочего дня. А ячейка таблицы, куда складывалась расшифровка, вмещала около 50 000 знаков — примерно 40 минут разговора. Всё, что длиннее, обрезалось молча. Последнее число и есть причина: система оценивала неполные разговоры как полные, и делала это уверенно. Проверьте у себя этот же лимит — он есть почти в любой таблице. Где транскрибация звонков теряет ваши данные Три места, и все три вы можете проверить у себя за полчаса, не привлекая подрядчика. Расшифровки хранились прямо в таблице — одна ячейка на один звонок. Удобно: открыл строку, увидел весь текст, рядом оценка. Но у ячейки в таблице есть технический лимит на количество символов. Длинные звонки — от десяти минут и дольше — в этот лимит не влезали. Текст обрезался молча, без ошибки, без предупреждения. ИИ получал не весь разговор, а его начало, и честно оценивал только то, что видел. Система не ошибалась — она оценивала то, что ей дали. Дело было не в модели, а во входных данных. Честно скажу: это моя недоработка. Я сам согласовал схему, где расшифровка лежит прямо в ячейке, и не проверил, сколько туда влезает. Ира приносила мне «оценка плывёт» трижды — и трижды я отвечал, что дело в качестве записи. Если вы сейчас узнали свою ситуацию, это нормально: на такой лимит наступают все, кто складывает длинный текст в таблицу. Дальше выяснилось второе: даже когда транскрипт полный, оценка одного и того же звонка при повторном прогоне не всегда совпадает сама с собой. «Оценка, она не всегда адекватна» — так это сформулировали на разборе. Прогнали один звонок трижды — получили не три одинаковых результата, а три близких, но разных. Для менеджера, у которого от этой оценки зависит премия, разница в один балл — это не мелочь. Что сделали: ссылка на расшифровку вместо текста в ячейке С обрезкой транскрипта решение нашлось простое, хотя дошли до него методом исключения. Вместо полного текста в ячейке таблицы теперь хранится короткий фрагмент — начало разговора для ориентира — и ссылка на полную расшифровку, которая лежит отдельно и открывается по клику. ИИ для оценки берёт полный текст из документа, а не то, что видно в таблице глазами человека. Разделили «что показываем человеку» и «что скармливаем модели» — вопрос, который вообще стоит держать в голове, когда решаете, какие данные можно отправлять в нейросети , а какие нет. Половина проблемы закрылась. Со вторым — нестабильностью оценки — решили не бороться в лоб, а сначала измерить масштаб. Ввели ручную сверку: каждый месяц отдел контроля качества берёт часть звонков — набралось 66 за первый месяц — и оценивает их вручную параллельно с ИИ. По каждому звонку считается дельта: разошлись ли оценки и насколько. Это не финальное решение, это диагностика — мы пока не готовы полностью довериться автоматической оценке, если не понимаем, насколько она вообще адекватна. Заодно ручная сверка помогает не превратить запуск автоматической оценки в саботаж со стороны тех, кого она оценивает — эта часть внедрения устроена так же, как в кейсе про контроль звонков без саботажа . Честно: если раньше Ира могла ушами прослушать от силы тридцать звонков в день, то ручная сверка 66 звонков в месяц с оценкой ИИ — это ещё около трёх часов её времени каждую неделю, которые раньше не тратились. Пока это не экономия, это цена за то, чтобы вообще понять, можно ли автоматизации доверять. Почему это касается не только транскрибации Проблема шире одной ячейки в таблице. Любая CRM-интеграция речевой аналитики сталкивается с вопросом: как система понимает, что это именно тот звонок, который нужно оценивать. Первый звонок может быть холостым, следующий — система не захватит, менеджер не всегда переводит сделку на нужный этап вовремя — это отдельная головная боль, разобранная в материале о том, почему менеджеры не вносят данные в CRM . Мы в итоге ушли от привязки к действиям менеджера — систему настроили так, что она сама выгружает все звонки по клиенту с уникальными идентификаторами и смотрит контекст предыдущих разговоров перед тем, как оценить последний. Про то, как это устроено технически на стороне речевой аналитики целиком — отдельный разбор в «Контроль качества звонков без ОКК» . Вывод с этой конкретной планёрки простой: прежде чем доверять оценке ИИ по звонкам, проверьте не модель, а трубу, по которой в неё льются данные. Обрезанный лимитом транскрипт и гуляющая от прогона к прогону оценка — не повод отказываться от речевой аналитики. Это повод не запускать её на всех менеджеров сразу, пока дельта между машиной и человеком не посчитана хотя бы на паре месяцев данных. Как эта труба устроена целиком, узел за узлом, — в разборе механики контроля качества звонков . Мы пока эту дельту считаем. Чем кончится — расскажем отдельно. И вот что я считаю главным во всей этой истории. Умение спросить у автоматики «а весь ли текст ты вообще видела» — это теперь навык руководителя, такой же обычный, как умение прочитать отчёт о деньгах. Раньше хватало доверия к подрядчику и к красивому интерфейсу. Сейчас тот, кто умеет проверить трубу с данными, стоит дороже того, кто умеет только требовать отчёт. Как замкнуть петлю «оценка → разбор → изменение» — в бесплатном курсе . И короткий чек-лист для вас: проверьте лимит ячейки, в которую складываются расшифровки; проверьте, доходят ли оценки до разбора с менеджером; проверьте, кто в вашей компании отвечает за то, чтобы по этим оценкам что-то менялось. Три проверки, полчаса времени — и вы будете знать, работает ваша аналитика или просто крутится. Мы месяцы платили за аналитику, которая исправно работала и никому не помогала. Не повторяйте мой заход: начните сегодня с лимита ячейки.

## Речевая аналитика на практике: 7139 оценок, $300 в месяц — и один отзыв
URL: https://davidgerstein.pro/blog/kontrol-kachestva-zvonkov-ii/
Дата: 2026-08-15
Направление: Контроль качества
Цифры: 7139 оценок · $300/мес · 1 отзыв
Коротко: Конвейер на нейросети оценивает 100% звонков — 7139 за месяц — за $300, дешевле любого ОКК. Но за весь период руководители оставили один отзыв на оценки, и без еженедельного разбора эффект в деньгах равен нулю. При обороте 9 млн ₽/мес и 10% зависающих из-за звонка сделок риск оценивается в ≈900 000 ₽/мес — и конвейер сам по себе его не снижает.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько разговоров ваших менеджеров с клиентами вы слышали за последний месяц? Скорее всего, ноль. И это нормально: у директора есть занятия поважнее. Ненормально другое — что их не слышал вообще никто, включая руководителя отдела. Если вы прямо сейчас не можете назвать, сколько разговоров разобрали в вашем отделе на прошлой неделе и что после этого изменилось, — контроля качества у вас нет. Есть ощущение контроля. Разница между этими двумя состояниями стоит денег, и ниже я посчитаю, сколько именно. Несколько месяцев назад я поставил в отделе продаж конвейер, который слушает все сто процентов звонков и оценивает каждый по чек-листу. Это разбор работающей системы, а не обзор сервисов: реальные цифры, устройство, промт — и главный вывод, который дороже всей технической части. На седьмой тысяче оценок я понял, что построил дорогую бессмыслицу. Вот это, честно говоря, полезнее всего остального. Сколько стоит речевая аналитика на нейросети Оценка всего потока разговоров обходится около $300 в месяц : за период машина поставила 7 139 оценок там, где вручную закрывалось четверть звонков. Это дешевле одной ставки контролёра. Но цена — не главный вопрос. За тот же период руководители оставили один отзыв на все 7 139 оценок. Контур, чьи результаты не превращаются в решения, стоит ровно $300 в месяц и не приносит ничего. Цифры Конвейер оценивает 100% звонков отдела — 7139 за отчётный период, около 177 в день, — и стоит около $300 в месяц. Это дешевле одного дня работы штатного контролёра качества. Но за тот же период руководители оставили на оценки ровно один отзыв, и это число говорит о системе больше, чем все остальные. Показатель Значение Оценено разговоров за период 7139 Средний темп ~177 разговоров в день Себестоимость обработки ~$300 в месяц Охват 100% звонков, а не выборка Отзывов от руководителей на оценки 1 (один) за весь период Последняя строка — самая важная в этой таблице. К ней и придём. Как устроен конвейер Описываю подробно, чтобы вы могли прикинуть, что из этого есть у вас, а чего не хватает. Ничего экзотического в схеме нет — она собирается из того, что уже стоит в большинстве компаний. Схема воспроизводима в любой CRM с телефонией: запись → расшифровка → оценка по чек-листу → агрегация в дашборд. Три технических этапа и один управленческий, который в нашем случае так и не заработал. Каждый узел этой цепочки разобран отдельно — выгрузка, транскрибация, чек-листы, калибровка и экономика контроля . Записи звонков из телефонии складываются в хранилище. Первый этап — расшифровка: речь в текст, с разделением по говорящим. Второй — оценка: языковая модель получает расшифровку и чек-лист (приветствие, выявление потребности, работа с возражением, следующий шаг — у вас будет свой) и возвращает структурированную оценку с цитатами. Третий — агрегация: оценки складываются в базу, руководитель видит сводку по менеджерам и может провалиться в конкретный разговор. Что важно из неочевидного: Не экономьте на расшифровке. Ошибки распознавания речи умножаются на этапе оценки: модель уверенно оценивает то, чего человек не говорил. Дешёвая расшифровка — главный источник несправедливых оценок, а несправедливая оценка — самый быстрый способ настроить менеджеров против системы. Чек-лист должен быть короче, чем хочется. Пять-семь пунктов, по которым возможен однозначный ответ. Пункты вида «менеджер был доброжелателен» порождают споры, пункты «менеджер назвал следующий шаг и дату» — нет. Оценка обязана цитировать. Каждый балл — с цитатой из разговора. Без цитат разбор превращается в спор с роботом. Отдельный вопрос — хранение. Записи и расшифровки 7139 звонков в месяц — это не просто база для оценки, а полноценный архив разговоров с клиентами, к которому со временем накапливаются вопросы доступа: кто может слушать записи, сколько они хранятся, кто отвечает за их удаление по истечении срока. Мы решили это заранее — доступ к аудио есть только у руководителя отдела и у самого менеджера по его звонкам, доступ к текстовым оценкам — шире, у коммерческого директора. Если этот вопрос не закрыть на старте, он всплывёт в худший момент — когда записи понадобятся для разбора конфликтной ситуации с клиентом, а выяснится, что их уже удалили по умолчанию через 30 дней. Промт: как модель оценивает звонок Вся оценка держится на одном промте, который получает расшифровку и чек-лист и возвращает структурированный JSON с баллом, цитатой и флагом риска по каждому пункту — без этого промта дальнейшая агрегация не имеет смысла, и его можно скопировать целиком. В нашей связке источник данных — amoCRM. После завершения звонка прилетает вебхук примерно такого вида: Сервис скачивает запись, прогоняет через распознавание речи с разметкой по говорящим и подставляет расшифровку в промт ниже вместо плейсхолдера {transcript} . Пример ответа модели на реальный (обезличенный) звонок: risk_flag — единственное поле, ради которого весь промт и затевался: это фильтр, по которому руководитель может за минуту отсортировать 7139 звонков и открыть только проблемные, не слушая остальные. Что выводить на дашборд, чтобы им реально пользовались Здесь вы можете сэкономить себе месяц: дашборд, который никто не открывает, — самый частый результат таких проектов. Правило простое: если вашему руководителю отдела нужно больше двух кликов, чтобы понять, что делать сегодня, — вы построили витрину, а не инструмент. Дашборд должен отвечать на один вопрос за один взгляд: «кого разбирать на этой неделе» — а не превращаться в ещё один отчёт, который открывают раз в квартал перед советом директоров. Мы ошиблись именно здесь: изначально вывели общий средний балл по отделу и красивый график динамики, но ни то, ни другое не подсказывает, что делать в понедельник утром. Рабочий минимум — четыре виджета: количество звонков с risk_flag: true за неделю по каждому менеджеру; топ-3 худших звонка недели со ссылкой на аудио и цитатой из оценки; доля выполнения по каждому пункту чек-листа отдельно (не общий балл, а именно «выявление потребности — X%», «следующий шаг — Y%»), потому что общий балл смешивает разные проблемы в одно число и прячет, что именно чинить; и счётчик «дней с последнего разбора» — простая метрика-триггер, которая делает пропуск ритуала заметным, а не тихим. Именно последний счётчик, если бы он у нас стоял на видном месте с первого дня, вероятно, не позволил бы месяцу тишины остаться незамеченным. Инженерная обвязка: очередь, ретраи, деньги Настройка конвейера заняла около 20 часов: 8 часов — распознавание речи и хранение записей, 8 часов — промт и тестирование чек-листа на живых звонках, 4 часа — интеграция с amoCRM и вывод результатов в таблицу (оценка). ASR и хранение записей 8 ч Промт и тест чек-листа 8 ч Интеграция с amoCRM 4 ч Из невидимого снаружи, но важного для устойчивости: очередь на обработку звонков должна переживать пиковые часы без потерь, а на сбои ASR и модели нужны ретраи с ограничением попыток (у нас — три), иначе часть звонков молча выпадает из статистики и руководитель видит неполную картину, даже не подозревая об этом. Второй момент — лимиты запроса: модель вызывается на каждый звонок отдельно, и при росте штата стоимость растёт линейно, а не скачками, что как раз и держит счёт в районе $300 при нынешнем объёме. Третий момент, который мы недооценили на старте, — длинные звонки. Разговор на 40–50 минут не помещается в один запрос к модели целиком без потери качества оценки: расшифровку приходится резать на смысловые куски и оценивать чек-лист по всей склейке, а не по последнему фрагменту. Решение простое — отправлять модели полную расшифровку, но с явным указанием в промте оценивать разговор целиком, а не последнюю реплику; в этом и есть весь фокус, специальная логика разбиения не потребовалась. Экономика Сравнивайте не с нулём, а со своей текущей ситуацией: сколько у вас стоит человек, который слушает четверть потока, и во что обходится один сорванный контракт, который никто не услышал вовремя. Настройка обошлась примерно в 20 часов работы, эксплуатация — около 27 000 ₽ в месяц (доллары по текущему курсу), а фактический эффект в деньгах за всё время работы — 0 ₽, потому что оценки никто не разбирал с менеджерами. При 7139 оценённых звонках это около 3,8 ₽ за звонок — конвейер сам по себе дешёвый, вопрос не в нём. Возьмём отдел из 8 менеджеров при обороте 9 млн ₽ в месяц и среднем чеке 180 тыс. ₽ — это около 50 сделок в месяц. Если 10% зависает именно из-за плохо отработанного звонка (не назначен следующий шаг, проигнорировано возражение), это 5 сделок и риск ≈ 900 000 ₽ в месяц (оценка). Конвейер этот риск сам не снижает — он только помечает флагом, в каких из 7139 звонков риск есть. Снижает риск разбор: 30 минут в неделю с каждым из 8 менеджеров — это около 16 часов управленческого времени в месяц при ставке руководителя ~1500 ₽/час, то есть 24 000 ₽ в месяц. Это на порядок дешевле риска в 900 000 ₽, но требует ритуала, которого у нас не было. Что мы не считаем эффектом: раньше звонки слушали выборочно и время на это никто не фиксировал — «экономию» этой ручной практики в деньгах мы не пересчитываем, потому что это просто исчезнувшее действие, а не высвобожденные часы сотрудника. Если разбор всё же заработает и повлияет на конверсию, сдвиг даст связка ИИ-оценки и управленческого ритуала целиком — вклад одной только модели отдельно выделить будет нельзя. Почему это не окупилось — честная часть Главный вывод Речевая аналитика не окупается не потому, что нейросеть плохо оценивает. Она не окупается, потому что результаты никто не разбирает. Ритуал разбора — еженедельный, обязательный, с конкретными разговорами — проектируется до запуска системы, и у него должен быть владелец. Если владельца нет, не тратьте деньги на технологию. Система оценивает 177 разговоров в день. Раньше выборочно слушали единицы. Казалось бы — прорыв. Но за весь период работы руководители оставили на оценки один отзыв, а калибровка критериев (совместный разбор спорных оценок, поправки в чек-лист) оборвалась через месяц. Оценка звонка меняет что-то в одном-единственном случае: когда руководитель садится с менеджером и разбирает конкретный разговор. Этот ритуал не был спроектирован. Все считали, что достаточно дать доступ к экрану с оценками. Недостаточно: у руководителя есть текущая работа, и новый экран сам в неё не встраивается — про эту же ловушку я писал в разборе того, почему внедрение ИИ не приживается , там она общая для любых инструментов, не только для звонков. Отдельно стоит сказать про сопротивление менеджеров, которое почти всегда возникает на старте таких систем и которое мы недооценили. Первая реакция — не «удобно», а «меня теперь слушает робот». Это снимается только практикой: если оценки первое время используют исключительно для наказаний, саботаж гарантирован; если первые недели показывают, что оценка помогает получить конкретный совет («на этом месте стоило спросить про бюджет») — сопротивление проходит за 2–3 недели. У нас этой фазы толком не было, потому что не было и самих разборов — отсюда и один отзыв за весь период вместо постепенного привыкания. Считать ли это провалом Отвечу так, как ответил бы вам за столом: технически — нет, управленчески — да. И если вы будете строить у себя похожий контур, я бы хотел, чтобы вы вынесли отсюда именно эту часть, а не цифры про охват. Технически — нет: конвейер стабилен, дёшев и точен. Управленчески — да: он несколько месяцев производил оценки, которые никто не читал. Разрыв между «технология работает» и «люди работают по-другому» — это самая частая причина того, что цифры из отчёта не превращаются в деньги; о том, как вообще правильно считать эффект ИИ-проектов, чтобы не путать поток с разовым запасом, я подробно писал в отдельном разборе про окупаемость ИИ-проектов . И вот что я вынес для себя лично. Довести машинную оценку до разговора с живым человеком — это отдельный навык руководителя, такой же осваиваемый, как чтение отчёта о прибылях. Раньше он не требовался: данных о работе людей было мало, добывались они вручную и поштучно. Теперь данных больше, чем управленческого времени, и руководитель, который умеет превращать поток машинных оценок в еженедельные решения, стоит дороже руководителя, который умеет только раздавать задачи. Я этим навыком в тот момент не владел — и никакая настройка промта этого не компенсировала. Я публикую этот разбор именно потому, что таких историй в открытом доступе почти нет — все продают кейсы успеха, и у читателя складывается ощущение, что у всех работает, а у него одного нет. Не у всех. Чек-лист на понедельник, если хотите повторить Порядок для вас — с поправкой на мою ошибку: приёмку ставим первой, а не последней. Сначала договоритесь с руководителем отдела: полчаса в неделю на разбор трёх худших и одного лучшего разговора. Письменно, с датой первой встречи. Только потом стройте конвейер — иначе получите точную систему без единого пользователя. Первую неделю оценивайте вручную вместе с системой — это калибровка чек-листа и прививка доверия к оценкам. Показывайте менеджерам их собственные оценки сразу: система, которую от людей прячут, воспринимается как слежка и саботируется. Раз в месяц пересматривайте чек-лист: продажи меняются, критерии отстают. Назначьте владельца ритуала разбора — не «руководитель отдела в целом», а конкретный человек с этим пунктом в еженедельном плане. Поставьте на дашборд счётчик «дней с последнего разбора» — если он есть на видном месте, месяц тишины заметят раньше, чем через месяц. Стоимость всей затеи — сотни долларов в месяц, а не миллионы на проект. В деньгах это доступно любому среднему бизнесу; в дисциплине — не любому. Дисциплина и есть цена. Если после этой статьи вы сделаете одну вещь — пусть это будет не запуск контура, а простой вопрос руководителю отдела продаж: «сколько звонков ты послушал на прошлой неделе и что после этого изменилось?». Ответ покажет, нужна ли вам вообще автоматика или сначала нужна управленческая привычка. Потому что машина, как выяснилось на моём опыте, отлично производит оценки — и совершенно не умеет заставлять людей ими пользоваться. Это по-прежнему ваша работа. Как выстроить и то и другое — в бесплатном курсе для руководителей .

## Контроль отдела продаж: как ввести прослушку звонков и не потерять команду
URL: https://davidgerstein.pro/blog/kontrol-zvonkov-bez-sabotazha/
Дата: 2026-07-30
Направление: Контроль качества
Цифры: цена ошибки сопоставима с годовым бюджетом отдела · 10%→100% охват звонков · 66 звонков на калибровке
Коротко: Контроль отдела продаж вводят не запуском системы на всех сразу, а через калибровочную сессию с каждым менеджером и три месяца параллельной работы ИИ-оценки с ручной — пока дельта отклонений, проверенная на 66 звонках, не станет предсказуемой. Цена одной пропущенной ошибки контроля может достигать величины, сопоставимой с крупным годовым бюджетом компании, поэтому без этого этапа менеджеры саботируют систему, не веря в её объективность — и часто справедливо.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Любой контроль сотрудники встречают одинаково: соглашаются вслух и обходят на практике. Если вы слушаете десятую часть звонков и по ней судите обо всём отделе продаж — у вас нет контроля качества. У вас есть выборка, которая вас успокаивает. Разбираю, как выстроить контроль отдела продаж так, чтобы это не превратилось в тихую войну. Стоимость одной ошибки в контроле качества может достигать величины, сопоставимой с крупным годовым бюджетом компании — на одном клиенте. При этом отдел контроля в лучшем случае охватывает 25% работы бизнеса — не потому что люди плохо работают, а потому что человек физически не прослушает весь поток звонков. Отсюда соблазн отдать контроль отдела продаж нейросети — и слушать не выборку, а весь поток. И отсюда же начинается сопротивление: менеджеры не хотят, чтобы их оценивал алгоритм, логику которого им никто не объяснил. Я видел, как это внедрение проваливается, и видел, как оно получается. Разница не в модели и не в бюджете на API. Разница в том, дали ли менеджерам увидеть, как система принимает решения, до того как решения системы стали влиять на их зарплату. Я сам в первый раз полез сначала в технику — конвейер, промпты, выгрузки — и только потом пошёл разговаривать с людьми. Порядок был неверный, и месяц ушёл на то, чтобы отыграть назад. Так что дальше я пишу не с позиции «делайте правильно», а с позиции человека, который это уже переставлял местами. Как ввести контроль отдела продаж без саботажа Контроль отдела продаж вводят в три такта и строго в этом порядке: сначала разговор с командой, потом письменные правила оценки, и только потом техника. Объявите, что именно меряется, зачем и что будет с результатами — пятнадцать минут честного объяснения экономят месяцы тихого саботажа. Ключевой приём — прозрачность оценки: показывайте цитату из разговора рядом с каждым баллом. Когда человек видит, за какую фразу снижен балл, спорить не с чем: можно только согласиться или объяснить контекст. Ориентир по срокам: калибровочная сессия с каждым менеджером до запуска, выборка от 50–70 звонков на сверку оценки ИИ с ручной и три месяца, когда оба контура работают параллельно, — до этого решения о премиях по автоматической оценке не принимают. Контроль отдела продаж — не слежка за сотрудниками Разница не в жёсткости, а в предмете замера. Слежка меряет человека: скриншоты экрана, трекеры активности, счётчики нажатий клавиш — то есть присутствие. Контроль отдела продаж меряет работу: как прошёл разговор с клиентом, отработано ли возражение, соблюдён ли регламент. Первое ваш сотрудник улучшить не может — он может только имитировать занятость. Второе может, и в этом весь смысл: у оценки есть чек-лист, который менеджер видит и вправе оспорить. Если ваша система не даёт человеку посмотреть, за что ему поставили балл, вы построили слежку и получите ровно то сопротивление, о котором ниже. Почему ваши менеджеры сопротивляются Три причины, и ни одна из них не «им есть что скрывать». Первая причина — оценка нейросети не всегда стабильна. Это не жалоба менеджера, это признание руководителя отдела, который сам внедряет систему: «Оценка, она не всегда адекватна». Один и тот же звонок при повторной обработке может получить разный результат. Если система колеблется сама с собой, доверять ей вслепую — значит плодить конфликты, а не снимать их. Вторая причина — менеджер не понимает, что именно оценивают и по каким данным. Показательный случай из смежной аналитики переговоров: менеджер по продажам не мог разобраться, у кого сколько договоров выставлено и откуда пришли клиенты. Его фраза точно описывает состояние человека перед внедрением любого контроля: «Я не могу с этим работать, я не понимаю, у кого сколько договоров выставлено, что это за клиенты». Когда человек не видит собственных данных в понятном виде, он не поверит и оценке своей работы — даже честной. Третья причина — необъяснённые сбои в системе учёта, которые совпадают по времени с внедрением контроля. В одном случае клиенты видели в списке посещений свои фамилии рядом с именем чужого менеджера. Причину так и не нашли. Это не про чью-то вину — это про то, что необъяснённая несостыковка разрушает доверие к любой автоматике быстрее, чем самая жёсткая, но понятная оценка. Правило Система, которая не может объяснить свою логику менеджеру, не получит от него сотрудничества. Она получит либо саботаж, либо формальное подчинение без реальной помощи в донастройке чек-листов. Как внедрить контроль отдела продаж: механика по шагам Ваш первый шаг вообще не про систему: это встреча с командой, на которой вы объясняете, что и зачем будете мерить. Порядок для вас: сначала разговор, потом правила, и только потом техника. Любая перестановка даёт саботаж. Ниже — последовательность, которую можно повторить с любой командой продаж, не привязываясь к конкретной CRM. Меняется инструмент, логика — нет. Источник данных. Звонки и записи встреч выгружаются из CRM (в фактуре — Bitrix24) в единое хранилище: Google Drive или отдельный бакет. Триггер выгрузки — заполнение обязательного поля с аудиозаписью на этапе сделки «встреча проведена». Без этого триггера система либо ловит холостые звонки, либо пропускает нужные. Транскрибация. Аудио прогоняется через сервис распознавания речи, текст сохраняется отдельно от таблицы с оценками — полный текст в Drive, в таблице только ссылка. Это защита от обрезания транскрипта лимитом ячейки, о которой ниже. Классификация звонка. Дешёвая модель определяет тип разговора: первичный звонок лида, звонок продаж, вторичный контакт и так далее — всего в практике встречается до 10 сценариев, под каждый свой чек-лист. Оценка по чек-листу. Дорогая модель получает транскрипт, тип звонка и релевантный чек-лист, выставляет оценку по каждому пункту, определяет менеджера по имени в записи. Свод результатов. Оценки собираются в личный кабинет руководителя продаж — сводная таблица по менеджерам, дельта отклонений от ручной проверки, алерты о нарушениях регламента (например, превышение времени молчания). Разбор. Руководитель раз в неделю смотрит проблемные зоны по чек-листу, раз в месяц — калибрует систему на конкретных звонках с менеджерами. Всё в этой цепочке держится на шаге 1. Если триггер выгрузки зависит от того, переведёт ли менеджер сделку на нужный этап вовремя, система будет захватывать не все звонки. Заставлять менеджеров быть дисциплинированнее — плохое решение. Правильное — сделать поле с аудиозаписью обязательным для перехода на следующий этап сделки, тогда дисциплина встроена в саму CRM, а не держится на памяти человека. Похожая логика разбиралась в материале о том, как менеджеры не вносят данные в CRM без репрессий. ИИ-связка: конвейер, промпт и обвязка Технику показываю коротко: в вашем случае она вторична, главное — то, как вы её объявите команде. Кому инженерная часть нужна подробно — устройство контура целиком: выгрузка, расшифровка, чек-листы, экономика . Схема конвейера в текстовом виде: CRM (Bitrix24) — выгрузка звонка по триггеру Хранилище (Drive) — аудио + полный транскрипт Дешёвая модель — классификация типа звонка Дорогая модель — оценка по чек-листу Таблица + кабинет — свод, дельта, алерты На шаге классификации ставится дешёвая модель — задача простая (определить один из 10 типов звонка по первым репликам), переплачивать за неё дорогой моделью бессмысленно. На шаге финальной оценки по чек-листу — дорогая модель: там нужно удерживать контекст всего разговора, включая предыдущие звонки с этим же клиентом, и не терять нюансы тона и возражений. Пример промпта для второго шага — оценки встречи по чек-листу. Платформа — Google Apps Script, который вызывает API модели и пишет результат обратно в Google Таблицу, откуда его забирает личный кабинет руководителя. Пример ответа модели: Инженерная обвязка. Скрипт крутится по расписанию (триггер Apps Script раз в час), забирает список звонков из Bitrix24 REST API за период, где заполнено поле аудиозаписи и ещё нет оценки. При ошибке вызова API (лимит, таймаут, пустой транскрипт) скрипт не падает молча — пишет статус в отдельную колонку и шлёт алерт в тот же Telegram-бот, который уже используется для оповещений о задержках ответов менеджеров. Повторный запуск — по следующему тику расписания, без ручного вмешательства. Отдельно логируется стоимость каждого вызова API — это тот же контур, что описан в материале о том, сколько реально стоит ИИ в месяц , включая ночь с циклическим запросом на заметную для месячного бюджета сумму из-за бага в коде — ошибка, которая случилась именно на этапе отладки такого пайплайна. Калибровочная сессия: снимаем сопротивление заранее Час вашего времени, который экономит месяцы. Сажаете команду и вместе оцениваете три записи по чек-листу — расхождения обсуждаете сразу. Работающий приём — калибровочная сессия с каждым менеджером до массового запуска. Руководитель разбирает одну конкретную встречу: показывает автоматическую оценку, показывает чек-лист, по которому она выставлена, и вместе с менеджером обсуждает, где они согласны, а где нет. Это не оправдание системы перед сотрудником — это способ получить от менеджера расхождения, которые лягут в донастройку промпта и чек-листа. Менеджер видит: его не наказывают анонимным алгоритмом, а спрашивают его мнение как эксперта. Из объекта контроля он становится соавтором чек-листа — и это ровно та грань, которая отделяет внедрение с поддержкой команды от внедрения, которое тихо саботируют. Стандарты обслуживания нужны раньше алгоритма Калибровка не работает, если стандарты обслуживания не сформулированы заранее. Нельзя оценивать звонок по критериям, которые никто не проговорил вслух. В одном случае отделу продаж и сопровождения поручили совместное совещание, чтобы выработать единую коммуникационную стратегию — как одинаково информировать клиентов о задержках, чтобы не получился «сломанный телефон» между отделами. Пока стандарт живёт в голове каждого менеджера по-своему, любая автоматическая оценка воспринимается как произвол. Проверка методологии: 66 звонков Ваш ориентир по объёму выборки: несколько десятков звонков достаточно, чтобы увидеть системные расхождения. Отдельная категория проблем — не человеческая, а методологическая. Прежде чем масштабировать оценку на всех менеджеров, по каждому звонку фиксируется, как его оценила нейросеть и как оценил человек из отдела контроля качества, и считается дельта отклонения. За месяц набралось 66 звонков с ручной оценкой параллельно с автоматической. Это не недоверие к ИИ ради недоверия — это способ понять, где система систематически ошибается, до того как её результат станет основанием для решений о зарплате или увольнении. Так выглядит фрагмент кабинета руководителя, куда стекаются результаты конвейера — с реальным примером звонка из промпта выше: Кабинет руководителя отдела продаж 66 звонков в выборке дельты 3 мес двойного контроля 10 чек-листов по типам звонков Звонок Менеджер Оценка ИИ Нарушение Статус CR-10452 Иванов И.И. 62 молчание 41 сек … … … без нарушений Руководитель, который отвечает за стратегию автоматизации, формулирует условие жёстко: «Я не готов автоматизировать контроль качества, потому что я не понимаю, работает ли методология, и я не понимаю, сколько это будет стоить. Пока нет цифр, пока нет доказанной эффективности, я не готов». Это здоровая позиция, а не перестраховка. Подробный разбор того, что стоит проверять до полного доверия автоматической оценке звонков, я делал отдельно — 7139 оценок и $300 в месяц: честный отзыв о системе . Три месяца двойной работы — это не потеря, а страховка Практика, которая повторяется в разных внедрениях: систему запускают не менее чем на три месяца параллельно с ручным контролем. Это значит двойной расход бюджета на этот период — платите и за ИИ-оценку, и за штат контроля качества одновременно. Неприятно, но альтернатива хуже: отключить ручной контроль раньше и начать принимать решения по людям на основе методологии, которая ещё не проверена. Этап внедрения Что происходит Риск, если пропустить Калибровочная сессия Разбор одной встречи с менеджером, сверка оценки ИИ и мнения человека Менеджеры саботируют систему как «чёрный ящик» Параллельная оценка (66+ звонков) Сравнение оценки ИИ и ручной, расчёт дельты Решения о людях принимаются на непроверенной методологии 3 месяца двойного контроля Оба контура работают одновременно, бюджет на период удваивается Раннее отключение ручного контроля скрывает системные ошибки ИИ Полное развёртывание 100% охват звонков, сокращение штата контроля качества Без предыдущих этапов — повтор истории про потерю крупной суммы на одной ошибке На диаграмме — рост охвата контроля после внедрения речевой аналитики: было 10% вручную (нижняя граница диапазона 10–25%, в который упирается ручной контроль), план — 100%. 10% было 100% план Выборочные 10% звонков вручную — против 100% охвата с речевой аналитикой на нейросетях (данные из практики внедрения). Ловушки, похожие на саботаж Прежде чем обвинять людей, проверьте технику: у нас часть «нарушений» оказалась сбоями записи. Часть сопротивления менеджеров на самом деле вызвана не недоверием к идее, а конкретными техническими сбоями, которые система выдаёт за «объективную оценку». Транскрибация обрезалась из-за лимита символов в ячейке Google-таблицы. ИИ оценивал неполный текст звонка и выносил вердикт по обрубленной версии разговора. Решение простое: в таблицу кладут короткий фрагмент и ссылку на полный текст, который открывается отдельно. Система не всегда понимает, какой именно звонок нужно оценивать в цепочке взаимодействий с клиентом: «Проблема любой АИ, которая связана с любой CRM, заключается в том, что как система должна понять, что это именно тот звонок, который нужно оценить». Первый звонок может быть холостым, следующий — система не захватывает, менеджер не всегда переводит сделку на нужный этап. Решение оказалось не в дисциплине менеджеров, а в инженерии: автоматическая выгрузка всех звонков из CRM с уникальными ID — сущность, менеджер, время. Триггером для выгрузки встречи служит заполнение обязательного поля с аудиозаписью на этапе «встреча проведена». Систему заставили анализировать контекст предыдущих звонков с тем же клиентом, а не оценивать разговор в вакууме. Ещё один нюанс: готовых коробочных решений, которые сами сегментируют тип звонка и подключают к каждому типу отдельный промпт, на рынке нет. В разбираемой практике используется 10 разных чек-листов под разные сценарии — первичный звонок лида, звонок продаж, вторичный контакт. Это не разовая настройка, а живой процесс: внедрение шло уже четвёртый месяц и требовало постоянных доработок. Похожая история — про автоматизацию, которая требует постоянного надзора: контроль качества звонков из той же породы решений. Где ломается Любая автоматическая оценка звонков спотыкается на стыке с CRM: система не знает, какой звонок оценивать, если менеджер не переводит сделку по этапам вовремя, и не знает, что оценивает обрезанный текст, если транскрипт превышает лимит ячейки таблицы. Чинить это дисциплиной менеджеров бесполезно — чинить нужно инженерией: уникальные ID звонков, обязательные поля-триггеры, вынос полного текста за пределы таблицы. Экономика: что это стоит и что даёт вам Считайте не только деньги: главные ваши затраты здесь — время на разговоры с командой, и они окупаются лучше всего. Возьмём условную компанию из легенды этого разбора: отдел из 15 менеджеров, оборот ~18 млн ₽/мес, средний чек ~90 000 ₽. Это не цифры реального клиента из фактуры, а модельный расчёт для формулы — подставьте свои значения и получите свою оценку. Формула 1. Сколько стоил бы ручной контроль при 100% охвате. (число звонков в месяц) × (минут на разбор одного звонка) ÷ 60 × (ставка контролёра в час) = стоимость полного ручного контроля в месяц. Подставляем: 15 менеджеров × 20 звонков/день × 22 рабочих дня ≈ 6 600 звонков в месяц. Разбор одного звонка с занесением в чек-лист занимает у контролёра в среднем 10–15 минут — возьмём середину, 12,5 минуты. Итого: 6 600 × 12,5 ÷ 60 ≈ 1 375 часов в месяц. При типовой ставке контролёра качества ~1 000 ₽/час (оценка) это выливается в сумму около 1 375 000 ₽ в месяц — эквивалент почти девяти штатных контролёров, работающих полный день, только на то, чтобы прослушать входящий поток. Именно поэтому на практике отдел контроля физически ограничивается 10–25% потока — не от лени, а потому что 100%-й ручной охват для такого объёма экономически нерентабелен без кратного расширения штата. Формула 2. Цена пропущенной ошибки. (поток контактов в месяц) × (доля, конвертирующаяся в сделку) × (доля сделок, которые портит необнаруженная ошибка в скрипте) × (средний чек) = упущенная выручка в месяц. Подставляем консервативно: 6 600 контактов × 3% конверсии в сделку (оценка, отраслевая усреднённая, в вашем случае может быть выше или ниже) ≈ 198 потенциальных сделок в месяц — это близко к фактическому объёму сделок легендированной компании: заявленный оборот ~18 млн ₽/мес при среднем чеке ~90 000 ₽ даёт те же ~200 сделок. Если необнаруженная вовремя ошибка в скрипте (пропущенное возражение, нарушенный регламент) портит всего 2% из них — это 4 сделки на средний чек 90 000 ₽, то есть около 360 000 ₽ упущенной выручки в месяц (оценка, зависит от реальной конверсии и цикла сделки). Это тот порядок величины, который стоит за фразой «сотни тысяч рублей риска» — не абстракция, а расчёт с консервативными допущениями. Формула 3. Экономия на ФОТ после автоматизации. (число высвобождаемых ставок) × (часы полной занятости в месяц) × (ставка в час) = экономия ФОТ в месяц. В разбираемой практике после настройки автоматической оценки планируют отказаться минимум от двух штатных единиц отдела контроля качества. Подставляем: 2 ставки × ~160 часов/мес × 1 000 ₽/час ≈ 320 000 ₽ экономии ФОТ в месяц (оценка). Это то, что раньше уходило на ручное прослушивание выборки в 10–25% звонков; конкретная сумма экономии компании из фактуры напрямую не раскрывается, это расчётная величина при указанных допущениях. Формула 4. Что съедает экономию — стоимость самого ИИ-контура. Эксплуатация ИИ-контура не бесплатна. В похожем по объёму проекте (7139 оценок в месяц) она составляла порядка $300/мес на инфраструктуру и вызовы моделей — цифра из другого кейса, не из текущего расчёта напрямую, но как ориентир масштаба полезна. В рублях (~27 000 ₽/мес по курсу ~90 ₽/$) это около 2% от стоимости полного ручного контроля (1 375 000 ₽) и заметно меньше экономии ФОТ по формуле 3. Даже если удвоить эту сумму на риск нештатных расходов, она остаётся на порядок меньше высвобождаемого ФОТ — окупаемость по грубой прикидке достигается в первый же месяц эксплуатации, если методология уже прошла проверку дельтой. Отдельно стоит закладывать риск разовых инцидентов: у меня циклический запрос из-за бага в коде за одну ночь обошёлся в сумму порядка нескольких тысяч рублей. Это моя недоработка: я не поставил потолок расходов на контур, прежде чем оставить его работать без присмотра. Сумма небольшая — примерно как один рабочий день контролёра качества, — но именно она заставила пересмотреть готовность системы к продакшену без мониторинга расходов. На диаграмме ниже — сопоставление денежных порядков этих четырёх формул: во сколько раз риск ошибки и экономия ФОТ меньше стоимости полного ручного контроля, и насколько дёшева на этом фоне сама эксплуатация ИИ-контура. Ручной контроль 100% потока 1 375 000 ₽ — базовый уровень Риск пропущенной ошибки ~360 000 ₽ (~26% от базового) Экономия ФОТ после ИИ ~320 000 ₽ (~23% от базового) Эксплуатация ИИ-контура ~27 000 ₽ (~2% от базового) Оценка для типового отдела из 15 менеджеров по формулам выше — не факт из отчётности конкретного клиента. Показатель Значение (оценка) Как считали Поток контактов на 15 менеджеров ≈ 6 600 звонков/мес 15 × 20 звонков/день × 22 раб. дня Ручной разбор 100% потока ≈ 1 375 часов/мес 6 600 × 12,5 мин ÷ 60 Текущий ручной охват на практике 10–25% физический предел человеко-часов ОКК Стоимость полного ручного контроля ≈ 1 375 000 ₽/мес 1 375 ч × 1 000 ₽/час Риск пропущенной ошибки в скрипте ≈ 360 000 ₽/мес 6 600 × 3% конверсии × 2% сорванных сделок × 90 000 ₽ Экономия ФОТ после автоматизации ≈ 320 000 ₽/мес 2 ставки × 160 часов × 1 000 ₽/час Эксплуатация ИИ-контура ≈ 27 000 ₽/мес ориентир $300/мес из другого проекта аналогичного объёма Риск нештатных расходов от нескольких тысяч рублей за инцидент кейс: циклический запрос из-за бага за одну ночь Период двойного бюджета 3 месяца параллельная работа ИИ и ручного контроля до валидации методологии Важная оговорка про смешение эффектов: за пару месяцев из реанимации невключившихся клиентов удалось вытащить сумму, заметную на фоне месячного оборота отдела — это результат отдельной инициативы по повторному контакту с базой, а не самого контроля качества звонков. Смешивать эти два эффекта нельзя: контроль качества снижает риск потери сделок из-за плохого разговора (формула 2 выше), а реанимация — отдельный процесс дожима уже потерянных лидов, у него свой бюджет и своя команда. Вклад именно контроля качества в выручку в фактуре напрямую не измерен и требует отдельного A/B-сравнения после трёх месяцев параллельной работы — до этого момента любые цифры выше остаются оценкой с консервативными допущениями, а не фактом из отчётности. Ваш чек-лист на понедельник Первые два пункта — разговоры, не техника. Сформулировать стандарт обслуживания письменно — на одном совещании отделов продаж и сопровождения, а не по памяти каждого менеджера. Сделать поле с аудиозаписью обязательным для перехода сделки на этап «встреча проведена» — это единственный надёжный триггер выгрузки звонков. Выбрать 2–3 типа звонков для старта (не все 10 сразу) и написать под них чек-листы вместе с руководителем продаж. Запустить параллельный контур: ИИ-оценка + ручная оценка тех же звонков, минимум 50–70 штук для первой выборки дельты. Провести калибровочную сессию с каждым менеджером до того, как оценки начнут влиять на премию. Посчитать свою версию формул выше — с вашим потоком звонков, вашей ставкой контролёра и вашим средним чеком — и зафиксировать бюджет на 3 месяца двойной работы с датой решения: масштабировать, донастраивать или остановить. Контроль отдела продаж — не про то, чтобы поймать менеджера на ошибке. Это про то, чтобы увидеть отдел продаж целиком, а не выборочную четверть. Но когда система в первый раз ошибётся — а она ошибётся, — её будет некому защищать. Разве что тем, кто с самого начала понимал, почему она посчитала именно так. О более широкой картине того, почему технически готовые внедрения буксуют на людях, я писал в материале почему внедрение ИИ не работает — хотя технически всё запустилось . И назову вещь своим именем. Умение объяснить машине, что в вашей компании считается хорошим разговором с клиентом, — это новый управленческий навык, и осваивать его придётся вам, а не подрядчику. Промпт напишут за деньги. Навык руководителя — другое: сформулировать стандарт так, чтобы его одинаково поняли и человек, и модель, а потом выдержать три месяца двойного бюджета, пока дельта на выборке в 66 звонков не станет предсказуемой. Руководитель, который это умеет, видит весь отдел продаж целиком. Руководитель, который не умеет, видит десять процентов звонков и называет это контролем. Разница в цене такого руководителя будет расти каждый год. Ваше первое действие — не настройка системы, а разговор с командой: что меряем, зачем, что будет с результатами. Пятнадцать минут честного объяснения экономят месяцы сопротивления. Как выстроить контроль, который принимают, — в бесплатном курсе для руководителей . И последнее, что стоит вам запомнить: сопротивление снимается не жёсткостью, а прозрачностью. Покажите людям, за что именно им ставят балл, — и спор о справедливости прекращается сам.

## Критерий оценки качества работы в звонке: пять вместо пятидесяти
URL: https://davidgerstein.pro/blog/chek-list-ocenki-zvonka/
Дата: 2026-06-14
Направление: Контроль качества
Цифры: 66 звонков ручной сверки · цена одной ошибки — до 2,4 млн ₽ (оценка) · 25% охват контролем вручную
Коротко: Рабочий критерий оценки качества работы менеджера в звонке — это пять пунктов: тип звонка, соблюдение сроков, соблюдение скрипта, тон коммуникации и фиксация результата в CRM. Пятьдесят пунктов не работают, потому что их не проверяет как следует ни человек, ни ИИ. Ручной контроль закрывает лишь 25% звонков, а цена одной пропущенной ошибки может достигать 2,4 млн ₽ на одном клиенте (оценка).

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас есть чек-лист оценки звонков на пятьдесят пунктов — у вас нет чек-листа оценки звонков. У вас есть документ, который никто не заполняет честно, потому что заполнить его честно физически невозможно. Я через это прошёл. Мы начинали с длинного списка «всё, что важно», и получили ровно то, что получают все: контролёр ставит галочки не глядя, менеджеры считают оценку лотереей, руководитель не может объяснить, почему у одного 7, а у другого 8. Работать начало, когда осталось пять пунктов. Ниже — какие именно и почему. Критерий оценки качества работы: короткий ответ Рабочий критерий оценки качества работы менеджера в звонке — это пять проверяемых пунктов вместо пятидесяти: тип звонка определён верно, соблюдён регламент по срокам, соблюдён скрипт своего этапа сделки, отмечен тон коммуникации и зафиксирован результат в CRM. Каждый из пяти подтверждается цитатой из разговора — поэтому оценка не «гуляет» между прогонами. Пятьдесят пунктов добросовестно не проверяет ни человек, ни машина. Руками контроль закрывает около 25% разговоров, автоматическая оценка по короткому списку — 100% того же потока. Прежде чем убирать людей из контроля, сверьте машину с человеком на выборке в 66 звонков и посчитайте дельту отклонения. Отдел настраивал систему оценки звонков четвёртый месяц. Десять вариантов чек-листов под разные сценарии — первичный звонок, звонок продаж, вторичный контакт, встреча. Каждый месяц — доработки. Не потому что систему делали плохо. Потому что критерий оценки качества работы в звонке — это не строка в документе, а живая настройка, которая ломается на реальных звонках чаще, чем кажется на этапе презентации. Параллельно в другой компании посчитали цену вопроса иначе: стоимость одной пропущенной ошибки в контроле качества может достигать 2,4 млн ₽ на одном клиенте — это примерно 65% его годового контракта на услуги компании (оценка). При этом отдел контроля в лучшем случае прослушивает 25% звонков — не потому что работает плохо, а потому что физически не успевает больше. Это не абстрактный риск. Это разрыв между тем, сколько звонков реально требует проверки, и тем, сколько человек способен проверить руками за смену. Почему ваши пятьдесят пунктов не работают Посмотрите на свой чек-лист и честно ответьте: сколько времени займёт заполнить его добросовестно по одному разговору? Если больше пяти минут — его никто не заполняет добросовестно, включая вашего лучшего сотрудника. Классический чек-лист контроля качества звонков — это лист на пятьдесят строк: поздоровался, представился, уточнил имя, задал открытый вопрос, отработал возражение, предложил альтернативу, поблагодарил, попрощался. Каждый пункт логичен сам по себе. Проблема — в сумме. Человек физически не может держать в голове пятьдесят критериев, слушая живой разговор. Он либо сваливается в формальную галочку («вроде было»), либо тратит на один звонок пятнадцать минут вместо пяти. А 25% охвата вручную — это уже потолок ресурса, а не вопрос качества работы контролёров. В отделах с большей нагрузкой на менеджера этот потолок проседает и до 10% — предел зависит от общего потока звонков и штата контроля, а не от желания людей проверять больше. ИИ формально может оценить все пятьдесят пунктов за секунды. Но это не решает проблему — оно её маскирует. Если критерии размыты, модель по-разному оценивает один и тот же звонок при повторной обработке. «Оценка, она не всегда адекватна» — это не претензия к технологии, это диагноз чек-листу. Пятьдесят нечётких формулировок дают пятьдесят источников погрешности, которые складываются друг с другом. Правило Если чек-лист даёт разные результаты при повторной оценке одного и того же звонка — проблема не в модели, а в формулировках критериев. Сначала переписать чек-лист, потом доверять автоматике. Пять пунктов: рабочий критерий оценки качества работы Сверьте со своим списком. Если у вас нет хотя бы трёх из этих пяти — вы меряете не то, что влияет на деньги. На разных внедрениях всплывает один и тот же короткий список. Не потому что кто-то сознательно урезал критерии до пяти, — потому что именно эти пять реально влияют на деньги и повторяются в каждой рабочей системе контроля. № Критерий Что проверяет 1 Тип звонка определён верно Первичный лид, продажа, вторичный контакт, встреча — от этого зависит, какой чек-лист вообще применять 2 Регламент по срокам Сроки молчания, скорость первого ответа, отсутствие «зависших» диалогов дольше установленного норматива 3 Скрипт по этапу сделки Соблюдение обязательных блоков разговора для конкретного этапа, а не абстрактной «вежливости» 4 Тон и эмпатия Отдельный ежемесячный отчёт по недостаткам деловой коммуникации — не по каждому звонку, а по накопленной картине 5 Фиксация результата Итог звонка записан в CRM: следующий шаг, договорённость, дата повторного контакта Здесь нет пункта «улыбался ли голосом». Есть проверяемые вещи. Тип звонка либо определён, либо нет. Срок молчания либо нарушен, либо нет. Скрипт для этапа либо соблюдён, либо нет. Это бинарные или почти бинарные критерии — именно поэтому ИИ на них не «гуляет» между прогонами. Тон и эмпатия — единственный субъективный пункт, и его сознательно вынесли из потокового контроля в отдельный ежемесячный отчёт, который становится основой для обучения, а не для дисциплинарных решений по каждому звонку. То, что оценивается автоматически и в реальном времени, должно быть проверяемым фактом. То, что требует нюанса, — идёт в накопительную аналитику. Инженерная связка: как машина понимает, какой звонок оценивать Эта часть нужна вам, если вы будете ставить оценку на поток. Если пока оцениваете руками — пропустите, вернётесь позже: сначала должен заработать сам чек-лист, а уже потом его стоит отдавать машине. Как он встраивается в остальной контур, показано в разборе всей системы оценки разговоров целиком — от выгрузки записи до калибровки и отчёта. Прежде чем спорить о критериях, нужно решить более простой вопрос: система вообще должна понять, какой звонок из CRM брать в оценку. Первый звонок клиенту может быть холостым — не дозвонились. Следующий звонок система может не захватить, если менеджер не перевёл сделку на нужный этап. А заставлять менеджеров вручную двигать статусы ради того, чтобы система «увидела» звонок, — путь в саботаж. Рабочая схема конвейера выглядит так (на диаграмме — пять шагов, от вебхука Bitrix24 до финальной оценки чек-листа): 1. Bitrix24-вебхук на смену этапа шаг 1 2. Выгрузка аудио и ID шаг 2 3. ASR-транскрибация шаг 3 4. Дешёвая модель: тип звонка шаг 4 5. Дорогая модель: оценка шаг 5 Для встреч триггером служит заполнение обязательного поля с аудиозаписью на этапе «встреча проведена» — а не ручная отметка «оцени меня». Перед оценкой самого звонка система подтягивает контекст предыдущих контактов с этим же клиентом: иначе оценка вырывает разговор из истории и делает неверные выводы. Похожая проблема с кривыми входными данными разбиралась в статье о том, как CRM врёт с датами — если данные на входе нечестные, никакой чек-лист на выходе не спасёт оценку. Промпт: разделение на дешёвую и дорогую модель Классификация типа звонка — задача с 3–4 вариантами ответа, глубокий контекст не нужен. Для неё хватает дешёвого классификатора — он быстрый и почти не влияет на счёт за месяц даже при полном охвате звонков. Финальная оценка по чек-листу требует понимания контекста разговора, нюансов возражений и связи с предыдущими звонками — здесь оправдана более мощная модель с расширенным окном контекста. Структура входных данных для второго шага (передаётся из Google Sheets, куда предварительно попадают ID звонка, менеджер, тип и ссылка на транскрипт): Пример ответа модели: Так выглядит итоговый отчёт руководителя после полного охвата — не выборка, а поток всех звонков за день: Отчёт: оценка звонков — сегодня 140 звонков за день 100% охват оценкой ID звонка Менеджер Тип Срок Скрипт CRM d-88213 M-07 продажа d-88214 M-03 первичный Инженерная обвязка держится не на скрипте-энтузиасте, а на трёх правилах. Где крутится: серверная часть — 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 рабочих дня — то есть дополнительно три полных ставки в месяц только на то, чтобы прослушивать, без учёта написания отчётов и обучения; в пересчёте на эксплуатацию модели это кратно больше стоимости обработки того же потока звонков автоматикой. Показатель Вручную (25% охват) С речевой аналитикой Звонков в обработке из потока 140/день 35 140 Часы контролёра в день 7 (в рамках смены) не требуется — обработка автоматическая Доп. ставки контролёров для 100% охвата нужно ещё 3 0 Доп. ФОТ в месяц на закрытие разрыва (оценка) ≈3 полных ставки — кратно дороже эксплуатации модели эксплуатационные расходы модели + риск инженерных ошибок (пример — до 35 000 ₽ за одну ночь из-за циклического запроса, оценка) Читателю, который хочет прикинуть свой случай: формула та же — поток звонков в день × минуты на ручную проверку ÷ 60 = часы; часы ÷ длительность смены = недостающие ставки; ставки × часы смены × своя ставка в час × число рабочих дней = ежемесячная стоимость закрытия разрыва руками . Подставьте свои цифры вместо 140 и 12 — порядок величины будет тем же. Если система хотя бы раз за период предотвращает ошибку катастрофического масштаба (по одной из практик — сумму порядка 2,4 млн ₽, около 65% годового бюджета клиента, оценка), это перекрывает многолетние издержки на разработку и эксплуатацию сразу. Но это редкий, единичный кейс, и его нельзя закладывать в среднюю экономику как регулярный эффект — поэтому основной расчёт выше идёт через операционные часы, а не через гипотетическую катастрофу. Речевая аналитика с автоматической классификацией и оценкой снимает потолок ручного охвата: 100% вместо выборочных 25% (в некоторых отделах — вместо 10%), без роста штата контроля. Экономический эффект здесь не в замене одного контролёра ИИ — это отдельный организационный шаг, который в разных компаниях планируют делать поэтапно и после проверки методологии, минимум за 3 месяца параллельной работы. В одной из практик по итогам такого перехода планируют отказаться минимум от двух штатных единиц контроля качества — но это управленческое решение после проверки методологии, а не автоматический результат внедрения чек-листа. Вклад именно чек-листа и оценки — в том, что охват растёт без пропорционального роста затрат на контроль, а не в том, что штат сокращается автоматически в день внедрения. На диаграмме — до и после внедрения речевой аналитики: 25% вручную 100% авто Охват контроля вырос с 25% звонков (35 из 140 в день, проверяемых вручную) до 100% при автоматической оценке — без увеличения штата контролёров. Обратная сторона — эксплуатационные расходы и риск инженерных ошибок. Один из внедрений столкнулся с циклическим запросом из-за ошибки в коде: за одну ночь это обошлось примерно в 35 000 ₽ (оценка). Сумма для месячного бюджета компании небольшая, но именно она стала поводом пересмотреть готовность системы к масштабированию — раз ошибка стоит денег на этапе теста, на проде она стоит больше. Детальный разбор счетов за подобный инструмент — в статье про контроль качества звонков без ОКК . Смешивать эффект этого инструмента с другими мерами — например, с параллельным пересмотром скриптов продаж — не стоит: вклад считается отдельно, иначе экономика получается дутой. Что я понял про сопротивление Когда мы вводили оценку, я ждал спора о критериях. Спора не было — было тихое сопротивление: менеджеры соглашались на планёрке и продолжали работать как раньше. Я разбирался месяц и понял простую вещь: они не верили, что оценка справедлива, и не могли это сказать вслух. Помогла не жёсткость, а прозрачность: мы стали показывать цитату из разговора рядом с каждым баллом. Когда человек видит, за какую именно фразу ему снизили балл, спорить становится не с кем — можно только согласиться или объяснить контекст, и оба варианта нам подходят. Тогда же я понял, чем это на самом деле является. Свести оценку к пяти пунктам, каждый из которых подтверждается цитатой, — это управленческий навык, а не работа контролёра. Руководитель либо умеет назвать пять вещей, за которые он отвечает деньгами, либо прячется за пятьюдесятью и называет это требовательностью. Если вы будете вводить это у себя — заложите на разговоры с командой столько же времени, сколько на настройку. У меня ушло примерно поровну, и я считаю это нормальной пропорцией. Стандарты обслуживания по телефону: что стоит за цифрами Сроки — часть любого чек-листа, но их легко занизить или завысить без реальных данных. В одной компании средний ответ на сообщение клиента — 8 часов, включая нерабочее время и сон, что требует отдельной проверки на честность метрики: если считать только рабочие часы, реальная скорость реакции может выглядеть иначе. Максимальный допустимый срок тишины — две недели, но ответ внутри рабочего дня требуется всегда. Это конкретные, измеримые нормативы — не «отвечать быстро», а число, которое можно проверить автоматически через тот же вебхук, что выгружает звонки. Отдельное правило для повторных касаний: если клиент молчит больше 24 часов после первого контакта — повторное сообщение через 4 часа, а если ответа нет и после этого — прописан следующий шаг сценария (вторая попытка, эскалация), а не открытый разбор без решения. Это тоже часть чек-листа, только не по звонку, а по цепочке коммуникации целиком. Перед тем как убирать людей из контроля, проверьте у себя адекватность самой автоматической оценки. В одном из внедрений за месяц прогнали 66 звонков параллельно через ИИ и через ручную оценку контролёра, посчитали дельту отклонения — и только после этого решали, готова ли методология к полному развёртыванию. Где ломается Внедрение оценки звонков без параллельного периода — минимум три месяца с двойной нагрузкой на бюджет — почти всегда даёт ложное чувство готовности. Система показывает цифры раньше, чем доказывает свою методологическую состоятельность. «Я не готов автоматизировать контроль качества, пока нет цифр и доказанной эффективности» — это не осторожность ради осторожности, это единственно рабочая позиция перед заменой людей автоматикой. Чек-лист на понедельник Выписать 2–3 реальных типа звонков в своей воронке — не десять, а именно те, что реально повторяются. Возьмите пять критериев из таблицы выше и адаптировать формулировки под свой скрипт продаж. Настройте выгрузку звонков из CRM по уникальным ID (сущность, менеджер, время), а не полагаться на ручные отметки этапов. Прогнать выборку в 50–70 звонков через ИИ и через ручную оценку, посчитать дельту отклонения. Проведите калибровочную сессию хотя бы с одним менеджером на каждый тип звонка. Только после совпадения оценок в 80–90% случаев — расширять охват и снижать долю ручного контроля. Это медленнее, чем «внедрить ИИ за неделю». Зато к моменту, когда систему используют для решений о премиях или увольнениях, она уже проверена, а не работает на веру. Что сделать на этой неделе: возьмите свой чек-лист (или составьте первый) и вычеркните всё, кроме пяти пунктов, каждый из которых можно подтвердить цитатой из разговора. Если пункт нельзя подтвердить цитатой — это не критерий, а мнение, и в оценке ему не место. Дальше — калибровка с менеджерами, иначе любой чек-лист мёртв. А как поставить на это машину, чтобы оценивались все звонки, а не выборка, — механика в бесплатном курсе . Сократите свой чек-лист до пяти пунктов на этой неделе и посмотрите, как изменится качество заполнения.