Короткий ответ: начните речевую аналитику с одного типа разговора и набора наблюдаемых действий. Для каждого балла требуйте основание в записи, отдельно отмечайте неприменимые критерии и недостаток данных. Сначала сравните AI с согласованным ручным разбором, затем используйте его для отбора звонков и обучения. Сам по себе низкий балл не доказывает ошибку менеджера.
Ниже — предлагаемая методика контроля, которую можно применять при выборе сервиса и проверке пилота. Это не универсальная шкала всех продуктов. Возможность передавать контекст, менять правила и пересматривать оценку нужно подтвердить в конкретной системе.
Как внедрить речевую аналитику в отдел продаж
- Выберите управленческий вопрос. Например: после квалификационного звонка понятно ли, что нужно клиенту и о каком следующем действии договорились? Формулировка «контролировать качество всех разговоров» слишком широка для первого пилота.
- Ограничьте сценарий. Разделите первичный запрос, повторное согласование, сервисный вопрос и жалобу. Один скрипт не должен требовать повторной презентации компании при коротком уточнении времени встречи.
- Проверьте записи и связи. Найдите исходное аудио, убедитесь, что слышны обе стороны и звонок привязан к нужной сделке. Перевод на другого сотрудника и несколько частей записи не должны приписываться одному человеку без проверки.
- Согласуйте шкалу с руководителем и менеджерами. Для каждого пункта запишите признак выполнения, исключение и пример спорной ситуации. Назначьте того, кто разбирает разногласия.
- Проведите пробный расчёт без автоматических последствий для сотрудников. Сравните результаты с ручной оценкой, выясните причины ошибок и только потом определите рабочий порог уведомлений.
До передачи записей в выбранный сервис определите разрешённый состав данных, доступ к аудио и расшифровкам, хранение и удаление. Для оценки разговора обычно не нужен полный архив документов клиента. Техническую доступность записи проверяйте отдельно от наличия карточки звонка в CRM.
Например, штатный раздел звонков amoCRM описывает количество и длительность вызовов, фильтры и связь с карточками. Это не то же самое, что содержательная оценка по вашей шкале. Документация аналитики звонков amoCRM. Общий выбор первого AI-сценария разобран в отдельном практическом материале.
Шкала качества разговора
Ниже — учебная шкала для содержательного разговора о выборе решения. Она оценивает действия, а не личность сотрудника, его акцент или предполагаемые эмоции. Продажа может не состояться даже после качественного разговора; успешная продажа тоже не подтверждает выполнение каждого пункта.
Для применимого критерия используйте 0, 1 или 2 балла. Дополнительно нужны два состояния: «не применимо» — действия не требовал сценарий; «недостаточно данных» — требование применимо, но запись или контекст не позволяют сделать вывод. Оба состояния отличаются от нуля.
| Критерий | 0 — не выполнено | 1 — частично | 2 — выполнено |
|---|---|---|---|
| Цель разговора | Менеджер не выяснил причину обращения и перешёл к несвязанной презентации | Общая тема понятна, конкретный вопрос не уточнён | Установлен вопрос, который клиент хочет решить в этом разговоре |
| Задача и ограничения | Существенные для выбора требования не выяснены, хотя возможность была | Задача названа, но важное ограничение осталось непроверенным | Выяснены нужные для этого сценария условия или подтверждены известные ранее |
| Связь предложения с задачей | Предложение противоречит выявленной задаче либо не объяснено | Назван подходящий вариант без объяснения, почему он подходит | Вариант связан с потребностью, обозначены существенные ограничения |
| Ответ на вопрос или возражение | Менеджер проигнорировал прозвучавший вопрос | Ответил лишь на часть либо не уточнил неоднозначность | Дал содержательный ответ или признал отсутствие данных и согласовал проверку |
| Корректность обещаний | Подтверждено противоречие обещания действующим условиям | Условия оговорены не полностью, важное исключение осталось неясным | Обещания соответствуют доступным условиям, неподтверждённое обозначено как требующее согласования |
| Следующее действие | Нужное продолжение не определено, хотя клиент был готов его обсуждать | Действие названо без срока или ответственного | Понятны действие, исполнитель и срок либо условие возвращения к вопросу |
Перед использованием уточните слова «существенное» и «нужное» под продукт. Например, для выбора поставки это могут быть количество и требуемая дата, а для внедрения CRM — текущая система и процесс. Если критерий допускает несколько толкований даже у двух руководителей, AI не исправит эту неопределённость.
Если возражений не было, соответствующий пункт неприменим. Если клиент сразу попросил перезвонить, оценивать полноценную презентацию не нужно. Если нет актуальных условий предложения, правильность обещанной цены нельзя установить по одной записи — это недостаток данных, а не автоматически ошибка менеджера.
Для полностью проверяемого звонка можно считать долю: сумма баллов / (2 × число применимых критериев) × 100%. При отсутствии применимых пунктов оценку не рассчитывайте. Если по применимому пункту недостаточно данных, сохраняйте профиль доступных оценок, но не выдавайте итоговый процент за полный и не включайте его в общий рейтинг без отдельного правила.
Учебный пример: пять применимых критериев получили 2, 2, 1, 2 и 1 балл; шестой неприменим. Итог — 8 из 10, или 80%. Это результат условного разговора, не порог качества и не статистика CHECK CRM. Если один из этих пяти пунктов невозможно проверить, вместо прежних 80% нужно показать неполную оценку.
Какое доказательство должно стоять за баллом
Для каждой оценки сохраняйте: ID звонка, критерий и его версию, балл, цитату, время фрагмента, объяснение и используемый контекст. Цитату перепроверяют по аудио: в расшифровке могут потеряться отрицание, сумма или принадлежность реплики. Для вывода об отсутствии действия отметьте, что просмотрен весь относящийся к нему участок разговора, а не только найденная фраза.
Три слоя проверяются отдельно:
- Запись: есть ли весь разговор, обе стороны и правильная привязка к сотруднику.
- Расшифровка: правильно ли распознаны ключевые слова и разделены реплики.
- Оценка: верно ли выбраны сценарий, применимость критерия и основание для балла.
Не исправляйте потерянное начало записи ужесточением скрипта. Не считайте согласие клиента с ценой, если фразу произнёс менеджер. Общий процент без этих проверок не показывает, на каком слое произошла ошибка.
Как проверить точность AI-оценки
- Соберите две части выборки. Случайные звонки из выбранного рабочего потока нужны для оценки обычной работы. Отдельный набор сложных случаев — шум, перевод, отказ, короткий повторный звонок — нужен для поиска слабых мест. Не выдавайте результаты специально отобранных проблемных разговоров за долю ошибок всего отдела.
- Получите ручной эталон. Два проверяющих независимо оценивают одну и ту же часть записей без просмотра баллов AI. Разногласия разбирают по аудио и правилам; неразрешённые случаи отмечают отдельно. Согласие с одним случайным мнением не равно доказанной точности.
- Разделите настройку и проверку. На одной части уточняйте критерии, другую сохраните для итоговой проверки. Не подтверждайте качество только звонками, по которым уже исправляли инструкции.
- Сравните каждый критерий. Считайте совпадения баллов и применимости, ложные замечания, пропущенные нарушения и случаи без достаточных данных. Итоговое среднее может скрыть систематическую ошибку одного важного пункта.
- Проверьте не только отмеченные звонки. Выборочно слушайте и те, которые AI признал хорошими: иначе пропущенные ошибки останутся невидимыми.
Учебный расчёт для одного бинарного критерия. Проверяющие разметили 100 пригодных разговоров и нашли 50 нарушений. AI отметил 40 разговоров: в 30 нарушение подтвердилось, в 10 — нет. Значит, подтверждены 30 / 40 = 75% тревог; найдено 30 / 50 = 60% реальных нарушений. Пропущены 20 нарушений. Одна цифра «75% точности» скрыла бы вторую проблему.
Эти показатели имеют смысл при согласованном определении нарушения и проверенной выборке. Размер выборки, допустимые пропуски и ложные тревоги выбирайте до приёмки с учётом частоты события и цены ошибки. Отсутствие редкого нарушения в небольшой выборке не подтверждает способность модели его находить. Показывайте абсолютные количества, состав проверенных звонков и отдельно — долю записей, которые вообще удалось оценить.
Как учитывать контекст сделки
Перед оценкой определите, какие сведения были доступны сотруднику на момент разговора: тип обращения, этап, предыдущая договорённость, продукт и действовавшие условия. Позднейшие поля карточки и будущий исход сделки не должны незаметно менять оценку уже состоявшегося действия.
Учебный пример. Вчера клиент согласовал состав работ, сегодня звонит уточнить дату начала. AI по скрипту первичной продажи ставит ноль за отсутствие выявления потребности. Проверяющий видит предыдущую договорённость: для этого звонка нужен сценарий подтверждения сроков. Ошибка находится в выборе сценария, а не обязательно в действиях менеджера.
Передавайте модели только подтверждённый и нужный контекст. Фиксируйте источник и время сведения. Если выбранный продукт не умеет учитывать историю сделки, ограничьте автоматическую оценку тем, что слышно в текущем разговоре, а контекстные пункты оставьте на ручной разбор. Не предполагайте, что наличие AI внутри CRM означает доступ ко всем её данным.
Если из разговора следует необходимость продолжения, проверяйте и содержание договорённости, и её фиксацию в CRM как два разных действия. Требования к следующему шагу описаны в статье о сделках без задач.
Что делать, если AI неверно оценил менеджера
У сотрудника должен быть понятный путь оспаривания: ссылка на звонок, спорный пункт, фрагмент записи и краткое объяснение. До завершения разбора не используйте спорную автоматическую оценку как единственное основание для решений о вознаграждении или работе сотрудника.
- Сохраните исходную оценку, версию правил и данные, по которым она получена.
- Проверьте запись и расшифровку, затем сценарий и контекст.
- Запишите решение человека: ошибка AI, ошибка исходных данных, неясное правило или подтверждённый пропуск действия.
- Исправьте причину. Неверный сценарий требует другой классификации, двусмысленный пункт — уточнения, потерянная запись — ремонта доставки данных.
- Повторите оценку контрольных примеров и проверьте, не сломалось ли то, что раньше работало.
- Отразите пересмотр в отчёте и сообщите сотруднику результат. Сохраните прежнюю и новую версии для объяснения изменений.
В актуальной справке Битрикс24 описана повторная оценка по другому или изменённому скрипту; удалить оценку нельзя, а в рейтинг идёт последняя. Там же указано, что автообновление может добавлять правила, а скрипт после расшифровки может отличаться от показанного во время звонка. Поэтому в пилоте фиксируйте версии и проверяйте фактически выбранный сценарий. Обновления распространяются постепенно — доступность нужно проверить в своём аккаунте. Документация речевой аналитики Битрикс24.
В другом сервисе способ пересмотра может отличаться. Если хранить версионную историю в нём нельзя, ведите отдельный журнал разборов. Повторный запуск сам по себе не доказывает, что причина ошибки устранена.
Когда пилот можно принять
До запуска согласуйте таблицу приёмки. В ней должны быть проверяемые условия, а не только желаемый средний балл:
| Область | Что подтвердить | Что делать при проблеме |
|---|---|---|
| Доставка и покрытие | Известны все звонки выбранного потока, обработанные и пропущенные записи с причинами | Исправить источник; не выдавать анализ части звонков за контроль всех |
| Качество оценки | На отложенной выборке выполнены согласованные требования по каждому важному критерию | Сузить сценарий, уточнить правило или оставить ручную проверку |
| Объяснимость | Замечание проверяется по записи и контексту; цитата существует и принадлежит нужному участнику | Пометить вывод неподтверждённым и разобрать причину |
| Работа руководителя | Измерены время разбора, число полезных находок и объём ложных тревог | Изменить очередь проверок; не повышать порог только ради красивой статистики |
| Пересмотр | Назначен ответственный, работают срок разбора и уведомление сотрудника | Не запускать автоматические последствия до появления рабочего процесса |
| Изменения | Сохранены версия шкалы, настройки, дата обновления и контрольный набор | После смены модели или правил повторить проверку и обозначить новую версию отчёта |
После приёмки продолжайте выборочную ручную проверку, включая высоко оценённые звонки. Сравнивайте сотрудников внутри сопоставимых сценариев: обработка жалоб и первичные продажи имеют разные задачи. Не интерпретируйте рост среднего балла после замены шкалы как доказанный рост качества.
Для запуска подготовьте шкалу, примеры разговоров и журнал расхождений. Их можно использовать в проекте диагностики и пилота AI CHECK CRM; регулярную проверку качества и изменения после запуска — включить в согласованный план сопровождения CRM. Объём автоматизации определяется результатом контрольной проверки.