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

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

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

Любой контроль сотрудники встречают одинаково: соглашаются вслух и обходят на практике. Если вы слушаете десятую часть звонков и по ней судите обо всём отделе продаж — у вас нет контроля качества. У вас есть выборка, которая вас успокаивает. Разбираю, как выстроить контроль отдела продаж так, чтобы это не превратилось в тихую войну.

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

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

Контроль отдела продаж — не слежка за сотрудниками

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

Почему ваши менеджеры сопротивляются

Три причины, и ни одна из них не «им есть что скрывать».

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

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

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

Как внедрить контроль отдела продаж: механика по шагам

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

Порядок для вас: сначала разговор, потом правила, и только потом техника. Любая перестановка даёт саботаж.

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

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

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

ИИ-связка: конвейер, промпт и обвязка

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

Схема конвейера в текстовом виде:

1. CRM (Bitrix24) — выгрузка звонка по триггеру
2. Хранилище (Drive) — аудио + полный транскрипт
3. Дешёвая модель — классификация типа звонка
4. Дорогая модель — оценка по чек-листу
5. Таблица + кабинет — свод, дельта, алерты

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

Пример промпта для второго шага — оценки встречи по чек-листу. Платформа — Google Apps Script, который вызывает API модели и пишет результат обратно в Google Таблицу, откуда его забирает личный кабинет руководителя.

Ты — эксперт по контролю качества звонков отдела продаж.
На входе: JSON с данными одного звонка.

Формат входных данных:
{
  "call_id": "CR-10452",
  "manager": "Иванов И.И.",
  "call_type": "встреча продаж",
  "checklist_id": "sales_meeting_v2",
  "prev_calls_summary": "1-й звонок: клиент интересовался сроками, возражений нет",
  "transcript_link": "https://drive.google.com/...",
  "transcript_text": "<полный текст диалога>"
}

Задача:
1. Оцени звонок строго по пунктам чек-листа checklist_id.
2. Учитывай контекст prev_calls_summary — не оценивай реплики
   вне логики предыдущих касаний с этим клиентом.
3. Если данных недостаточно для однозначной оценки пункта —
   поставь null и укажи причину в comments, не угадывай.
4. Верни только JSON без пояснений вне структуры.

Формат ответа:
{
  "call_id": "...",
  "manager": "...",
  "checklist_score": {"пункт1": 0-2, "пункт2": 0-2, ...},
  "total_score": число,
  "violations": ["список нарушений регламента, если есть"],
  "comments": "краткое пояснение спорных оценок"
}

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

{
  "call_id": "CR-10452",
  "manager": "Иванов И.И.",
  "checklist_score": {"приветствие": 2, "выявление потребности": 1, "работа с возражением": 0},
  "total_score": 62,
  "violations": ["молчание 41 секунда на 6-й минуте"],
  "comments": "возражение по цене не отработано, менеджер сменил тему"
}

Инженерная обвязка. Скрипт крутится по расписанию (триггер Apps Script раз в час), забирает список звонков из Bitrix24 REST API за период, где заполнено поле аудиозаписи и ещё нет оценки. При ошибке вызова API (лимит, таймаут, пустой транскрипт) скрипт не падает молча — пишет статус в отдельную колонку и шлёт алерт в тот же Telegram-бот, который уже используется для оповещений о задержках ответов менеджеров. Повторный запуск — по следующему тику расписания, без ручного вмешательства. Отдельно логируется стоимость каждого вызова API — это тот же контур, что описан в материале о том, сколько реально стоит ИИ в месяц, включая ночь с циклическим запросом на заметную для месячного бюджета сумму из-за бага в коде — ошибка, которая случилась именно на этапе отладки такого пайплайна.

Калибровочная сессия: снимаем сопротивление заранее

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

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

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

Стандарты обслуживания нужны раньше алгоритма

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

Проверка методологии: 66 звонков

Ваш ориентир по объёму выборки: несколько десятков звонков достаточно, чтобы увидеть системные расхождения.

Отдельная категория проблем — не человеческая, а методологическая. Прежде чем масштабировать оценку на всех менеджеров, по каждому звонку фиксируется, как его оценила нейросеть и как оценил человек из отдела контроля качества, и считается дельта отклонения. За месяц набралось 66 звонков с ручной оценкой параллельно с автоматической. Это не недоверие к ИИ ради недоверия — это способ понять, где система систематически ошибается, до того как её результат станет основанием для решений о зарплате или увольнении.

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

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

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

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

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

Выборочные 10% звонков вручную — против 100% охвата с речевой аналитикой на нейросетях (данные из практики внедрения).

Ловушки, похожие на саботаж

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

Часть сопротивления менеджеров на самом деле вызвана не недоверием к идее, а конкретными техническими сбоями, которые система выдаёт за «объективную оценку».

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

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

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

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

Возьмём условную компанию из легенды этого разбора: отдел из 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. Даже если удвоить эту сумму на риск нештатных расходов, она остаётся на порядок меньше высвобождаемого ФОТ — окупаемость по грубой прикидке достигается в первый же месяц эксплуатации, если методология уже прошла проверку дельтой. Отдельно стоит закладывать риск разовых инцидентов: у меня циклический запрос из-за бага в коде за одну ночь обошёлся в сумму порядка нескольких тысяч рублей. Это моя недоработка: я не поставил потолок расходов на контур, прежде чем оставить его работать без присмотра. Сумма небольшая — примерно как один рабочий день контролёра качества, — но именно она заставила пересмотреть готовность системы к продакшену без мониторинга расходов.

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

Оценка для типового отдела из 15 менеджеров по формулам выше — не факт из отчётности конкретного клиента.

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

Ваш чек-лист на понедельник

Первые два пункта — разговоры, не техника.

• Сформулировать стандарт обслуживания письменно — на одном совещании отделов продаж и сопровождения, а не по памяти каждого менеджера.
• Сделать поле с аудиозаписью обязательным для перехода сделки на этап «встреча проведена» — это единственный надёжный триггер выгрузки звонков.
• Выбрать 2–3 типа звонков для старта (не все 10 сразу) и написать под них чек-листы вместе с руководителем продаж.
• Запустить параллельный контур: ИИ-оценка + ручная оценка тех же звонков, минимум 50–70 штук для первой выборки дельты.
• Провести калибровочную сессию с каждым менеджером до того, как оценки начнут влиять на премию.
• Посчитать свою версию формул выше — с вашим потоком звонков, вашей ставкой контролёра и вашим средним чеком — и зафиксировать бюджет на 3 месяца двойной работы с датой решения: масштабировать, донастраивать или остановить.

Контроль отдела продаж — не про то, чтобы поймать менеджера на ошибке. Это про то, чтобы увидеть отдел продаж целиком, а не выборочную четверть. Но когда система в первый раз ошибётся — а она ошибётся, — её будет некому защищать. Разве что тем, кто с самого начала понимал, почему она посчитала именно так. О более широкой картине того, почему технически готовые внедрения буксуют на людях, я писал в материале почему внедрение ИИ не работает — хотя технически всё запустилось.

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

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

Как выстроить контроль, который принимают, — в бесплатном курсе для руководителей.

И последнее, что стоит вам запомнить: сопротивление снимается не жёсткостью, а прозрачностью. Покажите людям, за что именно им ставят балл, — и спор о справедливости прекращается сам.

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

Как убедить менеджеров, что оценка ИИ объективна?

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

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

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

Что делать, если оценка ИИ не совпадает с оценкой человека?

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

Контроль отдела продаж — это то же самое, что слежка за сотрудниками?

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

#автоматизация #ии и нейросети #контроль и надёжность