Совещание по продажам, план снова не добран, и директор задаёт вопрос, на который в комнате уже готовы противоположные ответы: продавцы говорят, что заявок мало, маркетинг говорит, что заявки приходят плохие, и у каждой стороны есть свой убедительный график.
Я в такие минуты открываю выгрузку из CRM и смотрю на даты смены статусов, потому что воронка продаж, разложенная на этапы по фактам, отвечает на этот спор сама и без повышенных голосов. Графики обеих сторон при этом обычно верные, просто они про разное.
За годы во внутреннем аудите я привыкла смотреть на любой процесс со стороны журнала событий: что произошло, когда и кто это зафиксировал. Продажи здесь ничем не отличаются от закупок или согласования договоров, и потери в них видны точно так же, если знать, в каких столбцах их искать.
Любая цепочка шагов теряет людей по дороге
Перед тем как сесть за эту статью, 24 сентября я заглянула в поиск Дзена по запросу "воронка продаж": там нашлось 20 материалов, заметный охват получили 4, у самого читаемого 4650 просмотров, и дочитывают его до конца далеко не все, кто открыл.
Это тоже воронка, только читательская: материал нашли, открыли, начали читать, дочитали, и на каждом переходе часть людей молча уходит. Автор видит итоговые просмотры, но в какой момент читатель закрыл вкладку, на втором экране или на середине таблицы, по одной этой цифре понять невозможно.
С продажами устроено так же: выручка за месяц это последняя строка отчёта, а потери случились раньше, на конкретном переходе между этапами, и у этого перехода есть свой владелец, своя причина и своя цена в рублях.

Почему привычные этапы ничего не показывают
Откройте настройки своей воронки и прочитайте названия этапов вслух: чаще всего там стоят "Презентация", "Переговоры" и "Думает", и каждое из них описывает настроение менеджера, которое никак нельзя проверить по журналу.
Сделка может неделями стоять в "Переговорах", хотя последний разговор с клиентом был очень давно, и отчёт честно покажет её живой и перспективной. Воронка, в которой сделки никогда не умирают, выглядит прекрасно ровно до конца квартала.
Вторая причина слепоты в том, что этап назначают по действию продавца: позвонил, отправил, напомнил, снова напомнил. Клиент при этом мог ничего не сделать, и сделка формально продвинулась по воронке, хотя по сути осталась там же, где была неделю назад.
Правило, которое я применяю при любой разметке этапов, звучит так: переход засчитывается только тогда, когда произошло событие со стороны клиента или денег, которое можно показать в журнале системы, в почте или в банковской выписке.

Как разложить воронку на этапы по событиям
Начните с конца, с поступления денег, и идите назад, спрашивая у каждого шага, какое событие без него невозможно. Для типичной продажи услуг цепочка выглядит так: заявка получена → первый разговор состоялся → потребность и бюджет подтверждены → предложение отправлено и открыто → счёт выставлен → оплата пришла.

Каждому этапу нужны условие входа, условие выхода, владелец и нормальный срок пребывания, после которого сделка считается зависшей. Без этого набора этап превращается в папку, куда складывают сделки, чтобы они не мешали на рабочем столе.
Отказы тоже этап, и вести его нужно с причиной. В документации amoCRM по воронкам и статусам у каждой воронки есть системные статусы для успешно закрытой сделки и для закрытой без результата, и именно второй чаще всего превращается в свалку без единого комментария.
Причина отказа должна выбираться из короткого списка, который вы составили заранее: дорого, выбрали конкурента, пропала потребность, не дозвонились. Свободный комментарий читают только на разборе отдельной сделки, а по списку можно посчитать, какая причина съедает больше всего денег.
Последнее условие касается истории: в CRM должен вестись журнал смены статусов с датой и временем каждого перехода, потому что таблица потерь строится именно по нему. Текущий статус показывает, где сделка находится сейчас, а история показывает, сколько она шла и откуда возвращалась.
Где прячутся потери между этапами
Когда этапы размечены по событиям, потери раскладываются на несколько видов, и у каждого своя механика, поэтому лечить их одним приказом "работать активнее" бесполезно, как бы решительно он ни звучал.

Утечка означает, что сделка ушла в отказ на конкретном этапе. Её видно по конверсии перехода и по причинам отказа, и это самая честная потеря из всех, потому что её хотя бы зафиксировали в системе.
Застой означает, что сделка стоит на этапе дольше нормального срока и не движется ни вперёд, ни в отказ. Такие сделки раздувают воронку и создают иллюзию запаса, который на деле давно остыл и в выручку уже не превратится.
Возврат означает, что сделка прыгает назад, например из счета обратно в предложение, потому что клиент попросил пересчитать. Единичный возврат нормален, а регулярные возвраты на одном и том же переходе говорят о том, что предыдущий этап закрывают раньше времени.
Дыра до системы возникает, когда заявка пришла в мессенджер или на почту и не попала в CRM вовсе. В отчётах её нет, поэтому её потерю никто не считает, и по моему опыту аудита деньги здесь уходят тише всего.

Цвет этапа удобно считать по паре показателей сразу: конверсии перехода и медианному времени на этапе. Конверсия без времени обманывает, потому что зависшие сделки формально ещё не проиграны, и этап выглядит зелёным, пока их не закроют задним числом одной большой пачкой.
Таблица потерь: шаблон для еженедельного разбора
Ниже структура таблицы, которую я собираю по журналу смены статусов. Одна строка соответствует одному этапу воронки, столбцы идут слева направо, и перенести её можно в любую электронную таблицу, которой вы уже пользуетесь.
- Этап: название этапа.
- Событие входа: что должно произойти, чтобы сделка сюда попала.
- Событие выхода: что должно произойти, чтобы она перешла дальше.
- Владелец: должность того, кто отвечает за этап.
- Вошло сделок: число за период.
- Вышло вперёд: число за период.
- Ушло в отказ: число за период.
- Висит дольше нормы: число сделок.
- Вернулось назад: число сделок.
- Медианное время на этапе: дни.
- Главная причина отказа: причина из списка.
- Стоимость потери: рубли.
Над таблицей одной строкой: период (неделя или месяц), название воронки, норма срока этапа в днях и средний чек в рублях.
Считается таблица по нескольким формулам, и все данные для них уже лежат в вашей системе, их нужно только выгрузить за нужный период:
- Конверсия перехода: вышло вперёд, делённое на вошло; берём из журнала смены статусов за период; пример: из [N] сделок на этапе "Предложение отправлено" до счета дошли [M].
- Доля застоя: сделки, пробывшие на этапе дольше нормы, делённые на вошедшие; берём разницу между датой входа и датой выхода или сегодняшним днём; пример: [K] сделок висят на "Счёте" дольше [дни].
- Медианное время: середина ряда длительностей по всем сделкам этапа; берём те же даты входа и выхода; пример: типичная сделка проходит этап за [дни].
- Стоимость потери: ушедшие в отказ и зависшие сделки, умноженные на средний чек и на сквозную конверсию следующих этапов; чек берём из оплат, конверсию из соседних строк этой же таблицы; пример: [N] сделок × [средний чек] × [конверсия до оплаты].
- Главная причина: самая частая причина отказа на этапе; берём из обязательного поля причины; пример: на этапе "Предложение отправлено" чаще всего выбирают "дорого".
Медиана здесь выбрана сознательно: среднее время на этапе ломает единственная сделка, которую забыли закрыть с прошлой весны, а медиана к такой забывчивости равнодушна. Аудиторы любят медиану примерно по той же причине, по которой не любят слово "обычно".
Читать таблицу стоит с последнего столбца: разбор начинается с этапа, где стоимость потери самая большая, даже если его конверсия выглядит прилично. Там, где низкая конверсия совпадает с ростом времени, ищите процессную причину: нет шаблона предложения, скидку согласуют слишком долго, менеджер ждёт юриста.
Если журнал смены статусов у вас ведётся, собирать эту таблицу руками каждую неделю незачем: её может собирать скрипт, который сам забирает события из CRM и присылает разбор руководителю. Такие отчёты я настраиваю при внедрении CRM.
Вопросы про воронку продаж, которые задают чаще всего
Сколько этапов должно быть в воронке продаж?
Столько, сколько в вашей продаже есть проверяемых событий со стороны клиента или денег, и ни одним больше. Если между соседними этапами нет события, которое можно показать в журнале, их стоит объединить, а если внутри этапа сделки застревают по разным причинам, его имеет смысл разделить.
Как посчитать конверсию воронки продаж по этапам?
Конверсия этапа считается как число сделок, перешедших на следующий этап, делённое на число вошедших в этот этап за тот же период. Считать её надо по журналу смены статусов, потому что текущий статус не показывает сделки, которые уже прошли дальше или вернулись назад.
Чем воронка продаж отличается от отчёта по сделкам?
Отчёт по сделкам показывает, сколько сделок и на какую сумму стоит на каждом этапе прямо сейчас, а воронка показывает, как сделки двигались между этапами за период. Для поиска потерь нужна вторая картина, потому что застой и возвраты в моментальном снимке просто не видны.
Что делать со сделками, которые давно висят на одном этапе?
Разобрать их одним заходом и по каждой принять решение: следующий шаг с конкретной датой или отказ с причиной из списка. После этого стоит ввести норму срока для этапа и автоматическое напоминание владельцу, иначе через месяц список зависших сделок наберётся заново.
Что проверить у себя сегодня
- Каждый этап назван событием, которое можно показать в журнале системы, в почте или в выписке.
- У отказа есть обязательное поле причины со списком вариантов, свободный текст не принимается.
- Журнал смены статусов включён и хранит дату и время каждого перехода.
- У каждого этапа записаны владелец и нормальный срок пребывания.
- Заявки из мессенджеров и почты попадают в CRM автоматически или по записанному регламенту.
- Сделок, висящих дольше нормы, меньше, чем сделок, закрытых за тот же период.
Если по большинству пунктов ответ положительный, таблица потерь соберётся за вечер, и уже на следующем совещании спор про плохие заявки сменится разговором о конкретном переходе с конкретной ценой. На каком этапе ваша воронка, по ощущениям, теряет больше всего, и готовы ли вы проверить это по журналу?
Новые разборы выходят в моём канале: t.me/promaren.
Автоматизация воронок продаж
Лид от комментария до оплаты без ручного менеджера, запуск за 10–14 дней
Первоисточники
Частые вопросы
Сколько этапов должно быть в воронке продаж?
Столько, сколько в вашей продаже есть проверяемых событий со стороны клиента или денег. Если между этапами нет события, которое можно показать в журнале, их стоит объединить.
Как посчитать конверсию воронки продаж по этапам?
Число сделок, перешедших на следующий этап, делят на число вошедших в этап за тот же период. Считать надо по журналу смены статусов, потому что текущий статус не показывает прошедшие дальше и вернувшиеся сделки.
Чем воронка продаж отличается от отчёта по сделкам?
Отчёт показывает, сколько сделок стоит на каждом этапе сейчас, воронка показывает, как они двигались между этапами за период. Застой и возвраты видны только во второй картине.
Что делать со сделками, которые давно висят на одном этапе?
Разобрать их одним заходом и по каждой принять решение: следующий шаг с датой или отказ с причиной. Затем ввести норму срока этапа и напоминание владельцу.

Марина Погодина, основатель PROMAREN
17 лет в ИТ и управлении технологическими рисками, из них 14 лет в аудите ИТ и внутреннем контроле. Более 60 аудитов ИТ и информационной безопасности.








