# Директор и машина — Продажи: полные тексты (часть 2 из 2)

Направление: Продажи — воронка и CRM · контроль менеджеров · прогноз и план
Хаб направления: https://davidgerstein.pro/prodazhi/
Материалов в файле: 2 из 10 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json
Другие части этого направления: https://davidgerstein.pro/llms-prodazhi.txt

## Прогноз продаж, которому можно верить: воронка вместо ощущений
URL: https://davidgerstein.pro/blog/prognoz-prodazh-po-voronke/
Дата: 2026-06-25
Направление: Продажи
Цифры: план выполнен на 80% · конверсия 14% против плана 23% · встреча→договор 22%
Коротко: Прогноз продаж — это расчёт от конверсии на каждом этапе воронки (лид→встреча→договор→оплата), а не сумма ожиданий менеджеров: в примере недели план выполнен на 80%, потому что конверсия просела до 14% вместо плановых 23%. Такой расчёт показывает отклонение на пятый день недели, а не в конце месяца, и требует дашборда с датой последнего контакта и ИИ-диагностики узкого места, а не памяти руководителя.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Как считать прогноз продаж по воронке Прогноз продаж по воронке — это произведение: число лидов × конверсия лид→встреча × конверсия встреча→договор × конверсия договор→оплата × средний чек. Не сумма ожиданий менеджеров, а арифметика по этапам, которую вы можете проверить строку за строкой. Если у вас прогноз собирается из ответов на вопрос «сколько закроешь в этом месяце», отклонение вы увидите на тридцатый день. Расчёт по этапам показывает его на пятый: в одной такой неделе план по деньгам выполнен на 80%, потому что конверсия просела до 14% против плановых 23% — и просела ровно на одном переходе, встреча→договор. Как вы сейчас отвечаете на вопрос «сколько закроем в этом месяце»? Если ответ собирается из ощущений менеджеров — вы не прогнозируете, вы гадаете и потом объясняете, почему не сбылось. Нормальный прогноз собирается из воронки: сколько сделок на каждом этапе, какая конверсия дальше, сколько времени занимает переход. Это арифметика, которую вы можете проверить, а не вера в оптимизм отдела. Неделя 14–20 мая. План по деньгам выполнен на 80%. Закрыли 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. Конверсия во встречу нормальная, 55%, а вот из встречи в договор — только 22%. Руководитель отдела продаж прямым текстом: «Тут уже мне становится страшно, я начинаю переживать конкретно». За недостающими 20% плана стоят не абстрактные проценты, а конкретные девять сделок, которые должны были закрыться и не закрылись. Это и есть прогноз продаж по воронке в чистом виде. Не «в этом месяце должны сделать миллион, потому что обычно делаем», а разложенная по этапам математика: сколько лидов, какая конверсия на каждом шаге, сколько денег получится на выходе. Когда цифры разложены так, страх появляется на пятый день недели, а не на тридцатый день месяца — когда уже поздно что-то менять. Дальше в статье — как считать этот прогноз руками, какой промпт можно скопировать для еженедельной диагностики узкого места, во сколько обходится зависшая сделка и где эта система обычно ломается. Прогноз продаж по воронке против прогноза «на глазок» Сравните два подхода на своём примере — вы наверняка узнаете первый. Классический прогноз продаж строится так: руководитель спрашивает у менеджеров, сколько они закроют в этом месяце, складывает ответы и докладывает наверх. Это работает, пока воронка стабильна. Как только что-то меняется — состав отдела, источник лидов, сезон — прогноз «на глазок» начинает врать, и врёт он всегда в оптимистичную сторону, потому что менеджер отвечает на вопрос «сколько ты хочешь закрыть», а не «сколько у тебя реально в пайплайне со сроком». В одной компании отдел из нескольких человек — руководитель, его напарник и ещё один менеджер — стабильно давал продажи выше, чем тот же отдел после расширения примерно вдвое. Причина не в квалификации новых людей. Причина в том, что лидов на каждого стало больше, а внимания к каждому лиду — меньше. Конверсия просела именно потому, что никто не считал её по этапам в моменте: рост штата выглядел как рост мощности, а на деле размывал воронку. После внедрения контроля по этапам конверсия начала расти на процентный пункт в месяц — не рывком, а постепенно, потому что причину нашли не на глаз, а по разбивке. Оговорюсь сразу: этот рост дал комплекс мер — контроль конверсии, разбор застрявших сделок, дисциплина по звонкам — а не один только факт появления таблицы. Ниже, в разделе про экономику, я оцениваю вклад именно инструмента прогноза отдельно от остальных мер. Правило Прогноз, который не разложен на этапы воронки, — это не прогноз, а надежда. Надежда не масштабируется вместе с отделом. Конверсия по этапам: где именно теряются ваши деньги Посчитайте свою конверсию по каждому переходу. Почти наверняка вы найдёте один этап, где теряется больше половины, — и почти наверняка это будет не тот этап, на который вы грешили. Отдельная цифра «конверсия 25%» ничего не говорит о том, что делать. Разбивка по этапам — говорит. В майском примере разница между планом и фактом была не в количестве лидов и не во встречах — там всё было в норме. Проблема сидела на переходе от встречи к договору: 55% встреч состоялось, но только 22% из них закрылись договором. Значит причину нужно искать не в лидогенерации и не в графике встреч, а в том, что происходит на самой встрече и сразу после неё. На диаграмме ниже — конверсия по каждому этапу воронки за неделю 14–20 мая в сравнении с плановой конверсией лид→продажа. Этап воронки План Факт (неделя 14–20 мая) Лид → встреча — 55% (49 встреч) Встреча → договор 23% 22% Лид → продажа 23% 14% Средний чек 10% 13,5% Закрыто сделок 16 7 Лид → встреча 55% Встреча → договор 22% Лид → продажа, факт 14% Лид → продажа, план 23% Подставим формулу из начала статьи в цифры недели 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%. Разбор занял не неделю, а около пяти минут — но не потому, что кто-то угадал причину, а потому, что дашборд уже был разбит не только по этапам, но и по источникам сделок. Первая же строка среза по источникам показала: просадка сосредоточена в одном канале холодных лидов, где менеджеры физически перестали успевать доводить контакт до встречи — остальные источники держали плановую конверсию. Без такой разбивки эту же причину пришлось бы искать вручную, поднимая карточки по каждому менеджеру — отсюда и оценка «неделя ручного разбора» в таблице ниже. О том, как теряются деньги между маркетингом и продажами на более раннем этапе — в статье «Лиды есть, а продаж нет» . Дашборд вместо памяти: механика по шагам Соберёте это за вечер, если у вас есть выгрузка из CRM. Никакой BI-системы покупать не нужно — начните с таблицы, а инструмент выберете, когда поймёте, что именно смотрите каждую неделю. Прогноз по воронке требует данных, которые не устаревают за неделю. Разовый отчёт для планёрки — это фотография прошлого. Нужен инструмент, который обновляется постоянно и показывает не только «сколько продали», а «что застряло и почему». Механика такая: Что → сырые данные о сделках (этап, дата создания, дата последнего движения, менеджер, сумма, источник) забираются из CRM. Чем → Google Apps Script или прямой вебхук CRM по расписанию складывает срез в таблицу, где считаются конверсии по этапам, разбивка по источникам и дни без движения. Куда → результат попадает на дашборд с интеграцией «клик по строке → карточка сделки», чтобы не искать её отдельно. Кто и когда смотрит → руководитель — ежедневно по светофору, собственник — на еженедельном разборе плана/факта. В одной компании собрали именно такой дашборд: pipeline по каждому менеджеру, конверсия из договора в оплату, дата последнего контакта, источник сделки. Детализация по месяцам показывает заброшенные сделки без касаний ещё до того, как они превратятся в потерянный доход. Потом руководитель заказал динамический отчёт по воронке с обновлением каждый час. Для каждого менеджера он показывает клиента, текущий статус, дату создания сделки, число дней в статусе и светофор — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Идея простая: если сделка на этапе «договор» висит дольше нормы, система красит её красным раньше, чем это заметит человек на планёрке. Вот как такой отчёт выглядит на практике для недели 14–20 мая: Воронка · неделя 14–20 мая 80% выполнение плана 14% лид→продажа (план 23%) 7 / 16 закрыто сделок Менеджер Этап Дней в статусе Статус Иванов Договор 12 просрочено Петров Встреча 2 норма Сидорова Оплата 1 норма Похожая логика — в отдельном дашборде по договорам: имя менеджера, имя клиента, сумма, дата выставления счёта, была ли встреча. Это позволяет видеть закономерность — сделки после встречи закрываются иначе, чем без неё — и дожимать конкретные неоплаченные договоры адресно, а не общим напоминанием «оплатите, пожалуйста». Про системный контроль оплат — в статье «Дебиторка растёт: контроль, который не зависит от памяти людей» . В итоге вместо двух-трёх разрозненных отчётов получился один интерактивный портал: все договоры по источникам, пайплайн по месяцам, оплаты и выставленные счета по каждому сотруднику. Логика владельца была простой: «Чем мне создавать два отчёта? Мне проще создать один» — и именно на этом портале был найден за пять минут кейс с падением конверсии до 30%, описанный выше. Показатель До дашборда С дашбордом Время поиска причины отклонения конверсии до недели ручного разбора карточек (оценка автора кейса, по трудозатратам на выгрузку и сверку вручную) ≈ 5 минут — зафиксировано в кейсе с падением конверсии до 30% при плане 50%, когда причина была видна в первой строке среза по источникам Время руководителя на сведение отчётов в неделю несколько часов (оценка автора кейса: выгрузка из CRM + сверка в трёх таблицах + формулы вручную) ≈ 0 — автосбор по расписанию, ручная работа только на чтение готового среза Момент обнаружения зависшей сделки на планёрке или после потери клиента в день превышения нормативного срока по стадии (светофор) Обе оценки в левой колонке — не измерения секундомером, а прикидка руководителя по памяти о том, сколько времени уходило раньше. Это честная оценка, а не точный хронометраж, и в статье она помечена как оценка намеренно — чтобы не выдавать прикидку за измеренный факт. ИИ-связка: диагностика узкого места Дальше — постановка, которую вы можете взять как есть и подставить свою выгрузку. Машина найдёт этап, где стоит очередь, и покажет, на чём именно вы теряете. Дашборд показывает цифры. Но кто-то ещё должен каждую неделю посмотреть на все строки по всем менеджерам и сформулировать словами, где именно проблема. Это ручная работа, и её можно передать дешёвой модели — задача чисто структурная: сравнить план и факт по этапам, найти максимальное отклонение и сформулировать причину без домыслов. Творческая модель здесь не нужна и дорогая тоже не нужна — нужна дисциплинированная, которая не выдумывает лишнего. Схема конвейера: CRM (amoCRM API или Bitrix24-вебхук) → почасовой снимок сделок в Google Sheets → раз в неделю сборка JSON по каждому менеджеру → запрос к дешёвой модели (класс gpt-4o-mini или аналог) → ответ пишется обратно в таблицу и дублируется в чат руководителя. Входные данные на менеджера выглядят так — это не гипотетический пример, а структура, которую реально собирает Google Apps Script по расписанию раз в неделю: Пример ответа модели на входные данные выше: Обратите внимание: модель не сказала «менеджер плохо работает» — она указала конкретную сделку и конкретное отклонение. Это и есть разница между диагностикой и оценочным суждением. Дальше решение принимает человек: разговор с менеджером, звонок клиенту, пересмотр скрипта — но повестку для этого разговора формирует не память руководителя, а цифра. Инженерная обвязка, без которой промпт ломается на третьей неделе: Расписание запуска — раз в неделю, в фиксированный день и час (например, понедельник 8:00), до планёрки, а не после. Если в срезе за неделю у менеджера меньше 5 сделок на этапе — модель должна писать «недостаточно данных», а не достраивать вывод по единичному случаю. Это правило зашито в промпт отдельным пунктом, а не оставлено на усмотрение модели. Сырой ответ модели логируется отдельной строкой рядом с итоговым JSON — если через месяц вывод покажется странным, можно проверить, на каких именно цифрах он основан. Числовые поля в ответе (deviation_pp, stuck_deals_count) валидируются скриптом перед записью в таблицу: если модель вернула не число или пустое поле — строка помечается для ручной проверки, а не публикуется как есть. Стоимость такого прогона на класс моделей gpt-4o-mini при отделе из нескольких менеджеров и одном запуске в неделю — предмет отдельного разговора: подробный разбор счетов за ИИ в инфраструктуре продаж — в статье про контроль качества звонков без ОКК , там похожая экономика на других объёмах. Экономика: во сколько обходится ваша зависшая сделка Возьмите свой средний чек и умножьте на число сделок, которые стоят без движения дольше двух недель. Это ваш замороженный оборот — деньги, которые уже почти ваши. Возьмём легендированный пример на профиле условной компании из этого разбора: сервисная компания, отдел из 12 менеджеров, оборот ~6 млн ₽ в месяц, средний чек — 500 тыс. ₽. При таких вводных отдел закрывает около 12 договоров в месяц (6 000 000 ₽ ÷ 500 000 ₽ — оценка). Возьмём консервативную долю зависающих на этапе «договор→оплата» сделок — 10% от закрытых договоров. В разобранном выше примере недели эта доля была выше — 4 зависших договора из 11, то есть 36% — так что 10% в этом расчёте заниженная, а не завышенная оценка. 10% от 12 договоров в месяц — это около 1 зависшей сделки (оценка). При среднем чеке 500 тыс. ₽ риск не дойти до оплаты по этой сделке — около 500 тыс. ₽ в месяц (оценка, верхняя граница: она справедлива, если сделка теряется полностью, а не переезжает на следующий месяц — на практике часть таких сделок всё же закрывается позже, так что реальный риск обычно ниже этой цифры). Отдельно — время руководителя. Ручной поиск причины по каждой зависшей сделке (поднять карточку, посмотреть переписку, позвонить менеджеру) занимает примерно час (оценка). На одну зависшую сделку в месяц это около 1 000 ₽ по ставке ~1 000 ₽/час (оценка) — сумма, которая не идёт ни в какое сравнение с риском 500 тыс. ₽ по недополученной выручке. Именно это время дашборд с автоматическим светофором и еженедельной ИИ-диагностикой освобождает почти полностью — вместо часа на сделку остаётся 5–10 минут на проверку уже готового вывода модели. Важная оговорка: рост конверсии на процентный пункт в месяц, о котором шла речь в начале статьи, — результат комплекса мер (контроль, разбор сделок, дисциплина по звонкам), а не одного только дашборда. Вклад именно инструмента прогноза в этом комплексе — сокращение времени на обнаружение проблемы с недели до минут, что и переводится в риск около 500 тыс. ₽ в месяц (оценка на легендированном профиле), выявленный на пятый день, а не в конце месяца, когда план уже сорван и деньги не вернуть. Где это ломается Три места, в которых ваш прогноз перестанет работать. Первые два вы почините за день, третье потребует разговора с командой. Ловушка данных Дашборд честен ровно настолько, насколько честна CRM. Если менеджеры двигают сделки по этапам с задержкой в 2–3 дня «для порядка», конверсия по этапам будет искажена системно, а не случайно — и разбор по источникам покажет ложную причину. Перед тем как доверять прогнозу по воронке, стоит проверить, не врут ли сами даты в CRM: разбор похожих искажений — в статье про сдвиг дат в Битрикс24 . Риск ИИ-диагностики Модель без жёстких правил в промпте начинает достраивать причины там, где их нет в данных — особенно если у менеджера на этапе меньше 5 сделок за неделю. Решение не в более умной модели, а в явном запрете достраивать вывод при нехватке данных прямо в тексте промпта, как это сделано в примере выше. Ловушка долгоживущих сделок Если в воронке есть клиенты, которые стоят без движения полтора года (специфический тип контрактов, разовые долгие случаи), они искажают среднюю конверсию и нормативные сроки по стадиям. Их нужно выносить в отдельную воронку до расчёта прогноза, а не усреднять вместе с обычным циклом сделки. Чек-лист понедельника Разложить план недели на этапы воронки: лид→встреча, встреча→договор, договор→оплата — а не одну цифру «план по деньгам». Свериться с фактом за прошлую неделю по каждому этапу отдельно, а не только по итоговой сумме продаж. Проверить разбивку по источникам сделок — просадка в одном канале маскируется нормальной средней конверсией по отделу. Выгрузить список сделок, которые дольше нормы висят на своём этапе (светофор красный/жёлтый), и разобрать топ-3 из них до планёрки. Если используется ИИ-диагностика — проверить, не помечены ли строки «недостаточно данных»: это сигнал, что в CRM просела дисциплина внесения данных, а не что всё в порядке. Отдельно вынести долгоживущие нетипичные сделки в отдельную воронку, чтобы они не искажали средние показатели. Прогноз по воронке не избавляет от плохих недель. Он избавляет от неожиданных плохих недель. Разница между «мы недобрали план и уже знаем почему» и «мы недобрали план и понятия не имеем почему» — это разница между управляемым отделом продаж и отделом, который живёт от отчёта к отчёту. Цифры за 14–20 мая некрасивые. Но они были видны на пятый день, а не на тридцатый — и это единственное, что даёт шанс что-то успеть исправить в текущем месяце, а не только сделать выводы для следующего. И ещё одно, без чего таблица не приживётся. Разложить план на этапы и раз в неделю сверять с фактом — это управленческий навык, такой же, как чтение отчёта о прибылях или разбор рекламации. Он ставится теми же понедельниками, что и любой другой: первые три раза уходит час, дальше двадцать минут, а через месяц вы начинаете замечать провал раньше, чем его замечает сам отдел продаж. Что сделать в понедельник: выгрузите сделки за квартал и посчитайте конверсию каждого перехода. Одна таблица, час работы. После неё разговор с отделом продаж перестанет быть спором мнений — вы будете обсуждать конкретный этап, где стоит очередь. Как собрать прогноз, который пересчитывается сам и предупреждает о провале заранее, — в бесплатном курсе . Мой опыт: где я обжёгся Первый наш прогноз по воронке был красивым и неверным. Я взял среднюю конверсию по всем сделкам сразу — и получил цифру, которая не сбывалась ни разу. Оказалось, что конверсия у разных источников отличается в три раза, и усреднять их было ошибкой: половина прогноза строилась на лидах, которые не конвертировались почти никогда. Мы разделили воронку по источникам, и прогноз начал попадать. Заодно выяснилось, что один канал стабильно даёт мусор, — его закрыли, и это решение окупило всю затею с прогнозированием. Так что если ваш прогноз не сбывается — прежде чем винить менеджеров, проверьте, не усредняете ли вы то, что усреднять нельзя.

## Цикл сделки в CRM: почему средняя цифра врёт и как найти сделки без движения
URL: https://davidgerstein.pro/blog/zavisshie-sdelki-v-voronke/
Дата: 2026-06-10
Направление: Продажи
Цифры: 1,5 года без движения · встреча 55% → договор 22% · факт продажи заметно ниже плана (неделя)
Коротко: Средний цикл сделки — это метрика, которую проще всего испортить: в разобранном случае клиент простоял в статусе «переговоры» 1,5 года, а доля таких сделок в пайплайне — около 10%, и все они попадали в расчёт средней длины цикла. Считать цикл сделки надо по нормативу каждой стадии, а не в среднем по воронке: старые сделки выносить из основной воронки, чтобы не портили статистику, тёплые — реанимировать точечно, разобравшись в причине паузы, а не массовой рассылкой. Рабочий контур — дашборд со светофором по стадиям плюс контролируемая реактивация, протестированная сначала на «паузниках», а не на всей базе.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Что такое цикл сделки и почему средняя цифра врёт Если вы не можете назвать за минуту, сколько сделок в вашей CRM не двигались дольше месяца, — средний цикл сделки в вашем отчёте посчитан вместе с ними и не значит ничего. Цикл сделки — это срок от первого контакта до оплаты, и мерить его надо не в среднем по воронке, а по нормативу каждой стадии: у квалификации свой срок, у стадии «ждём документы от клиента» — свой. В разобранном случае один клиент простоял в статусе «переговоры» полтора года, а доля таких сделок в пайплайне — около 10%. Пока они лежат в общей воронке, цикл сделки завышен, прогноз по срокам сыпется, а деньги, за которые уже заплачено рекламой и временем менеджера, числятся «в работе». Видно это становится после трёх полей в карточке: дней в статусе, дата последнего контакта, норматив срока стадии. Деньги, о которых все забыли, лежат не в новых заявках — они в вашей воронке. Не потенциальные — почти ваши: клиенты, которые интересовались, обсуждали условия и просто перестали отвечать. Вы за них уже заплатили — за рекламу, за звонки, за время менеджера на встрече. Пока они висят в статусе, выручки они не приносят, зато исправно тянут вверх цифру, по которой вы планируете месяц. Как это устроено, разобрал отдельно: процент от прибыли, который перестали платить . У одной компании клиент завис в CRM в статусе «переговоры» на полтора года. Не отказ, не пауза с пометкой — просто висел. Каждый месяц эта зависшая сделка попадала в отчёт по срокам работы с клиентами и портила среднюю температуру по больнице: аналитик считал средний цикл сделки, а полтора года без движения тянули цифру вверх так, что реальная картина исчезала. Руководитель предложил простое решение — вынести такие сделки в отдельную воронку. Не удалить, не забыть, а перестать мешать ими считать остальных. Отдельный разбор на эту тему: потерянные заявки . Проблема — не один забытый клиент. Это про то, что база растёт, а вы теряете зрение: не видите, где деньги застряли, а где их уже нет. И чем больше отдел, тем быстрее зрение садится. Отдел из пятнадцати менеджеров при обороте около 9 млн ₽/мес и среднем чеке порядка 60 тыс. ₽ — это несколько сотен позиций в воронке. Если хотя бы десятая часть из них зависла (оценка доли, на практике часто выше), это несколько десятков сделок, которые числятся «в работе», а по факту не существуют — и никто не считал, сколько денег в них заморожено. Если вы прямо сейчас не можете назвать эту сумму по своей воронке — она уже работает против вас: вы платите за новых клиентов, стоя на старых. Зависшая сделка — это не отказ и не потеря Разница простая. Отказ — клиент сказал «нет», сделку можно закрывать. Потеря — вы прозевали момент, и клиент ушёл к другому. Зависшая сделка — это состояние неопределённости: никто не сказал «нет», но и движения нет. Она живёт в статусе месяцами, потому что менеджеру неудобно её закрыть (жалко бросать) и неудобно её толкать (непонятно, чем). Проблема не в том, что такие сделки существуют — они будут всегда. Проблема в том, что они искажают всё остальное: среднюю длину цикла сделки — если считать её вместе с «висяками», прогноз по срокам закрытия сыпется; конверсию по стадиям — сделка числится «в работе», хотя фактически из воронки выпала; загрузку менеджера — в отчёте у него много активных клиентов, а реально с половиной он не общался месяцами. Один такой клиент в отчёте почти не заметен. Пара десятков таких клиентов на отдел из пятнадцати человек — это около 1,2 млн ₽ подвисшего пайплайна (около 20 сделок × средний чек 60 тыс. ₽, оценка), который не существует, но занимает место в статистике и в голове менеджера, когда он планирует свою неделю. Как считать цикл сделки по стадиям: дашборд и светофор В одной компании руководитель поставил задачу построить отчёт по воронке, обновляемый ежечасно. Логика: для каждого менеджера видно клиента, текущий статус, дату создания сделки, количество дней в этом статусе — и индикатор-светофор на основе нормативных сроков по стадиям. Зелёный — в пределах нормы, жёлтый — превышение, красный — сделка мертва по всем признакам, кроме статуса в CRM. Соль тут в слове «нормативных». Норматив свой для каждой стадии и своей воронки. Для звонка-квалификации это может быть два дня, для стадии «ждём документы от клиента» — две недели, для крупной сделки с согласованием — месяц. Если применить один универсальный порог ко всей воронке, светофор либо будет всегда красным, либо никогда — оба варианта бесполезны. Цвет Что значит Что делать Зелёный Сделка движется в пределах нормы для стадии Ничего, оставить менеджеру Жёлтый Срок стадии превышен, но контакт был недавно Напоминание менеджеру, разбор на планёрке Красный Срок сильно превышен, контакта не было давно Разбор причины паузы: реанимация, перенос в отдельную воронку или закрытие Так этот отчёт выглядит на экране РОПа — не таблица цифр, а живой список сделок с цветным статусом на каждой строке: Воронка · светофор по стадиям 240 сделок в пайплайне 24 зависших (10%) 540 макс. дней без движения Клиент Стадия Дней в статусе Статус ООО «Вектор» Переговоры 18 Иванов А. Ждём документы 21 ИП Соколова После встречи 47 ООО «Гранд» Переговоры 540 Отдельно нужен дашборд по договорам: менеджер, клиент, сумма, дата выставления счёта, была ли встреча. Это отвечает на вопрос, который иначе тонет в общих цифрах: сделки закрываются после встречи или без неё, и на каком именно клиенте застрял конкретный договор. В одной компании такой отчёт собрали в единый портал вместо разрозненных таблиц — просто потому, что вести два отчёта дороже, чем один с фильтрами. Про то, что CRM сама по себе может показывать неверные даты — отдельная тема, я разбирал её в статье про сдвиг дат в Битрикс24 . Если светофор строится на датах, а даты сдвигаются, светофор врёт вместе с ними — это стоит проверить до того, как строить отчёт, иначе вся механика ниже работает на кривых входных данных. Почему сделки зависают: не всегда виноват менеджер За неделю в одной компании факт продажи заметно отстал от плана. Закрыта примерно половина запланированных сделок, конверсия продажи заметно ниже плановой. При этом конверсия во встречу — 55% (несколько десятков встреч проведено), а из встречи в договор — только 22%. Люди доходят до встречи нормально. Проблема — на стадии между встречей и договором. Именно там сделки чаще всего зависают: клиент выслушал, кивнул, взял паузу «подумать» — и дальше тишина. На диаграмме видна именно эта просадка — конверсия рушится не на входе в воронку, а на переходе от встречи к договору. Конверсия во встречу 55% Встреча → договор 22% Конверсия продажи, план план выше факта Конверсия продажи, факт факт ниже плана Причины паузы разные, и лечатся они по-разному: клиент хочет посоветоваться — нужен не звонок с напоминанием, а материал, который он покажет второй стороне; клиент не готов платить сейчас — реактивация должна прийти не сразу, а через месяц-два, когда ситуация изменится; клиент разочаровался в качестве общения с конкретным менеджером — тут реанимация должна идти от другого человека, иначе сделка просто зависнет второй раз. В одной сделке клиент дал согласие на комплексную услугу с заметным чеком, оба супруга оставили повторные заявки, перезвонили руководителю продаж с благодарностью — а в понедельник объявили паузу для «стратегического решения» и попросили не давить. Это не отказ и не зависшая в классическом смысле сделка, но именно из таких пауз чаще всего вырастают полугодовые «висяки»: клиент реально заинтересован, но никто не поставил ему напоминание через месяц, и сделка тихо ушла в тень. Здесь ошибаются все, включая меня. Я сам годами читал воронку по количеству сделок, а не по времени: вижу «переговоры» — значит, менеджер работает. Не работал. Мне было проще верить статусу в карточке, чем спросить, когда с этим клиентом последний раз реально разговаривали, — и потом я же считал средний цикл сделки по цифрам, в которых сидел полуторагодовалый «Гранд». Это не халатность и не лень. Это нормальная слепота руководителя, у которого нет под рукой одного столбца — «дней в статусе». Лечится он не выговором менеджеру, а этим самым столбцом. Правило Зависшая сделка старше полугода не должна учитываться в той же воронке, что живые сделки. Она либо переносится в отдельную воронку для длинных случаев, либо закрывается с явной причиной. Смешивать её с текущим пайплайном — значит врать самому себе о скорости продаж и о реальной длине цикла сделки. Реанимация: тест на «паузниках» перед атакой на активную базу Одна компания сделала ИИ-бота для реактивации: он анализирует историю переписки с клиентом, определяет вероятную причину паузы и выбирает тон сообщения — не одинаковый шаблон всем, а разный подход под ситуацию. Дальше бот контролируемо пингует клиентов из зависших сделок целевыми сообщениями. Логика запуска мне понравилась: тестировать сначала на «паузниках», а не на активной базе. Если бот сформулирует неудачное сообщение, риск — потерять клиента, который и так стоит без движения, а не испортить отношения с тем, кто ещё активно ведёт переговоры. Похожий подход, только вручную, я видел в другой компании: неготовые лиды не закрывают сразу, а переводят в резерв на два-три месяца, и потом их берёт в работу другой, более опытный менеджер. За два года практики там сложилась чёткая картина: клиенты «подостывают», но новый голос и новый контакт снова включает интерес. Это работает именно потому, что реактивация не давит — она приходит через паузу, достаточную, чтобы обстоятельства клиента могли измениться. Кейс с 7-летней базой Самый показательный пример — компания подняла базу лидов, которые отказали ещё семь лет назад: не готовы платить, не готовы разговаривать, заявку не оставили. В марте эти же клиенты вернулись и купили на сумму, заметную для месячного оборота отдела — по грубой прикидке, сопоставимую с ≈1–1,5 млн ₽ (оценка). Общий признак у всех: раньше они брали трубку и общались, просто попали к менеджерам низкой квалификации. То есть отказ был не в продукте и не в клиенте — он был в качестве разговора. Компания теперь готовит отдельное предложение с автоматическим инструментом реактивации именно под этот сегмент — тех, кто когда-то отвечал на звонки, но не дошёл до сделки. Как шёл этот подъём по дням и что он принёс — дневник реанимации базы . Вывод из этого кейса простой: реанимация клиентской базы работает не потому, что вы напомнили о себе, а потому что вы исправили то, что сломалось в первом контакте. Если причина отказа была в слабом менеджере — второй заход с сильным менеджером даёт результат. Если причина была в продукте или цене — тот же заход с тем же предложением просто повторит отказ. Результат в этом кейсе дала связка «новый менеджер + давность контакта + сам факт повторного касания» — три фактора смешаны, и без А/Б-разбивки по сегментам нельзя сказать, какой из них внёс больший вклад. Это стоит учитывать при оценке, что именно сработает на вашей базе: инструмент реактивации без замены менеджера может дать заметно меньший эффект, чем в этом кейсе. ИИ-связка целиком: конвейер реактивации без спама Схема, которую можно повторить на своей CRM, выглядит так: CRM (у меня — Bitrix24) по правилу автоматизации триггерит вебхук, когда сделка не менялась дольше нормативного срока стадии; внешний сценарий (n8n, Make или свой сервер) забирает через REST API историю переписки и метаданные сделки; эти данные уходят в LLM с промптом на определение причины паузы, тона и черновика сообщения; ответ модели записывается в поле сделки и превращается в задачу менеджеру на подтверждение — сообщение не уходит клиенту само, менеджер видит черновик и одобряет или правит; каждый вызов логируется в отдельную таблицу мониторинга, чтобы было видно, сколько сделок обработано и сколько реактиваций подтверждено. Модель на этом шаге — дешёвая (класса GPT-4o-mini или аналог). Задача классификационная и шаблонная: определить одну из нескольких типовых причин паузы и подобрать один из нескольких тонов. Дорогая модель здесь не даёт прироста качества, зато на заметном месячном объёме сделок ощутимо увеличивает счёт. Разбор того, сколько вообще стоят разные модели в проде, я делал отдельно — это тема для другого материала, здесь важно только само правило: чем более рутинная классификация, тем дешевле должна быть модель под неё. Пример ответа модели на такой запрос: Инженерная обвязка простая и без магии. Триггер на «нет изменений N дней» — бизнес-процесс в CRM, вызывающий вебхук раз в сутки батчем, а не в реальном времени: это дешевле и не создаёт гонки при массовом обновлении сделок. Сценарий забирает историю через методы вроде crm.timeline.comment.list и crm.deal.get , отправляет промпт в LLM API, результат пишет обратно в пользовательское поле сделки через crm.deal.update и создаёт задачу менеджеру. Если вызов API упал по таймауту — три повтора с задержкой, и если не помогло — сообщение об ошибке с deal_id в рабочий чат, а не молчание. Сценарий идемпотентен: при следующем суточном триггере он повторно берёт сделки с флагом «не обработано», так что пропущенный день не теряет данные, а просто обрабатывается позже. Экономика: что это стоит и что даёт Настройка дашборда со светофором — оценочно 8–15 часов, конвейер реактивации поверх CRM — ещё 10–20 часов, эксплуатация на дешёвой модели держится в пределах 300–600 ₽ в месяц (оценка), а потенциальный эффект реанимации одной партии зависших сделок — ≈317 000 ₽ (оценка, верхняя консервативная граница). Разберём по шагам. Стоимость внедрения — это в первую очередь часы, а не деньги на подписки. Настройка дашборда со светофором по стадиям — оценочно 8–15 часов работы аналитика или интегратора CRM, в зависимости от того, сколько воронок и нормативов нужно завести. Настройка конвейера реактивации поверх готовой CRM — ещё 10–20 часов на вебхук, промпт и логирование, плюс тестовый прогон на «паузниках» перед масштабированием. Эксплуатация на дешёвой модели недорогая. Если в месяц через конвейер проходит несколько сотен зависших сделок, а на каждую уходит порядка 1500 входных токенов (история переписки плюс промпт) и 300 выходных, суммарный расход выходит на уровне нескольких сотен тысяч токенов в месяц. При тарифе дешёвой модели, который на порядок ниже, чем у топовых моделей того же класса, это выходит в пределах 300–600 ₽ в месяц по прямой стоимости токенов с учётом курсовой наценки и накладных расходов провайдера — не отдельная статья бюджета, а строка внутри существующих расходов на LLM-инструменты. Формула для своей оценки: (число зависших сделок в месяц) × (токены на сделку) × (цена за токен у вашего провайдера) — подставьте свои цифры и посчитайте порядок суммы до внедрения, а не после. Теперь про эффект в деньгах, отдельно от затрат на внедрение. Возьмём цифры из начала статьи: отдел из пятнадцати менеджеров, оборот ~9 млн ₽/мес, средний чек ~60 тыс. ₽, недельный план продаж отдела — около 2,25 млн ₽ (оценка на базе оборота). При десятой части пайплайна, зависшей на практике часто больше, и при допущении, что конверсия из зависшей сделки в оплату после реактивации не выше конверсии «встреча → договор» из фактуры (22%), расчёт по формуле (число зависших сделок) × (средний чек) × (22%) при 24 зависших сделках даёт: 24 × 60 000 ₽ × 0,22 ≈ 317 000 ₽ потенциального эффекта реанимации этой партии (оценка, консервативный сценарий, верхняя граница). Важная оговорка: эта величина — эффект всего контура «дашборд нашёл + бот классифицировал причину + менеджер довёл до сделки» целиком, а не одного инструмента. Дашборд без реактивации даст только видимость проблемы, реактивация без дашборда будет бить по случайным сделкам вместо реально застрявших — 22% конверсии реалистичны только при обеих частях контура вместе, и то как верхняя, не гарантированная граница. 0 без системы ≈317 000 ₽ потенциал Без дашборда и реактивации зависшие сделки просто лежат в воронке. С полным контуром — потенциальный эффект реанимации этой партии, ≈317 000 ₽ (24 сделки × 60 000 ₽ × 22%), консервативная верхняя оценка. Формула для своего случая словами: (число зависших сделок) × (средний чек) × (ожидаемая конверсия реактивации, консервативно — не выше вашей конверсии «встреча → договор») = потенциальный эффект партии. Число зависших сделок берётся не «на глаз», а по факту после первой выгрузки фильтром по дате последнего изменения — иначе вся формула строится на предположении, а не на данных. Отдельно — стоимость ручного поиска зависших сделок без дашборда. Если РОП тратит на просмотр воронки и выписывание «висяков» вручную 3 часа в неделю при ставке ~1000 ₽/час, это около 12 часов и ~12 000 ₽ в месяц просто на то, чтобы найти проблему, — до того, как её начали решать. Дашборд со светофором сокращает это время до 10–15 минут просмотра готового отчёта, то есть экономит РОПу практически весь этот ресурс времени каждый месяц, не считая эффекта от найденных сделок. Что мы не считаем эффектом: часы, которые менеджер тратил на «висяк», после внедрения дашборда просто перераспределяются на другие сделки — это не прямая экономия в деньгах, а освобождённый ресурс времени, который ещё нужно конвертировать в новые продажи. Показатель Без дашборда и реактивации С дашбордом и контролируемой реактивацией Время РОПа на поиск «висяков» в месяц ~12 часов / ~12 000 ₽ ~1 час / ~1 000 ₽ на просмотр готового отчёта Зависшие сделки в пайплайне 15 менеджеров около десятой части, не выделены и не видны та же доля, выделена светофором и распределена по причинам Потенциальный эффект реактивации этой партии 0 (сделки просто лежат) ≈317 000 ₽ (верхняя консервативная граница) Затраты на внедрение — ~18–35 часов разово + 300–600 ₽/мес на токены LLM Как не наплодить новых зависших сделок Есть соблазн решить проблему массовым пингом всей базы разом — благо технически это дёшево. В одной компании была история: в мае отдел отвлёкся на апсейл и почти не звонил новым контактам — звонков сделали в разы меньше плана. Зато повторное касание по тёплым лидам из апреля дало несколько рекомендаций. Вывод руководителя: одного касания недостаточно, нужна регулярная, а не разовая работа с базой. Разовая массовая реактивация без системы просто создаёт новую партию зависших сделок — теперь уже «зависших после реактивации», и с клиентом, у которого накопилось раздражение от двух неудачных контактов вместо одного. Чтобы это не повторялось, нужны три вещи одновременно: регулярный, а не разовый цикл касаний по резервной базе — с интервалом, а не единым днём рассылки; привязка реактивации к нормативному сроку стадии, а не к «когда вспомнили»; фиксация причины паузы в CRM, чтобы второй заход не повторял ошибку первого. Ещё одна вещь, которую легко упустить: если реактивацией занимается тот же менеджер, что довёл сделку до зависания, шанс повторить сценарий выше, чем если подключить другого человека — живого или бота. Про то, почему менеджеры вообще перестают доводить сделки до конца и как это чинить без репрессий, я писал отдельно — см. про менеджеров, которые не ведут CRM . А если проблема шире — лиды идут, а до продажи не доходят системно — стоит смотреть не только на зависшие сделки, но и на всю воронку целиком, этому посвящена статья про лиды есть, продаж нет . Где ломается Автоматическая реактивация без сегментации по причине паузы превращается в спам с человеческим лицом. Клиент, который замолчал из-за цены, и клиент, который замолчал из-за плохого менеджера, не должны получать одинаковое сообщение — иначе вы просто ускорите второй отказ. Второй частый сбой — светофор строится на «дате последнего изменения» в CRM, а поле обновляется автоматически при любом техническом действии, включая смену ответственного. Тогда красная сделка внезапно становится зелёной без единого реального контакта с клиентом, и всё построение теряет смысл. Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки, которые не менялись дольше двух нормативных сроков стадии — без ИИ, просто фильтр по дате последнего изменения. Разбить список на три корзины: старые (более полугода), тёплые с понятной причиной паузы, тёплые без понятной причины. Старые вынести в отдельную воронку тем же днём, чтобы аналитика по срокам цикла перестала врать. По тёплым сделкам выписать причину паузы — спросить у менеджера, если она неочевидна из переписки, — прежде чем писать хоть одно реактивационное сообщение. Задать нормативный срок по каждой стадии воронки хотя бы вручную в таблице: без него светофор строить не на чем. Запустить реактивацию сначала на десятке-двух самых старых «паузников», а не на всей базе — оценить долю ответивших, прежде чем масштабировать конвейер дальше. Выгрузите свои сделки без движения дольше двух недель и посчитайте их сумму. Обычно эта цифра сопоставима с месячным планом — и работа с ней стоит вам ноль рублей на привлечение. Смотреть на воронку по времени, а не по числу карточек, — такой же базовый навык руководителя, как читать остаток на расчётном счёте. Спросить машину «покажи всё, что стоит дольше нормы для своей стадии» и получить список за секунду — это уже не про CRM и не про ИИ, это про то, сколько вы стоите как управленец. Тот, кто держит эти 24 сделки перед глазами каждую неделю, дороже того, кто узнаёт про 540 дней простоя из чужого отчёта раз в квартал. Я считаю, разрыв между этими двумя руководителями будет расти быстрее, чем разрыв в знании инструментов. Как поставить реанимацию на поток и не терять сделки заново — в бесплатном курсе для руководителей . Ваш регулярный ритуал после первой чистки: раз в неделю смотреть список сделок без движения дольше двух недель. Пять минут вашего времени — и ни одна сделка больше не зависает на месяцы. Заведите этот список у себя на этой неделе — и посмотрите, сколько ваших денег в нём лежит. Мы у себя нашли в таком списке сумму, сопоставимую с месячным планом, — и половину из неё удалось вернуть в работу за две недели.