Мы перестали анализировать весь звонок и начали проверять один факт

Как переход от общей оценки разговора к одному наблюдаемому действию помог связать работу менеджеров, встречи и договоры без преувеличения роли AI.

Мы несколько раз меняли объект анализа.

Сначала пытались отличить успешные звонки от неуспешных.

Затем искали явные и скрытые возражения.

После этого оценивали разговор по трём критериям:

• право на разговор;
• причина для диагностики;
• конкретный следующий шаг.

Рубрика помогла точнее разбирать коммуникации.

Но для изменения работы команды требовался более узкий вопрос:

Предложил ли менеджер бесплатный аудит в разговоре, где такое предложение было уместно?

Дальше можно было отдельно проверить:

• как отреагировал клиент;
• появилась ли встреча;
• возникла ли задача;
• был ли заключён договор.

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

Почему выбрали бесплатный аудит

Компания работала с организациями, которым раньше внедряла и дорабатывала решения на базе 1С.

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

• новые ручные операции;
• ошибки после обновлений;
• изменения процессов;
• накопленные доработки;
• участки, которые перестали соответствовать текущей работе.

Аккаунт-менеджер не обязан самостоятельно проводить техническую диагностику.

Его задача могла быть проще:

1. Напомнить контекст предыдущих работ.
2. Уточнить, как всё работает сейчас.
3. Предложить бесплатную проверку.
4. Передать клиента специалисту.

Аудит не требовал продавать большой проект в первом разговоре.

Он создавал понятный следующий этап.

Сам факт предложения можно было увидеть в транскрибации и проверить вручную.

Мы разделили действие менеджера и решение клиента

Раньше эти события могли смешиваться в общей категории успеха.

Теперь отчёт разделял их.

Действие менеджера

• предложил аудит;
• не предложил;
• критерий неприменим.

Реакция клиента

• согласился;
• отказался;
• попросил вернуться позже;
• предложил другой формат.

Последующее событие

• встреча назначена;
• встреча проведена;
• появилась задача;
• заключён договор.

Это позволило увидеть разные ситуации.

Менеджер мог сделать предложение, а клиент отказаться.

Мог не предложить аудит, но получить конкретную задачу другим способом.

Мог предложить аудит в неподходящем разговоре, что формально повышало показатель, но не создавало ценности.

Один критерий не стал универсальным скриптом

Руководитель сразу обозначила важное ограничение.

Не каждый успешный разговор должен заканчиваться предложением аудита.

Некоторые клиенты могли сразу:

• сформулировать задачу;
• попросить оценить работы;
• согласиться на консультацию;
• передать запрос специалисту.

Если в таком звонке не прозвучало слово “аудит”, это не делает разговор неуспешным.

Поэтому мы разделили два слоя.

Общий разбор

Показывал:

• с чего начался разговор;
• что выяснял менеджер;
• какие задачи обсуждались;
• о чём договорились.

Операционный критерий

Показывал:

• выполнила ли команда одно выбранное действие в подходящих ситуациях.

Один показатель не должен описывать весь бизнес.

Он нужен для проверки одной гипотезы.

Простое действие всё равно требовало правил

Критерий “предложил или не предложил” кажется очевидным.

Но потребовалось определить:

• что считается предложением;
• достаточно ли простого упоминания;
• нужно ли объяснить предмет аудита;
• что считать согласием;
• как учитывать инициативу клиента;
• какие звонки исключать;
• как отделять текущих клиентов от бывших.

Простой показатель требует сложной подготовки.

Но после калибровки им значительно легче управлять, чем общей оценкой разговора.

Что произошло в наблюдаемом периоде

За период около трёх недель в публичной версии кейса были зафиксированы:

• более 120 звонков;
• 49 предложений аудита;
• 9 встреч;
• 5 договоров на ежемесячное обслуживание;
• 200 000 рублей общей стоимости этих договоров.

Это те цифры, которые были озвучены в опубликованном видео и используются во всей публичной серии.

Они показывают наблюдаемую последовательность событий.

Но сами по себе не доказывают, что каждый следующий этап был вызван только предыдущим.

Почему нельзя сказать, что AI принёс 200 000 рублей

В этот период одновременно изменилось несколько элементов:

• руководитель фильтровала базу;
• команда получила конкретный фокус;
• менеджеры начали совершать исходящие звонки;
• обсуждались сильные и слабые примеры;
• платформа показывала выполнение критерия;
• специалисты проводили диагностику;
• клиенты принимали решения.

Поэтому корректная формулировка выглядит так:

После выбора критерия, подготовки базы, работы руководителя и звонков команды в наблюдаемом периоде появились 9 встреч и 5 договоров на ежемесячное обслуживание общей стоимостью 200 000 рублей.

Некорректная:

AI принёс компании 200 000 рублей.

Во второй формулировке исчезают люди, процесс и ограничения данных.

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

Первый вопрос был не о выручке.

Он звучал проще:

Начали ли менеджеры предлагать аудит в подходящих разговорах?

Только после этого можно было смотреть дальше.

Уровень 1. Поведение

Предложил ли менеджер аудит?

Уровень 2. Реакция

Согласился ли клиент продолжить разговор?

Уровень 3. Следующий этап

Появилась ли встреча?

Уровень 4. Коммерческий результат

Появился ли договор?

Если первое действие почти не выполняется, нельзя надёжно оценивать его связь с дальнейшей воронкой.

Один критерий изменил характер обратной связи

До этого руководитель мог говорить:

Менеджерам нужно лучше работать со старой базой.

После запуска появилось более конкретное обсуждение:

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

Обратная связь стала привязана к факту.

Исследование превратилось в управленческий цикл

Раньше мы в основном изучали коммуникации.

Теперь появился повторяющийся процесс:

1. Руководитель выбирает критерий.
2. Менеджеры применяют действие.
3. Платформа фиксирует выполнение.
4. Руководитель проверяет примеры.
5. Команда получает обратную связь.
6. Следующий период измеряется по тому же правилу.

Это и было главным изменением.

Не более сложный промт.

Не ещё одна классификация.

А связь анализа с конкретным действием команды.

Кто создал результат

Платформа

• собрала и обработала звонки;
• применила согласованный критерий;
• показала конкретные разговоры;
• помогла сократить ручную проверку.

Руководитель

• выбрала гипотезу;
• фильтровала базу;
• объясняла задачу сотрудникам;
• разбирала результаты;
• следила за коммерческим продолжением.

Менеджеры

• изучали карточки;
• совершали звонки;
• задавали вопросы;
• предлагали аудит;
• назначали встречи.

Специалисты

• проводили диагностику;
• определяли возможные работы;
• готовили продолжение.

Клиенты

• соглашались на встречу;
• подтверждали задачи;
• принимали решение о договоре.

AI не заменил ни одну из этих ролей.

Он сделал выбранное поведение видимым.

Что этот кейс подтверждает

Можно достаточно уверенно сказать:

• компания выбрала один операционный критерий;
• критерий применялся к реальным разговорам;
• команда начала использовать предложение аудита;
• руководитель фильтровала базу и возвращала обратную связь;
• за три недели в публичном срезе были зафиксированы более 120 звонков, 49 предложений, 9 встреч и 5 договоров на 200 000 рублей.

Что этот кейс не доказывает

Он не доказывает, что:

• все пять договоров возникли только благодаря предложению аудита;
• результат был создан одной технологией;
• такая же воронка повторится в другой компании;
• аудит является универсальным следующим шагом;
• увеличение количества предложений автоматически даст пропорциональный рост договоров;
• менеджеры должны предлагать аудит в каждом звонке.

Это ограниченный практический кейс, а не универсальный закон.

Что мы сделали бы иначе сейчас

Сразу определили бы один сегмент

Только бывшие клиенты с подтверждённой историей работ и без активного проекта.

Сразу отделили бы три уровня результата

• действие;
• реакция;
• коммерческое продолжение.

Зафиксировали бы исходный период

До обратной связи команде измерили бы выполнение критерия по тем же правилам.

Не меняли бы фильтр внутри спринта

Это позволило бы корректнее сравнивать периоды.

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

Чтобы не ограничиваться общей последовательностью событий.

Заранее определили бы итоговое решение

Например:

• сохранить критерий;
• изменить формулировку;
• изменить сегмент;
• выбрать другой следующий шаг.

Главный вывод

Мы начали с вопроса:

Почему клиенты отказываются?

Затем пытались понять:

Насколько хорошо менеджер проводит разговор?

Рабочая управленческая конструкция появилась после более узкого вопроса:

Выполнил ли менеджер одно конкретное действие в ситуации, где оно было уместно?

Этот вопрос можно:

• определить;
• проверить;
• посчитать;
• вернуть команде;
• повторно измерить;
• связать со следующим этапом.

Главное изменение произошло не потому, что промт стал сложнее.

Объект анализа стал проще.

Один тип звонка.

Один сегмент.

Одно действие.

Одна реакция клиента.

Один следующий этап.

На поиск этой конструкции ушло несколько месяцев.

В заключительной части я соберу план, по которому запускал бы такой проект сейчас, чтобы быстрее прийти к проверяемому управленческому циклу.

← Предыдущая часть
Все материалы серии
Следующая часть →