директор и машина · контроль качества · полный гайд · 20 января 2025

полный гайд направления

Как построить систему контроля качества звонков: от записи до отчёта руководителю

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

Что такое контроль качества звонков и почему «прослушать пару разговоров» — это не контроль

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

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

На диаграмме — охват звонков контролем: ручная прослушка одним контролёром закрывала около четверти потока отдела из 8 менеджеров, автоматическая выгрузка и ИИ-скоринг после калибровки доводят охват до полного объёма.

Дальше в статье — не про то, «как приятно, когда всё автоматизировано», а про то, из каких узлов реально собирается система, где она чаще всего рвётся и сколько это стоит на цифрах условной компании: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 тыс. ₽, цикл сделки ~6 недель.

Из чего физически состоит система контроля

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

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

Дальше разберу каждый узел отдельно — потому что именно на стыках между ними компании теряют месяцы на настройку.

Выгрузка и идентификация: как система понимает, какой звонок оценивать

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

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

Транскрибация: техническая изнанка, о которую разбивается оценка

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

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

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

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

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

ИИ-скоринг против ручной оценки: зачем нужна калибровка, а не слепое доверие

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

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

Контроль переписок и SLA ответа: где теряются деньги, пока все смотрят только на звонки

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

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

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

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

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

С чего начать: минимальный контур за одну неделю

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

1. Выгрузить вручную 15–20 звонков за неделю из CRM (или попросить менеджера по автоматизации настроить разовую выгрузку по API) в Google Drive.
2. Прогнать их через транскрибацию (любой доступный сервис распознавания речи) и вставить в Google Таблицу — сразу с учётом лимита символов ячейки, короткий фрагмент плюс ссылка на полный текст.
3. Составить один чек-лист на 5 критериев под самый частый тип звонка в отделе (обычно это первичный звонок лида).
4. Оценить эти же звонки вручную и параллельно прогнать через ИИ по тому же чек-листу.
5. Посчитать дельту между оценками — это и есть ваша стартовая метрика доверия к будущей автоматизации.

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

ИИ-связка: три промпта под три разные задачи контроля

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

Промпт 1. Классификация типа звонка (дешёвая модель, например gpt-4o-mini). Используется как первый фильтр перед подключением тяжёлого промпта оценки. Вход — транскрипт, полученный по вебхуку из Bitrix24 при смене статуса сделки.

Ты классифицируешь тип телефонного звонка по транскрипту.
Верни ответ строго в формате JSON без пояснений.

Входные данные:
- transcript: полный текст разговора
- deal_stage: текущий этап сделки в CRM
- is_first_contact: true/false — первый ли это контакт с клиентом

Определи call_type из списка:
"primary_lead" — первичный звонок нового лида
"sales_call" — звонок в рамках активной сделки (презентация, дожим)
"secondary_call" — повторный контакт с уже действующим клиентом
"support_call" — звонок по сервисным вопросам, не про продажу

Верни:
{
  "call_type": "...",
  "confidence": 0.0-1.0,
  "reason": "краткое обоснование в одно предложение"
}

Транскрипт: {{transcript}}
Этап сделки: {{deal_stage}}
Первый контакт: {{is_first_contact}}

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

{
  "call_type": "sales_call",
  "confidence": 0.86,
  "reason": "Менеджер презентует условия договора и отрабатывает возражение по цене"
}

Промпт 2. Оценка звонка по релевантному чек-листу (дорогая модель, например GPT-4o или Claude Sonnet). Подключается после классификации, использует контекст предыдущих звонков с тем же клиентом. Вход — из amoCRM API: транскрипт, тип звонка (из промпта 1), история предыдущих касаний.

Ты — контролёр качества звонков отдела продаж.
Оцени звонок по чек-листу для типа "sales_call".
Учитывай контекст предыдущих звонков с этим клиентом — не оценивай разговор в отрыве от истории.

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

Верни JSON:
{
  "scores": {"1": 0-2, "2": 0-2, "3": 0-2, "4": 0-2, "5": 0-2},
  "total": сумма,
  "red_flags": ["конкретная проблемная фраза или её отсутствие"],
  "manager_note": "одна рекомендация для менеджера"
}

Транскрипт: {{transcript}}
История предыдущих звонков: {{previous_calls_summary}}

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

{
  "scores": {"1": 2, "2": 2, "3": 0, "4": 1, "5": 2},
  "total": 7,
  "red_flags": ["Клиент дважды спросил про рассрочку — менеджер сменил тему"],
  "manager_note": "Отработать возражение по рассрочке, а не уходить от него"
}

Промпт 3. Анализ переписки на эмпатию и деловую коммуникацию (дешёвая модель, ежемесячный batch-прогон). Вход — выгрузка чатов за месяц из Google Sheets, куда стекаются диалоги из открытых линий CRM.

Проанализируй переписку менеджера с клиентом за месяц.
Оцени два параметра по шкале 1-5: эмпатию (учёт эмоционального состояния клиента)
и деловую коммуникацию (чёткость, отсутствие лишних извинений, конкретика).

Входные данные (строка таблицы Google Sheets):
- manager_name
- chat_log: полный текст переписки за период
- response_times: массив времени ответа в часах на каждое сообщение клиента

Верни JSON:
{
  "manager_name": "...",
  "empathy_score": 1-5,
  "business_score": 1-5,
  "avg_response_hours": число,
  "top_issue": "главная проблема одной фразой"
}

Переписка: {{chat_log}}
Время ответов: {{response_times}}

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

{
  "manager_name": "Менеджер 4",
  "empathy_score": 2,
  "business_score": 4,
  "avg_response_hours": 11.2,
  "top_issue": "Игнорирует эмоциональные сообщения клиента, отвечает только по фактам"
}

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

На отделе из 8 менеджеров с оборотом 9 млн ₽/мес и чеком 180 тыс. ₽ система контроля качества окупается в течение 1–2 месяцев после завершения калибровки — но первые три месяца параллельного прогона придётся платить дважды: за ручной контроль и за ИИ одновременно.

Разовая настройка интеграции (выгрузка из CRM, классификация, чек-листы, личный кабинет) — это в среднем 2-3 недели работы программиста или подрядчика. Дальше — ежемесячная стоимость обработки: при 8 менеджерах и примерно 15 звонках в день на человека набегает около 2600 звонков в месяц, обработка каждого (транскрибация + классификация + оценка) через связку дешёвой и дорогой модели обходится примерно в 19 ₽ за звонок, а в сумме выходит около 50 000 ₽ в месяц — раскладка ниже в таблице.

Сделок в месяц ≈ оборот / средний чек = 9 000 000 / 180 000 = 50. Если 10% сделок зависает из-за пропущенных ошибок в звонках (не выявлено возражение, забыт follow-up) — это 5 сделок под риском, то есть риск в деньгах ≈ 5 × 180 000 = 900 000 ₽/мес до внедрения контроля. Если контроль спасает половину из них — выгода ≈ 450 000 ₽/мес (оценка).

Что мы не считаем эффектом: время, которое контролёр качества освобождает при переходе на выборочную ручную проверку, — если эти часы просто перераспределяются на другие задачи, а не сокращают ФОТ, в деньги их не переводим. Итог: ежемесячные расходы на систему (50–90 тыс. ₽ на калибровочной фазе) многократно перекрываются экономией на ФОТ и спасёнными сделками ещё до конца первого квартала эксплуатации. Похожую экономику, но в конкретных цифрах чужого внедрения — 7139 оценок в месяц за $300 — уже показывали выше, в разборе про контроль качества без штатного ОКК, на примере отдела без штатного ОКК. Важно не путать эффект: экономия здесь — результат именно контроля качества звонков, а не всего комплекса автоматизации отдела продаж.

Зрелость по уровням: что делает компания на старте, через квартал и через год

Зрелость системы контроля качества измеряется не количеством купленных инструментов, а долей звонков под контролем и тем, насколько команда доверяет оценке — на старте это обычно 25% и недоверие, через год — 100% и встроенное в регламент обучение.

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

Чек-лист на первый понедельник

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

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

Сколько звонков нужно для калибровки ИИ-оценки?

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

Какой охват звонков даёт ИИ-контроль по сравнению с ручным?

Ручной контроль в компаниях с одним-двумя контролёрами обычно закрывает 10–25% звонков; система с автоматической выгрузкой и оценкой способна закрыть 100% без роста штата.

Сколько стоит внедрение речевой аналитики для отдела из 8 менеджеров?

Разовая настройка интеграции — это порядка 150 тысяч рублей, ежемесячная обработка звонков (в конфигурации из статьи — около 50 тысяч ₽) на порядок дешевле одной ставки контролёра качества.

Как снять сопротивление менеджеров ИИ-контролю звонков?

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