Аналитик Dmitry Nercy опубликовал на Хабре кейс с заголовком «Каждому клиенту ответили, а сделки застревают в конце воронки». Он разобрал CRM-воронку кросс-бордер сервиса по данным за три года и показал, куда девается разница между растущим потоком лидов и не растущими деньгами. Материал короткий — сам Хабр помечает его как чтение на пять минут, — но цифр в нём больше, чем в большинстве длинных статей про продажи.
Ценность кейса не в выводе «надо дожимать клиентов». Она в том, что автор показывает механику: как система, у которой все привычные показатели в норме, каждый год хоронит тысячи оплаченных заявок, и почему этого не видно ни руководителю, ни аналитику с полным доступом к базе.
Ниже — содержание разбора: как выглядит путь одной заявки, откуда берётся затор, кто в это время приносит деньги, почему метрики показывают здоровье и что автор предлагает делать дальше. Тезисы в этом конспекте — утверждения автора кейса по данным одной компании, а не проверенный факт для всех.
CRM-воронка на примере одной заявки
Автор берёт одну типичную заявку — по его словам, не худшую и не лучшую — и прослеживает её целиком.
День нулевой: клиент пишет, срабатывает автоответ. Через час приходит первое сообщение менеджера. На второй день робот по таймеру переводит заявку в статус «дожим», менеджер пишет ещё раз и сам переводит её во второй дожим. Дальше — двадцать дней без единого сообщения с любой стороны.
После этого заявка просто лежит. Месяц, два, четыре. Таких накапливаются тысячи, они начинают мешать работе с новыми обращениями и грузить систему. Поэтому воронку периодически чистят — обычно в конце осени: один сотрудник за один день закрывает 3–3,5 тысячи заявок. Причина отказа почти ни у одной не указана.
Автор отдельно снимает вопрос вины исполнителя: саботажа и лени он здесь не видит. Сотрудник делает ровно то, что от него ждут, — чистит воронку, которую никто не успевает разобрать.
Откуда берётся затор: поток выше мощности отдела
Второй смысловой блок кейса — причина. Поток лидов стабильно выше, чем отдел способен переварить. За день в чатах проходит 200–300 диалогов, из них новых заявок около 80. Остальное — постоянные клиенты, вопросы по текущим заказам, статусы. Закреплённых ролей нет: чаты делятся по ситуации, каждый берёт то, что пришло, в рамках своих навыков.
Больше половины входящих сообщений обрабатывает бот. Он закрывает первичку: отвечает сразу, в том числе ночью, собирает базовые данные. Сотрудник заходит в чат, где первичная обработка уже сделана. Автор прямо говорит, что без бота отдел при таком потоке буксовал бы уже на первом ответе.
Но узкое место от этого не исчезло, а сдвинулось в середину воронки. Руководитель платит за маркетинг и, чтобы оправдать затраты, направляет силы на встречу новых клиентов. Всё остальное идёт по остаточному принципу. В цифрах: на новых клиентов уходит 61% сообщений отдела, а заявке на дожиме в будний день человек пишет только в 6,6% случаев.
Логика руководителя при этом не нарушена: за лид заплатили — лид должен получить ответ. Автор указывает, что проблема в самой постановке цели. Отделу поставили задачу быстро отвечать новым, а довести клиента до оплаты в эту задачу не записано. Он ссылается на теорию ограничений Голдратта: маркетинг производит больше, чем продажа способна обработать, и излишек превращается в склад.
Кто приносит деньги, пока продажа не успевает
Если продажа не справляется, откуда выручка. Автор делит все оплаты входящих заявок на три группы:
- около половины приносят постоянные клиенты — они платят почти в три раза чаще новых и сразу уходят в производство;
- около четверти дают новые клиенты, оплатившие в первые три дня: они сами написали и сами инициировали отправку;
- ещё около четверти дают новые клиенты, которых действительно довела продажа.
Вывод автора: продажа работает, но примерно на четверть своей задачи — на остальное у неё нет времени. Постоянники составляют четверть входящего потока, а приносят половину денег. И обходятся дешевле: на одну оплату постоянного клиента уходит около 8 сообщений отдела, нового — около 26.
То есть бизнес держится на постоянных клиентах и на тех, кто купил бы и без продажи. Остальные заявки, за которые заплатил маркетинг, уходят в очередь.
Почему со стороны всё выглядит здоровым
Отдельный блок кейса — про то, почему проблему не видно по сводкам. Если смотреть на привычные показатели, чинить нечего: первый ответ приходит за 15 минут в рабочее время, поток за три года вырос в разы, конверсия тоже подросла. Автор тут же оговаривается, что часть роста потока дали пачки заявок, которые создавал бот.
Сверху ложится высокая маржа. При заработке 40–50% с заказа компания может терять большую часть лидов и оставаться в плюсе. Дыры не исчезают, они просто не видны — и всплывают все сразу, когда падает поток или маржа.
Есть и вторая причина невидимости: проблема стирает свои следы. Автор рассказывает, как сначала попросил ИИ-агента посчитать, сколько заявок висит на дожимах, и получил ответ «сотни, не тысячи». Цифра не совпала с тем, что он знал о процессе, и он поднял историю. Оказалось, что срез попал на момент сразу после очередной чистки. Ретроспектива за три года дала другую картину: перед каждой чисткой в воронке висело от 2,8 до 4,5 тысяч открытых заявок, и 80–90% из них не двигались больше месяца.
Ключевое наблюдение автора из этого эпизода: если аналитик с полным доступом к CRM не увидел проблему на одном снимке, владелец по вечерней сводке не увидит её тем более.
Что даёт возврат «мёртвых» заявок и где данные хромают
В компании однажды пробовали вернуть заявки из мусора: заново открыли около двух тысяч «мёртвых» сделок. До оплаты дошли 5–7% — примерно сотня заказов. У заявок, которые не трогали, тот же показатель составляет 0,2–0,3%, разница в двадцать раз.
Автор не выдаёт это за золотую жилу: в абсолютных цифрах сотня заказов — немного. Важен сам факт, что внимание работает даже через четыре месяца. А в первые недели работает лучше: заявка со второго дожима доходит до оплаты примерно в каждом пятом случае. Отсюда его вывод о моменте смерти заявки — она умирает не при чистке, а на второй день, когда заканчивается переписка. Чистка только фиксирует то, что уже случилось.
Ограничения данных автор перечисляет сам, и для конспекта это важная часть:
- звонки в CRM не записываются, поэтому при отсутствии переписки контакт всё же мог быть;
- когда клиент пишет из другого мессенджера, CRM создаёт нового клиента — значит, часть «новых» на самом деле повторные, и реальная доля постоянников выше;
- переписка доступна только за последние месяцы, поэтому связку «два дня переписки, потом похороны» для прошлых лет автор вывел логически, а не измерил.
Он также отмечает, что мощность отдела сейчас посчитать нельзя: в CRM не видно, кто фактически ведёт клиента, звонки не записываются, а разница в результатах менеджеров во многом объясняется тем, кому достались постоянники.
Поэтому вместо готового решения в кейсе — план измерения. Бот уже держит первичку, значит людей можно снять с гонки за первым ответом и отдать им то, чего бот не умеет: доведение до оплаты. Порядок автор предлагает такой: выделить часть отдела с другой задачей — доводить клиента до оплаты; распределять этой группе лиды случайно, не подбирая ни сильных сотрудников, ни удачные заявки, иначе результат окажется завышенным; через месяц посмотреть, сколько заявок в среднем доводит один человек; экстраполировать на весь отдел; сравнить с потоком и понять, насколько маркетинг перепроизводит лиды.
Когда разрыв посчитан, решений он видит два: покупать меньше лидов либо сделать вход, который переводит клиента в работу без продажи — через консультацию и сразу в производство. Второй вариант он оставляет на отдельную статью. И сразу говорит, что писать «мы всё починили» не будет: пока проблему только увидели.
Коротко
- Заявка в разобранной воронке умирает на второй день, когда заканчивается переписка; чистка на 3–3,5 тысячи сделок за день только оформляет уже случившееся.
- Причина не в людях, а в цели: отделу поставили задачу быстро отвечать новым, доведение до оплаты в задачу не входит. На новых уходит 61% сообщений, на дожим в будний день — 6,6%.
- Деньги при этом приносят постоянные клиенты (половина оплат при четверти потока) и те новые, кто оплатил сам в первые три дня; собственно продажа доводит примерно четверть оплат.
- Привычные метрики показывают здоровье: ответ за 15 минут, рост потока, рост конверсии, маржа 40–50%. Дыра не видна, пока поток и маржа держатся.
- Возврат старых заявок даёт конверсию 5–7% против 0,2–0,3% у нетронутых, а заявка со второго дожима доходит до оплаты примерно в каждом пятом случае.
Что из этого следует
Кейс применим там, где входящий поток обрабатывается людьми и где на первый ответ уже поставлен бот или автоответчик. Автоматизация первого шага не убирает узкое место, а перемещает его дальше по процессу — и метрики, придуманные под старое узкое место, нового не показывают. Скорость первого ответа продолжает расти, пока сделки копятся в середине воронки.
Полезен и метод: автор поймал ошибку, потому что не поверил одному срезу данных. Один снимок воронки после чистки показал «сотни», ретроспектива за три года — тысячи. Любая метрика, которую периодически «обнуляют» ручной операцией, будет врать в момент замера, и сверять её нужно историей, а не текущим состоянием.
Что стоит проверить у себя: сколько в системе открытых сделок, по которым не было ни одного действия больше месяца; кто и на каком основании закрывает их пачками; указывается ли причина отказа; какая доля оплат приходит от повторных клиентов и какая — от тех, кого действительно довели. И отдельно — записана ли в задачу сотрудника доведение до результата или в ней стоит только скорость реакции.
Отдельно это читается как напоминание для любого конвейера, где машина взяла на себя первый этап. У нас это производство контента, у автора кейса — продажи, но механика одна: пока вход разогнан, а следующий шаг остаётся человеческим и неизмеренным, разница между этими скоростями превращается в склад незавершённой работы. И считать надо не скорость входа, а пропускную способность самого узкого места.
Разборы воронок и процессов автор кейса публикует в своём Telegram-канале Nercy.
Источник: Каждому клиенту ответили, а сделки застревают в конце воронки. Разобрал CRM за три года