Почему обзвон старой клиентской базы дал нулевой результат: смешанная CRM-выборка, отсутствие истории контакта и неверный знаменатель оценки.
После нескольких итераций у нас появился возможный операционный фокус:
В подходящем разговоре с бывшим клиентом менеджер уточняет состояние ранее выполненных работ и предлагает бесплатный аудит.
Оставалось запустить звонки и посмотреть, как клиенты реагируют.
Первый же день дал неожиданный результат.
Один из сотрудников сделал 30 звонков.
Встреч не было.
Понятного интереса не было.
Можно было решить:
- менеджер плохо разговаривает;
- скрипт не работает;
- бывшим клиентам не нужен аудит.
Но при разборе выяснилось, что значительная часть контактов вообще не пользовалась услугами компании.
Они находились в CRM, но не были бывшими клиентами в содержательном смысле.
Большая CRM-база не является одним сегментом
За годы работы в системе накопились:
- действующие клиенты;
- бывшие клиенты;
- компании с завершёнными проектами;
- организации, которым готовили предложение;
- незавершённые лиды;
- контакты без состоявшейся коммуникации;
- пустые карточки;
- дубли;
- устаревшие номера;
- компании, которые не использовали 1С.
Формально всё это находилось в одной базе.
Но предложения для этих групп должны отличаться.
Бывшему клиенту можно сказать:
“Мы раньше настраивали вам обмен между системами. Хотим уточнить, как он работает после обновлений и не появились ли ручные операции”.
Компании, которой когда-то только отправили коммерческое предложение, нельзя говорить о проверке ранее выполненных работ.
Работ могло не быть.
Контакт в CRM не создаёт историю отношений автоматически.
Первые звонки проверяли не ту гипотезу
Мы собирались ответить на вопрос:
Предлагают ли менеджеры аудит бывшим клиентам?
Но фактически начали проверять другое:
Что происходит, когда сотрудники звонят всем контактам подряд, включая компании без подтверждённой истории работы?
Это другой эксперимент.
Даже если платформа обработает сотни таких разговоров, объём не исправит несоответствие выборки задаче.
Мы получим много данных о том, что:
- контакт неактуален;
- компания не работала с интегратором;
- собеседник ничего не знает о предыдущем обращении;
- предложение не имеет контекста.
После первых десятков звонков эти сигналы начинают повторяться.
Дополнительный объём уже не даёт нового знания пропорционально затратам.
Руководитель и менеджеры звонили в разных условиях
До массового запуска у руководителя уже были положительные примеры.
Она выбирала:
- крупные компании;
- клиентов, которые её знали;
- контакты с реальной историей работы;
- ситуации, где был понятен предыдущий контекст.
Кроме того, она звонила в статусе руководителя.
Менеджеры получили другую среду:
- массовую выборку;
- слабую историю карточек;
- большое количество контактов;
- отсутствие личного доверия;
- не всегда понятный повод.
Поэтому результаты нельзя было сравнивать напрямую.
Одинаковая формулировка в тёплом и почти холодном контакте работает по-разному.
То, что сработало на тёплом клиенте, не становится универсальным скриптом
Сравним два разговора.
Разговор с историей
Менеджер видит, что компания несколько лет назад настраивала клиенту конкретную интеграцию.
Он говорит:
“Мы раньше делали вам обмен с сайтом. Хотим уточнить, как он работает сейчас. После обновлений иногда появляются ошибки или ручные операции. При необходимости можем бесплатно проверить этот участок”.
Клиент понимает:
- кто звонит;
- откуда известен его контекст;
- что предлагается проверить;
- какую пользу может дать разговор.
Разговор без истории
Карточка почти пустая.
Менеджер говорит:
“Предлагаем бесплатный аудит 1С”.
Клиент может не понимать:
- почему звонят именно ему;
- откуда взяли контакт;
- что предполагается проверять;
- зачем тратить время.
Формально действие выполнено.
Содержательно предложение слабо связано с ситуацией.
Право на разговор создаётся до начала разговора
Мы стали использовать понятие содержательного права на контакт.
Речь не о юридическом разрешении.
Речь о способности объяснить:
- почему обращаются именно к этой компании;
- на какую историю опираются;
- какой возможный риск или пользу обсуждают;
- почему контакт имеет смысл сейчас.
Такое основание может появиться из:
- предыдущей работы;
- незавершённой заявки;
- изменения требований;
- обновления конфигурации;
- ранее зафиксированной проблемы;
- типового риска после внедрения.
Менеджер не обязан заранее знать, что проблема существует.
Но он должен иметь проверяемую гипотезу, почему стоит задать вопрос.
Смешанная выборка искажает оценку сотрудников
Предположим, менеджер сделал 100 звонков.
Только в 30 аудит действительно был уместен.
В остальных разговорах:
- компания не была клиентом;
- шла текущая сервисная работа;
- контакт оказался нецелевым;
- другой сотрудник недавно уже разговаривал с клиентом.
Менеджер предложил аудит в 15 подходящих разговорах.
Если считать от всех звонков, получится 15 процентов.
Если считать только от применимых, получится 50 процентов.
Обе цифры математически верны.
Но отвечают на разные вопросы.
Для управления поведением нужен второй показатель:
Как часто сотрудник выполняет действие в ситуации, где оно уместно?
Поэтому фильтрация является частью методики, а не только настройкой отчёта.
Аккаунт-менеджеры не были отделом исходящих продаж
Обзвон выполняли сотрудники, которые сопровождали текущих клиентов.
Их основная работа включала:
- координацию задач;
- коммуникацию по действующим проектам;
- решение вопросов;
- удержание контекста клиента.
Теперь к этой нагрузке добавились десятки исходящих звонков.
Сотрудники начали спрашивать, не превращаются ли они в отдел продаж.
Риск выгорания был практическим, а не теоретическим.
Последовательность отказов влияет на поведение:
- вступление становится формальным;
- пропадает интерес к карточке;
- предложение звучит механически;
- менеджер быстрее принимает первое “нет”;
- снижается доверие к эксперименту.
Получается замкнутый круг:
- Слабая база создаёт отказы.
- Отказы снижают вовлечённость.
- Разговоры становятся слабее.
- Отчёт показывает проблемы менеджеров.
- Причина ошибочно переносится только на сотрудников.
Подготовка к звонку стала частью качества
До этого мы в основном оценивали разговор.
Теперь стало понятно, что часть результата создаётся до снятия трубки.
Менеджеру нужно проверить:
- были ли реальные работы;
- что именно выполнялось;
- чем завершилось сотрудничество;
- когда был последний содержательный контакт;
- нет ли активного проекта;
- не звонил ли другой сотрудник недавно;
- какой повод можно использовать.
Если история есть, появляется предмет разговора.
Если карточка пустая, нужен другой сценарий или исключение из текущего эксперимента.
Идеально очистить базу заранее было невозможно
Информация находилась не только в структурированных полях.
Она могла быть:
- в сделках;
- в комментариях;
- в задачах;
- в переписке;
- в памяти сотрудников.
Карточки создавались в разные годы и по разным правилам.
Отдельного процесса возврата клиентов не существовало.
Поэтому нельзя было одним фильтром получить идеальный список бывших клиентов.
Нужно было начать с минимальных признаков применимости.
Например, контакт выглядел подходящим, если:
- есть завершённая или содержательная сделка;
- понятен предмет предыдущего обращения;
- зафиксированы реальные работы;
- существует история разговора;
- найден ответственный сотрудник.
Дальше фильтры можно уточнять.
Текущие клиенты тоже искажали показатель
Аккаунт-менеджер мог звонить:
- по действующей задаче;
- для согласования документа;
- по техническому вопросу;
- по активному проекту.
В таком разговоре бесплатный аудит мог быть неуместен.
Система могла корректно отметить:
Аудит не предложен.
Но использовать этот факт для оценки критерия нельзя.
Менеджер не обязан произносить одну коммерческую формулировку в каждом контакте.
Поэтому нужно разделять:
- действующую работу;
- сервисные касания;
- возврат бывших клиентов;
- повторную продажу;
- реактивацию незавершённого обращения.
Уместность важнее формального выполнения
Если команда слышит:
Нужно предлагать аудит в каждом звонке,
показатель может начать расти формально.
Клиент звонит по счёту, а ему предлагают аудит.
Идёт текущий проект, а менеджер повторяет то же предложение.
Факт выполнения есть.
Бизнес-смысл теряется.
Поэтому критерий должен звучать так:
Менеджер предложил аудит в подходящем разговоре после понимания контекста клиента.
Это сложнее считать.
Но только такая формулировка сохраняет смысл.
Нулевой результат оказался полезным
Первые 30 звонков показали проблему раньше, чем мы масштабировали эксперимент.
Стало видно:
- база неоднородна;
- CRM-контакт не равен бывшему клиенту;
- условия руководителя и сотрудников различаются;
- массовый обзвон создаёт риск выгорания;
- показатель нельзя считать по всем звонкам;
- фильтрация должна быть частью управленческого цикла.
Если бы несколько случайных клиентов сразу согласились на встречу, мы могли бы дольше не замечать искажение.
Что мы сделали бы иначе сейчас
Разделили бы CRM на сегменты
- действующие клиенты;
- бывшие клиенты;
- незавершённые обращения;
- неуспешные лиды;
- контакты без истории;
- нецелевые карточки.
Выбрали бы один сегмент
Например:
Компании с подтверждённой историей работ, у которых сейчас нет активного проекта.
Зафиксировали бы признаки включения
Контакт попадает в эксперимент, если:
- история работы подтверждена;
- понятен предмет взаимодействия;
- нет недавнего содержательного звонка;
- нет активного сервисного процесса;
- доступен релевантный собеседник.
Подготовили бы карточку
До звонка менеджер должен видеть:
- что делали;
- когда;
- с кем;
- чем завершилось;
- какой повод можно использовать.
Начали бы с небольшой выборки
Не тысяча звонков, а 20-30 подготовленных контактов и короткий период.
Считали бы показатель только по применимым разговорам
Отдельно показывали бы:
- все звонки;
- применимые звонки;
- предложения;
- реакции;
- следующие шаги.
Следили бы за нагрузкой
Проверяли бы, сколько времени уходит на подготовку и не страдает ли текущая работа команды.
Главный вывод
Качество разговора нельзя отделить от качества выбранного контакта.
Можно настроить точный AI-анализ и разработать сильную рубрику.
Но если менеджер звонит компании без подтверждённой истории и без понятного повода, результат будет искажён.
Сначала нужно определить:
- кому звонить;
- почему звонить;
- в каких разговорах действие уместно.
И только затем оценивать, насколько последовательно сотрудник его выполняет.
После уточнения выборки у нас наконец появилась более чистая конструкция:
- подходящий контакт;
- понятный повод;
- одно действие;
- наблюдаемая реакция;
- следующий этап.
Следующая часть:
Мы перестали анализировать весь звонок и начали проверять один факт.
От анализа звонков к управляемому действию
- 10 Мы попросили AI отличить успешный звонок от неуспешного. Но сами не смогли показать ему разницу
- 20 Мы нашли десятки возражений клиентов. Управленческого ответа от этого больше не стало
- 30 Хороший промт начинается не с формулировок, а с правил оценки
- 40 Мы научились точнее оценивать звонки. Продажи от этого автоматически не изменились
- 50 Первые 30 звонков дали ноль. Проблема была не только в менеджерах
- 6 Скоро выйдет, приходите завтра