Руководитель получает таблицу, где один менеджер набрал высокий балл, другой — низкий. Кажется, что контроль качества уже работает. Но при разборе выясняется: короткий повторный звонок оценивали по сценарию первого контакта, в критерий «выявил потребность» попали любые вопросы, а отсутствие следующего шага система не считала критичным. Цифра есть, управленческого смысла нет.
Рабочий чек-лист оценки звонка менеджера начинается не с количества пунктов и не с настройки AI. Сначала отдел договаривается, какое наблюдаемое действие подтверждает качественную работу на конкретном этапе продажи. Затем правила проверяют на реальных разговорах, уточняют исключения и только после этого автоматизируют оценку.
Что должен давать чек-лист руководителю
Чек-лист нужен не для составления рейтинга ради рейтинга. Он должен отвечать на три вопроса: выполнено ли обязательное действие, где менеджеру требуется разбор и какой разговор нужно проверить вручную. Если низкая оценка не приводит к понятному действию, критерий либо слишком общий, либо не связан с процессом продаж.
Отделу обычно нужны разные уровни контроля. Критические критерии защищают процесс: менеджер подтвердил запрос, не дал запрещённого обещания, зафиксировал договорённость. Развивающие критерии помогают обучению: задал уточняющие вопросы, связал предложение с потребностью, проверил понимание. Смешивать их в одну нерасшифрованную сумму неудобно.
| Слабая формулировка | Проверяемый критерий | Какое доказательство искать | Что делать при нарушении |
|---|---|---|---|
| Хорошо выявил потребность | Задал вопросы о задаче, сроке и ограничениях | Ответы клиента по каждому обязательному блоку | Разобрать пропущенный блок |
| Отработал возражение | Уточнил причину сомнения до ответа | Вопрос менеджера и пояснение клиента | Проверить типовой сценарий |
| Презентовал продукт | Связал предложение с озвученной задачей | Фраза клиента и соответствующий аргумент | Скорректировать обучение |
| Закрыл разговор | Согласовал действие, ответственного и срок | Явная договорённость обеих сторон | Поставить задачу и проверить сделку |
| Был вежлив | Не перебивал и корректно завершил конфликтный фрагмент | Конкретный участок записи | Передать спорный случай РОПу |
Шаг 1. Разделите звонки по бизнес-сценарию
Один чек-лист редко подходит всем разговорам. Первый контакт, квалификация, обсуждение коммерческого предложения, повторный звонок и возврат клиента решают разные задачи. На первом контакте важно понять запрос и следующий шаг. На согласовании уже может не требоваться повторная презентация компании.
Начните с небольшого числа сценариев, которые реально различаются по цели. Для каждого запишите входное состояние сделки, ожидаемый результат разговора и признаки успешного завершения. Если сценарии отличаются только названием, их лучше объединить. Если обязательные действия разные, нужна отдельная версия критериев.
Шаг 2. Переведите скрипт в наблюдаемые действия
Скрипт часто содержит пожелания: «установить контакт», «проявить экспертность», «понять клиента». Для единообразной оценки этого недостаточно. Каждый пункт должен описывать то, что можно подтвердить по записи или расшифровке: менеджер представился, задал вопрос, повторил договорённость, назвал срок или запросил недостающие данные.
Хорошая формула критерия состоит из действия, доказательства и исключения. Например: «Менеджер согласовал следующий шаг; доказательство — в разговоре названы действие и срок; исключение — клиент завершил звонок до обсуждения продолжения». Такая запись помогает и проверяющему, и AI одинаково понимать границу результата.
Шаг 3. Выберите понятную шкалу
Для большинства обязательных действий полезна шкала «выполнено / не выполнено / неприменимо». Она проще для калибровки, чем субъективные оценки от одного до десяти. Промежуточное состояние допустимо, если у него есть отдельное определение: например, следующий шаг назван, но срок не согласован.
Не заставляйте систему угадывать отсутствие данных. Плохая расшифровка, обрыв записи или разговор не по теме должны давать статус «недостаточно данных» и маршрут на ручную проверку. Низкий балл менеджеру за техническую проблему разрушает доверие к контролю.
Шаг 4. Назначьте критичность, а не декоративные веса
Вес критерия должен отражать последствие для процесса. Отсутствие приветствия и отсутствие согласованного следующего шага могут быть нарушениями, но влияют на сделку по-разному. Сначала выделите условия, которые блокируют положительный итог, затем обязательные и развивающие пункты.
Не добивайтесь красивой суммы в сто пунктов ценой ложной точности. Руководителю полезнее видеть нарушенный критический критерий и подтверждающий фрагмент, чем общий балл без объяснения. Итоговая оценка остаётся навигацией к разговору, а не автоматическим решением о премии или дисциплинарной мере.
Шаг 5. Опишите неоднозначные случаи
Клиент может сам назвать потребность до вопроса менеджера. Следующий шаг иногда следует из контекста, но не подтверждён вслух. Возражение может быть вопросом о деталях, а не отказом. Соберите такие пограничные примеры заранее и решите, как их оценивать.
Для каждого критерия полезны положительный пример, отрицательный пример и исключение. Не нужно публиковать реальные разговоры или персональные данные в рабочей инструкции. Достаточно обезличенных фрагментов и описания логики. Доступ к исходным записям должен соответствовать принятой в компании модели прав.
Шаг 6. Проведите калибровку на одной выборке
Выберите разговоры разных менеджеров, длительности и результата. Одну и ту же выборку независимо оценивают РОП или наставники, затем сравнивают расхождения между людьми. Если два опытных руководителя по-разному понимают критерий, автоматизация лишь закрепит неоднозначность.
После согласования человеческой оценки ту же выборку обрабатывает AI. Сравнивайте не только итог, но и каждый критерий: найденное доказательство, пропущенный фрагмент, неверно выбранное исключение. Ошибки группируют по типам, а формулировку правила меняют только после нескольких похожих случаев.
Шаг 7. Запускайте пилот с ручной проверкой
На пилоте не используйте AI-оценку как единственное основание для мотивации. Руководитель просматривает критические нарушения, случаи «недостаточно данных» и часть обычных оценок. Это позволяет заметить систематическую ошибку до того, как она попадёт в отчёт отдела.
Зафиксируйте версию чек-листа и дату изменения. Если критерии меняются, оценки до и после нельзя механически сравнивать как одну последовательность. Повторная калибровка нужна после изменения скрипта, продукта, этапов продажи, состава каналов или качества записи.
Условный пример для B2B-продаж
Рассмотрим условный пример. Компания оценивает звонки после отправки коммерческого предложения. Первоначальный список требовал повторно выявить потребность, подробно презентовать компанию и закрыть возражение. На реальных разговорах эти действия часто уже были выполнены раньше, поэтому сильные менеджеры получали неполные оценки.
РОП меняет цель сценария: проверить реакцию на предложение, выяснить участников согласования, зафиксировать препятствие и договориться о следующем действии со сроком. Для каждого пункта добавляют доказательство и статус «неприменимо». После калибровки отчёт показывает не абстрактное соблюдение универсального скрипта, а качество конкретного этапа сделки.
BitrixGPT и решение CTR1: не смешиваем возможности
По актуальной официальной документации Битрикс24, BitrixGPT в CRM умеет расшифровывать звонки, готовить резюме и оценивать разговоры по скриптам продаж. Доступность отдельных режимов зависит от действующих условий продукта и настроек портала, поэтому перед запуском их проверяют в официальной документации и на конкретном тарифе.
CTR1 не разрабатывает Битрикс24. CTR1 как интегратор настраивает CRM и предлагает отдельное решение для анализа звонков и контроля продаж. В проекте критерии, место сохранения результата, отчёты и действия после оценки согласуются отдельно. Обзор роли автоматического контроля есть в материале о контроле качества звонков без постоянного прослушивания.
Типичные ошибки
- Один список для всех этапов. Критерии противоречат цели конкретного разговора.
- Оценивать впечатление. Формулировки «уверенно» и «качественно» не содержат проверяемой границы.
- Не использовать статус «неприменимо». Менеджера штрафует ситуация, которой в звонке не могло быть.
- Сразу привязывать результат к мотивации. Ошибка модели превращается в конфликт с командой.
- Не показывать доказательство. Руководитель видит балл, но не может проверить причину.
- Забывать о версиях. После изменения критериев динамика перестаёт быть сопоставимой.
- Проверять только лучшие записи. Нужны разные сценарии, качество звука и результаты разговора.
Чек-лист готовности критериев
- Для каждого типа звонка определена бизнес-цель.
- У критерия есть наблюдаемое действие и доказательство.
- Описаны положительный пример, нарушение и исключение.
- Критические пункты отделены от развивающих.
- Есть статусы «неприменимо» и «недостаточно данных».
- Несколько руководителей одинаково оценивают тестовую выборку.
- AI сравнен с согласованной человеческой оценкой по каждому пункту.
- Спорные и критические случаи попадают на ручную проверку.
- Версия чек-листа и дата изменения фиксируются.
- По каждому отклонению понятно следующее управленческое действие.
Частые вопросы
Сколько критериев должно быть в чек-листе?
Столько, сколько нужно для цели конкретного сценария. Короткий проверяемый список полезнее длинного перечня общих пожеланий.
Нужно ли оценивать приветствие в каждом звонке?
Это зависит от типа разговора и стандарта компании. Для короткого продолжения уже начатого диалога критерий может быть неприменим.
Можно ли использовать только общий балл?
Общий балл удобен для навигации, но решение должно опираться на расшифровку критериев и подтверждающие фрагменты.
Что делать, если расшифровка неточная?
Помечать оценку как недостаточно надёжную и передавать разговор на ручную проверку, а не считать техническую ошибку нарушением менеджера.
Когда менять веса критериев?
После анализа повторяющихся расхождений и изменения бизнес-процесса. Вес не стоит корректировать ради желаемого среднего балла.
Можно ли сравнивать менеджеров по разным скриптам?
Только по сопоставимым критериям и контексту. Разные этапы и типы клиентов требуют отдельного анализа.
Как часто повторять калибровку?
После значимых изменений скрипта, продукта, этапов сделки или качества данных, а также когда растёт число спорных оценок.
Следующий шаг
Перед автоматизацией полезно проверить, можно ли по каждому критерию показать доказательство и назначить действие руководителя. Дополнительный контекст дают статьи о расшифровке звонков для руководителя и сценариях ИИ после звонка. CTR1 может помочь настроить AI-оценку звонков менеджеров под фактический процесс продаж и правила проверки спорных выводов.
