Опубликовано:
Содержание
Коротко: потому что лиды уже есть — они теряются дальше, в звонке, где их никто не считает.
Маркетолог отчитался: заявок на 30% больше, цена лида ниже плана. Через месяц коммерческий директор смотрит на выручку — она почти не сдвинулась.
Первый вывод напрашивается сам: «нужно ещё больше лидов». Но лиды уже есть. Они уходят в разговор менеджера с клиентом — на участок, который не виден ни в одном отчёте.
Дальше — семь конкретных точек, где клиент отваливается, даже если менеджер формально «отработал» лид. У всех семи общая черта: они невидимы в CRM.
Коротко: CRM фиксирует, что действие произошло, но не фиксирует, было ли оно результативным. «Звонок состоялся» и «звонок продвинул клиента к сделке» — в отчёте это одна и та же строка.
| Этап звонка | Что видит CRM | Что теряется незаметно |
|---|---|---|
| Выявление потребности | «звонок состоялся» | вопросы не заданы, клиент не услышан |
| Презентация | «контакт», длительность | рассказ «про продукт вообще», мимо задачи клиента |
| Работа с возражением | статус «в работе» | скрытый отказ, смена тона — без реакции |
| Фиксация следующего шага | «перезвонить позже» | нет конкретной даты — лид подвисает |
| Завершение | «разговор завершён» | закрыт раньше, чем клиент был готов |
Всё, что в правой колонке, в отчёт не попадает. Дальше — разбор по каждой строке плюс два системных паттерна, которые видно только на объёме.
Коротко: пять потерь сидят на конкретных этапах дерева оценки, ещё две — это системные паттерны, заметные только на массиве звонков. Разбор по порядку.
Скрипт предполагает, что перед презентацией менеджер выясняет, что нужно клиенту. На практике этап часто сводится к одному-двум общим вопросам, после которых менеджер уходит в заготовленную презентацию — независимо от ответов.
Клиент слышит рассказ о продукте, который не учитывает то, что он только что сказал. Ощущение «меня не услышали» формируется в первые минуты. Дальше менеджер продаёт уже вопреки этому ощущению, а не на его основе.
Даже если потребность выявлена нормально, презентация может идти по шаблону — «про продукт в целом», а не «про то, как продукт решает именно вашу задачу, о которой вы сказали минуту назад».
В этот момент клиенту кажется, что он говорит с автоответчиком. Решение «подумаю» принимается именно здесь — а прозвучит позже, при попытке завершить звонок.
Возражение — это не всегда явное «дорого». Чаще это пауза, смена тона, короткие ответы, «надо подумать» — то, что системы анализа звонков фиксируют как смену эмоционального фона или скрытый отказ.
Менеджер продолжает «как ни в чём не было», не возвращаясь к сомнению. Формально клиент остаётся «в работе». По факту разговор закончился для него ещё на той паузе.
Этап «фиксация следующего шага» пропускают чаще других: он требует прямого действия — договориться о конкретной дате и формате следующего контакта, а не закончить на «хорошо, я подумаю».
Без договорённости звонок считается состоявшимся, но следующий шаг зависит от того, вспомнит ли клиент сам. На объёме это десятки и сотни подвешенных лидов, которые тихо выпадают из воронки — те самые, за которые маркетинг уже заплатил.
Обратная ситуация. Менеджер, стараясь не «навязываться», завершает разговор при первой нейтральной фразе — не убедившись, что вопросов не осталось. Часть клиентов в этот момент готова задать ещё один вопрос, который снял бы последнее сомнение. Но разговор уже закончен, и они уходят «думать» с невысказанным вопросом.
Этот паттерн виден только при системном разборе массива звонков. Первые этапы — приветствие, начало выявления потребности — соблюдаются стабильно: они отработаны почти автоматически. А этапы ближе к концу — работа с возражением, фиксация следующего шага, корректное завершение — проседают, особенно если разговор пошёл не по удобному сценарию.
По одному звонку этого не увидеть. На масштабе — это системная утечка, сосредоточенная во второй половине разговора.
При одинаковом скрипте этапы выполняются по-разному. «Выявление потребности» у одного менеджера — это два содержательных вопроса с уточнениями, у другого — формальное «что вас интересует?». Формально оба «выполнили этап». По влиянию на решение клиента — это два разных разговора.
Без единого измеримого стандарта эта разница остаётся «личным стилем» — и устойчиво влияет на то, у кого реальная конверсия выше, даже когда KPI по числу звонков у всех одинаковый.
Коротко: между «скрипт написан» и «скрипт соблюдается на каждом звонке» лежит дистанция, которую не закрыть выборочной прослушкой.
На ручной контроль уходит 1–8 часов РОПа в неделю при ставке порядка 1–1,5 тыс. ₽/час — и даже верхняя планка покрывает лишь единицы процентов звонков. Очевидный ответ — «пусть РОП слушает звонки». Но остальные 90%+ остаются непроверенными. Получается простое правило:
Выборочная прослушка ловит ошибки там, где успел послушать. Системная утечка живёт в тех 90% звонков, до которых руки не дошли.
Почему даже добросовестный РОП физически не закрывает этот объём — разобрали отдельно: «РОП тонет в прослушке». А как эти семь причин выглядят в реальном кейсе, где компания с трафиком на 10 млн ₽ нашла утечку именно на стыках этапов — в разборе кейса Take&Wake.
Коротко: до правки скрипта «на глаз» — понять, какие из 7 причин актуальны именно у вас, и для этого разобрать не выборку, а все звонки по чек-листу.
Это даёт картину, которую выборочная прослушка не показывает. Прежде чем менять скрипт или запускать очередное обучение, стоит понять, какие из этих семи причин проявляются системно, а не разово. Как разбор всех звонков по чек-листу устроен без расширения штата ОКК — описано здесь: система оценки звонков без раздувания штата.
Если хотите получать такие разборы воронки звонков по мере выхода — мы публикуем их в блоге регулярно, по одной точке утечки за раз.