директор и машина · продажи · запись № 010 · 25 июня 2026 · Давид Герштейн

Прогноз продаж, которому можно верить: воронка вместо ощущений

Неделя 14–20 мая. План по деньгам выполнен на 80%. Закрыли 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. Конверсия во встречу нормальная, 55%, а вот из встречи в договор — только 22%. Руководитель отдела продаж прямым текстом: «Тут уже мне становится страшно, я начинаю переживать конкретно». За недостающими 20% плана стоят не абстрактные проценты, а конкретные девять сделок, которые должны были закрыться и не закрылись.

Это и есть прогноз продаж по воронке в чистом виде. Не «в этом месяце должны сделать миллион, потому что обычно делаем», а разложенная по этапам математика: сколько лидов, какая конверсия на каждом шаге, сколько денег получится на выходе. Когда цифры разложены так, страх появляется на пятый день недели, а не на тридцатый день месяца — когда уже поздно что-то менять. Дальше в статье — как считать этот прогноз руками, какой промпт можно скопировать для еженедельной диагностики узкого места, во сколько обходится зависшая сделка и где эта система обычно ломается.

Прогноз продаж по воронке против прогноза «на глазок»

Классический прогноз продаж строится так: руководитель спрашивает у менеджеров, сколько они закроют в этом месяце, складывает ответы и докладывает наверх. Это работает, пока воронка стабильна. Как только что-то меняется — состав отдела, источник лидов, сезон — прогноз «на глазок» начинает врать, и врёт он всегда в оптимистичную сторону, потому что менеджер отвечает на вопрос «сколько ты хочешь закрыть», а не «сколько у тебя реально в пайплайне со сроком».

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

Конверсия продаж по этапам: где именно теряются деньги

Отдельная цифра «конверсия 25%» ничего не говорит о том, что делать. Разбивка по этапам — говорит. В майском примере разница между планом и фактом была не в количестве лидов и не во встречах — там всё было в норме. Проблема сидела на переходе от встречи к договору: 55% встреч состоялось, но только 22% из них закрылись договором. Значит причину нужно искать не в лидогенерации и не в графике встреч, а в том, что происходит на самой встрече и сразу после неё. На диаграмме ниже — конверсия по каждому этапу воронки за неделю 14–20 мая в сравнении с плановой конверсией лид→продажа.

Формула прогноза по воронке простыми словами: продажи = число лидов × конверсия лид→встреча × конверсия встреча→договор × конверсия договор→оплата × средний чек. На примере недели 14–20 мая, где в источнике зафиксирован не весь набор величин: 49 встреч при конверсии лид→встреча 55% означают около 89 лидов в работе (49 ÷ 0,55 — оценка, точное число лидов не зафиксировано). Из 49 встреч конверсия 22% даёт около 11 договоров (49 × 0,22). Но оплатой закрыли только 7 сделок — то есть ещё 4 договора из 11 за неделю не дошли до денег: они либо повиснут на следующей неделе, либо уйдут в отказ. Без разбивки по этапам эта картина не видна вообще — на выходе была бы одна цифра «7 из 16» без понимания, где именно теряются четыре уже подписанных договора.

Любопытная деталь: средний чек выше плана. Это значит, менеджеры не проседают в презентации ценности дорогих пакетов — они проседают именно на переходе к подписанию. По другому кейсу той же компании: конверсия 25–28% держалась три месяца подряд, и руководитель прямо сказал — если так продолжится, меняю структуру мотивации и все рекомендации отдаю отделу с конверсией 80%. Жёстко, но честно: он смотрел не на факт продаж, а на то, где именно теряется процент.

Ещё пример того, как этап-специфичная причина маскируется под «плохой месяц»: отдел отвлёкся на апсейл по одному направлению и почти забросил холодные звонки. Вместо плановых 60+ звонков новым контактам сделали в разы меньше. При этом повторное касание по нескольким десяткам тёплых лидов месячной давности дало несколько рекомендаций. Вывод руководителя: одного звонка недостаточно, нужна регулярная работа с базой. Без разбивки по этапам этот вывод было бы невозможно сделать — просто увидели бы «продажи ниже плана» и не поняли почему.

Отдельно стоит случай, когда конверсия отдела внезапно упала до 30% при ожидаемых 50%. Разбор занял не неделю, а около пяти минут — но не потому, что кто-то угадал причину, а потому, что дашборд уже был разбит не только по этапам, но и по источникам сделок. Первая же строка среза по источникам показала: просадка сосредоточена в одном канале холодных лидов, где менеджеры физически перестали успевать доводить контакт до встречи — остальные источники держали плановую конверсию. Без такой разбивки эту же причину пришлось бы искать вручную, поднимая карточки по каждому менеджеру — отсюда и оценка «неделя ручного разбора» в таблице ниже.

О том, как теряются деньги между маркетингом и продажами на более раннем этапе — в статье «Лиды есть, а продаж нет».

Дашборд вместо памяти: механика по шагам

Прогноз по воронке требует данных, которые не устаревают за неделю. Разовый отчёт для планёрки — это фотография прошлого. Нужен инструмент, который обновляется постоянно и показывает не только «сколько продали», а «что застряло и почему». Механика такая:

1. Что → сырые данные о сделках (этап, дата создания, дата последнего движения, менеджер, сумма, источник) забираются из CRM.
2. Чем → Google Apps Script или прямой вебхук CRM по расписанию складывает срез в таблицу, где считаются конверсии по этапам, разбивка по источникам и дни без движения.
3. Куда → результат попадает на дашборд с интеграцией «клик по строке → карточка сделки», чтобы не искать её отдельно.
4. Кто и когда смотрит → руководитель — ежедневно по светофору, собственник — на еженедельном разборе плана/факта.

В одной компании собрали именно такой дашборд: pipeline по каждому менеджеру, конверсия из договора в оплату, дата последнего контакта, источник сделки. Детализация по месяцам показывает заброшенные сделки без касаний ещё до того, как они превратятся в потерянный доход.

Потом руководитель заказал динамический отчёт по воронке с обновлением каждый час. Для каждого менеджера он показывает клиента, текущий статус, дату создания сделки, число дней в статусе и светофор — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Идея простая: если сделка на этапе «договор» висит дольше нормы, система красит её красным раньше, чем это заметит человек на планёрке. Вот как такой отчёт выглядит на практике для недели 14–20 мая:

Похожая логика — в отдельном дашборде по договорам: имя менеджера, имя клиента, сумма, дата выставления счёта, была ли встреча. Это позволяет видеть закономерность — сделки после встречи закрываются иначе, чем без неё — и дожимать конкретные неоплаченные договоры адресно, а не общим напоминанием «оплатите, пожалуйста». Про системный контроль оплат — в статье «Дебиторка растёт: контроль, который не зависит от памяти людей».

В итоге вместо двух-трёх разрозненных отчётов получился один интерактивный портал: все договоры по источникам, пайплайн по месяцам, оплаты и выставленные счета по каждому сотруднику. Логика владельца была простой: «Чем мне создавать два отчёта? Мне проще создать один» — и именно на этом портале был найден за пять минут кейс с падением конверсии до 30%, описанный выше.

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

ИИ-связка: промпт, который диагностирует узкое место за вас

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

Схема конвейера: CRM (amoCRM API или Bitrix24-вебхук) → почасовой снимок сделок в Google Sheets → раз в неделю сборка JSON по каждому менеджеру → запрос к дешёвой модели (класс gpt-4o-mini или аналог) → ответ пишется обратно в таблицу и дублируется в чат руководителя. Входные данные на менеджера выглядят так — это не гипотетический пример, а структура, которую реально собирает Google Apps Script по расписанию раз в неделю:

Входные данные (JSON, один объект на менеджера, собирается скриптом из Google Sheets):

{
  "manager": "Петров",
  "week": "2026-05-14/2026-05-20",
  "stages": {
    "lead_to_meeting": {"plan": null, "fact": 0.55, "count": 49},
    "meeting_to_contract": {"plan": 0.23, "fact": 0.22, "count": 11},
    "contract_to_payment": {"plan": 0.85, "fact": 0.64, "count": 7},
    "lead_to_sale": {"plan": 0.23, "fact": 0.14}
  },
  "avg_check_vs_plan": 1.35,
  "deals_stuck_over_norm_days": [
    {"deal_id": "D-1042", "stage": "contract", "days_in_stage": 12, "norm_days": 5}
  ]
}

---

Промпт для модели:

Ты — аналитик отдела продаж. Тебе дан JSON с фактической и плановой конверсией
по этапам воронки для одного менеджера за неделю.

Правила:
1. Не придумывай причины, которых нет в данных. Если данных недостаточно
   для вывода — так и напиши в поле "comment": "недостаточно данных".
2. Найди этап с максимальным отрицательным отклонением факта от плана
   в процентных пунктах. Если у этапа нет плана (null), не считай его
   узким местом только по этой причине.
3. Если в deals_stuck_over_norm_days есть сделки старше нормы — упомяни
   их количество отдельно, это не то же самое, что просадка конверсии.
4. Не советуй ничего, что не следует напрямую из цифр (без общих фраз
   вида "нужно больше стараться").

Верни строго JSON без пояснений вне JSON:
{
  "manager": "...",
  "problem_stage": "...",
  "deviation_pp": число,
  "stuck_deals_count": число,
  "comment": "1-2 предложения, только по цифрам",
  "recommended_action": "1 конкретное действие"
}

Пример ответа модели на входные данные выше:

{
  "manager": "Петров",
  "problem_stage": "contract_to_payment",
  "deviation_pp": -21,
  "stuck_deals_count": 1,
  "comment": "Конверсия договор→оплата 64% при плане 85%, отклонение -21 п.п. Одна сделка (D-1042) висит на этапе договора 12 дней при норме 5.",
  "recommended_action": "Разобрать сделку D-1042 сегодня: узнать причину задержки оплаты и зафиксировать срок."
}

Обратите внимание: модель не сказала «менеджер плохо работает» — она указала конкретную сделку и конкретное отклонение. Это и есть разница между диагностикой и оценочным суждением. Дальше решение принимает человек: разговор с менеджером, звонок клиенту, пересмотр скрипта — но повестку для этого разговора формирует не память руководителя, а цифра.

Инженерная обвязка, без которой промпт ломается на третьей неделе:

• Расписание запуска — раз в неделю, в фиксированный день и час (например, понедельник 8:00), до планёрки, а не после.
• Если в срезе за неделю у менеджера меньше 5 сделок на этапе — модель должна писать «недостаточно данных», а не достраивать вывод по единичному случаю. Это правило зашито в промпт отдельным пунктом, а не оставлено на усмотрение модели.
• Сырой ответ модели логируется отдельной строкой рядом с итоговым JSON — если через месяц вывод покажется странным, можно проверить, на каких именно цифрах он основан.
• Числовые поля в ответе (deviation_pp, stuck_deals_count) валидируются скриптом перед записью в таблицу: если модель вернула не число или пустое поле — строка помечается для ручной проверки, а не публикуется как есть.
• Стоимость такого прогона на класс моделей gpt-4o-mini при отделе из нескольких менеджеров и одном запуске в неделю — предмет отдельного разговора: подробный разбор счетов за ИИ в инфраструктуре продаж — в статье про контроль качества звонков без ОКК, там похожая экономика на других объёмах.

Экономика: во сколько обходится зависшая сделка

Возьмём иллюстративный расчёт, не привязанный к конкретной компании из фактуры выше, — чтобы читатель мог повторить его на своих цифрах. Отдел из нескольких менеджеров, средний чек — заметная для месячного бюджета сумма. Возьмём консервативную долю зависающих на этапе «договор→оплата» сделок — 10% от закрытых договоров (в разобранном выше примере недели эта доля была выше, 36%, то есть 10% — это заниженная, а не завышенная оценка).

Если отдел в месяц закрывает несколько десятков договоров (условная цифра для примера, оценка), то 10% — это несколько зависших сделок. При среднем чеке, сопоставимом с крупной статьёй месячного бюджета, риск не дойти до оплаты по этим сделкам сопоставим с ощутимой долей месячной выручки отдела (оценка, при условии, что зависшая сделка теряется полностью, а не переезжает на следующий месяц — на практике часть таких сделок всё же закрывается позже, так что это верхняя граница риска).

Отдельно — время руководителя. Ручной поиск причины по каждой зависшей сделке (поднять карточку, посмотреть переписку, позвонить менеджеру) занимает примерно час. На несколько сделок в месяц — это несколько часов руководителя, что в деньгах не идёт ни в какое сравнение с риском по недополученной выручке, но это именно то время, которое дашборд с автоматическим светофором и еженедельной ИИ-диагностикой освобождает почти полностью — вместо часа на сделку остаётся 5–10 минут на проверку уже готового вывода модели.

Важная оговорка: рост конверсии на процентный пункт в месяц, о котором шла речь в начале статьи, — результат комплекса мер (контроль, разбор сделок, дисциплина по звонкам), а не одного только дашборда. Вклад именно инструмента прогноза в этом комплексе — сокращение времени на обнаружение проблемы с недели до минут, что и переводится в заметный риск по выручке, выявленный на пятый день, а не в конце месяца, когда план уже сорван и деньги не вернуть.

Где это ломается

Чек-лист понедельника

1. Разложить план недели на этапы воронки: лид→встреча, встреча→договор, договор→оплата — а не одну цифру «план по деньгам».
2. Свериться с фактом за прошлую неделю по каждому этапу отдельно, а не только по итоговой сумме продаж.
3. Проверить разбивку по источникам сделок — просадка в одном канале маскируется нормальной средней конверсией по отделу.
4. Выгрузить список сделок, которые дольше нормы висят на своём этапе (светофор красный/жёлтый), и разобрать топ-3 из них до планёрки.
5. Если используется ИИ-диагностика — проверить, не помечены ли строки «недостаточно данных»: это сигнал, что в CRM просела дисциплина внесения данных, а не что всё в порядке.
6. Отдельно вынести долгоживущие нетипичные сделки в отдельную воронку, чтобы они не искажали средние показатели.

Прогноз по воронке не избавляет от плохих недель. Он избавляет от неожиданных плохих недель. Разница между «мы недобрали план и уже знаем почему» и «мы недобрали план и понятия не имеем почему» — это разница между управляемым отделом продаж и отделом, который живёт от отчёта к отчёту. Цифры за 14–20 мая некрасивые. Но они были видны на пятый день, а не на тридцатый — и это единственное, что даёт шанс что-то успеть исправить в текущем месяце, а не только сделать выводы для следующего.

Частые вопросы

Как считать выполнение плана продаж, если сделки долгие?

Считать не по факту оплаты в конце месяца, а по конверсии на каждом этапе воронки понедельно — тогда отклонение видно на пятый день, а не на тридцатый.

Почему конверсия продаж по этапам важнее общей цифры конверсии?

Общая цифра не говорит, где теряются деньги — на встрече, на договоре или на оплате. Разбивка по этапам показывает конкретное узкое место и конкретный разговор с менеджерами.

Что делать, если конверсия резко упала при росте штата?

Проверить, не размылось ли внимание к лидам из-за их избытка на менеджера — это частая причина падения конверсии при масштабировании отдела, а не проблема квалификации новых людей.

#аналитика и отчётность #контроль и надёжность #деньги