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

Воронка продаж врёт: клиент завис на 540 дней, а отчёт считал его живым

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Саша, РОП отдела продаж на производстве под заказ (шесть менеджеров, оборот около 4 млн ₽ в месяц, средний чек — 180 тысяч), открыл фильтр «сделки старше 90 дней» и увидел клиента в статусе «Согласование договора». Дата создания сделки — полтора года назад (540 дней). Всё это время клиент числился активным: попадал в отчёт по конверсии, в план по срокам закрытия месяца, в разговор на планёрке «ну, работаем». На деле с ним никто не разговаривал восемь месяцев.

Один такой клиент не разоряет компанию. Но это классическая ошибка воронки продаж: она врёт в статистике по всем сделкам сразу, а не только по одной. Конверсия по стадии «Согласование» считается по всем сделкам на этой стадии, включая мёртвую. Средний срок закрытия сделки в отчёте раздувается на недели. А менеджер, который её ведёт, раз в неделю тратит 10–15 минут на то, чтобы упомянуть её на планёрке. Формула проста: минуты на упоминание × число недель в месяце ÷ 60 × ставка часа = потери. У Саши это 10–15 минут × 4 недели ≈ 40–60 минут, округлим до часа; час × ~1 000 ₽/час (ставка менеджера, оценка) ≈ 1 000 ₽ в месяц ни за что. Само по себе не страшно. Страшно то, что пока команда обсуждает мёртвую сделку, никто не смотрит на сорок живых, у которых, возможно, тот же самый диагноз — просто их ещё не поймали.

Ошибки воронки продаж «до»: три системные причины

Стандартный отчёт по воронке в Bitrix24 у Саши выглядел так: колонка «Стадия», колонка «Сумма», колонка «Ответственный». Всё. Ни даты последнего контакта, ни количества дней в текущем статусе, ни норматива, с которым можно сравнить. Воронка показывала, ГДЕ клиент, но не показывала, сколько он там уже стоит.

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

У отчёта «до» было три системные проблемы, и ни одна не про конкретного менеджера:

• Время в статусе не фиксировалось — видна только текущая стадия, а сколько сделка там уже провисела, никто не считал.
• Разовые заказы, годовые контракты и нестандартные долгие проекты сидели в одной воронке и портили друг другу статистику.
• Норматива по срокам не было в принципе — «долго» и «нормально» каждый менеджер определял на глаз, и глаза у всех разные.

Похожая история с датами есть в CRM почти у каждого — иногда система сама сдвигает даты создания сделки, и тогда врёт не отчёт, а исходные данные. Это отдельная поломка, я разбирал её в статье про сдвиг дат в Битрикс24. Здесь другой случай: даты честные, просто их никто не считает.

Пересборка: как собирался новый отчёт

Пересборка заняла три итерации, каждая — по результатам разговора с Сашей, который проверял всё на своей неделе и заворачивал то, что не билось с реальностью.

1. Аудит стадий и нормативных сроков. Взяли реальную воронку производства на заказ: заявка → расчёт КП → согласование договора → производство → приёмка → оплата. По каждой стадии выставили норматив в днях — не из головы, а по медиане фактических сроков закрытых сделок за полгода.
2. Сегментация по типам работ. Нестандартные проекты с индивидуальным циклом (заказчик тянет решение месяцами по объективным причинам — например, ждёт финансирование) вынесли в отдельную воронку. Это тот самый случай зависшего клиента: он не «плохая сделка», он просто из другой категории, и в общей статистике ему не место.
3. Добавили поля в карточку сделки. Дата создания, дата последнего контакта, количество дней в текущем статусе (вычисляемое поле), источник сделки.
4. Светофор по нормативам. Зелёный — в пределах норматива стадии. Жёлтый — превышение до 50%. Красный — превышение больше 50% или полное отсутствие контакта дольше 14 дней.
5. Ежечасное обновление и переход в карточку. Отчёт тянет данные напрямую из CRM по вебхуку, обновляется каждый час, из строки отчёта можно кликом уйти в саму сделку — без поиска по ID.
6. Кто и когда смотрит. Красные сделки — на утренней летучке РОПа, до разбора плана на день. Жёлтые — раз в неделю на общей планёрке отдела.

Саша принял идею не сразу — со скрипом, после того как отчёт нашёл вторую такую же зависшую сделку, которую он лично считал живой ещё неделю назад.

ИИ-конвейер поверх отчёта

Светофор — это арифметика: даты и нормативы, без ИИ. Ум в конвейер добавили на следующем шаге — когда встал вопрос, что делать с красными сделками. Их набиралось 6–8 штук на весь отдел одномоментно, и по каждой нужно было понять: сделка мёртвая или просто клиент взял паузу по объективной причине. Разбирать вручную — минимум 10 минут на сделку: 6–8 сделок × 10 минут ≈ час РОПа в день только на диагностику.

Схема конвейера:

CRM (Bitrix24) → вебхук по расписанию (раз в час) → облачная функция считает дни в статусе и красные/жёлтые сделки → для каждой красной сделки формируется запрос к языковой модели с историей переписки и комментариев → модель определяет вероятную причину паузы и предлагает тон обращения → результат пишется обратно в поле сделки и падает уведомлением в чат РОПа.

Ты — ассистент отдела продаж производственной компании.
Тебе дана карточка сделки CRM и последние комментарии менеджера.
Определи вероятную причину, по которой сделка не двигается,
и предложи следующий шаг.

Данные сделки (JSON):
{
  "deal_id": "40123",
  "stage": "Согласование договора",
  "days_in_stage": 62,
  "stage_norm_days": 14,
  "last_contact_days_ago": 47,
  "amount": 180000,
  "comments": [
    "Клиент просил прислать финальную смету — отправил 12.03",
    "Звонок не взял, написал в WhatsApp — без ответа",
    "Клиент писал, что решение зависит от согласования бюджета внутри его компании"
  ]
}

Верни строго JSON:
{
  "likely_reason": "краткая формулировка причины паузы",
  "confidence": "высокая/средняя/низкая",
  "recommended_action": "конкретный следующий шаг менеджера",
  "suggested_tone": "тон обращения к клиенту",
  "priority": "красный/жёлтый"
}
Не придумывай факты, которых нет в комментариях.
Если данных недостаточно — так и укажи в reason.

Пример ответа модели:

{
  "likely_reason": "Ждёт внутреннего согласования бюджета у клиента, не отказ",
  "confidence": "средняя",
  "recommended_action": "Напомнить через 5 дней, предложить созвон с ЛПР клиента",
  "suggested_tone": "деловой, без давления",
  "priority": "жёлтый"
}

Модель на этом шаге — дешёвая (уровня GPT-4o-mini или аналог): задача классификационная, текста немного, объём запросов маленький — 6–8 сделок в день на весь отдел. Дорогая модель здесь избыточна, разница в качестве классификации причины паузы на этом объёме не окупает разницу в цене токена.

Инженерная обвязка простая и в этом её ценность: облачная функция (или скрипт по крону на сервере компании) дёргает Bitrix24 REST API, считает дни в статусе, для красных сделок вызывает модель, пишет ответ обратно в кастомное поле сделки и дублирует в Google Sheets как лог. Если вызов к CRM или к модели падает — запись уходит в отдельный лист «ошибки» с таймстампом, и в чат РОПа летит короткое уведомление «отчёт не обновился, час X». Без такого лога вы не отличите «сделок сегодня мало» от «скрипт упал вчера ночью».

Экран «после»: что показывает отчёт теперь

Пример строк актуального отчёта (обезличено):

Клиент менеджера 5 (540 дней в «Согласовании договора») в этот отчёт больше не попадает — он вынесен в отдельную воронку нестандартных проектов, чтобы не искажать статистику остальных.

Распределение открытых сделок отдела по светофору после трёх месяцев работы отчёта (оценка на основе типового пайплайна из 45 открытых сделок) — на диаграмме ниже:

Доля сделок без движения дольше 60 дней (то есть фактически зависших, а не просто медленных) снизилась с 20% до внедрения светофора до 5% после — оценка на типовом пайплайне отдела.

Отдельно: качество работы с этим же пайплайном заметно зависит не только от отчёта, но и от численности отдела. У Саши уже был период, когда три менеджера (он сам, напарник и ещё один) продавали стабильно больше, чем позже шесть-семь человек — просто потому что лидов на каждого стало больше, а внимания на каждого — меньше. После того как ввели контроль по пайплайну, конверсия начала расти на 1 процентный пункт в месяц. Это заслуга комплекса мер — контроль пайплайна плюс перераспределение нагрузки, а не одного только светофора, и вклад именно отчёта здесь нельзя выделить в чистом виде.

Что это стоит и что даёт

Внедрение: аудит стадий, нормативов и настройка вебхука с полями — 10–14 часов работы аналитика или толкового менеджера по CRM. По ставке ~1 500 ₽/час (оценка, инженерное время дороже линейного) это 10 × 1 500 = 15 000 ₽ — 14 × 1 500 = 21 000 ₽ разово.

Эксплуатация: ежечасный опрос CRM — бесплатно в рамках лимитов вебхука; вызовы к дешёвой модели на 6–8 сделок в день — по опыту такие объёмы укладываются в единицы долларов в месяц, подробный разбор счетов за похожие сценарии — в статье про реальные расходы на ИИ.

Эффект в деньгах, оценка на условной компании: отдел из 6 менеджеров, средний чек 180 тыс. ₽, в пайплайне одномоментно около 45 открытых сделок. Если 15% из них зависает дольше норматива — это 45 × 0,15 ≈ 7 сделок. Даже если из них закрывается позже половина, а половина теряется навсегда — это 7 × 0,5 ≈ 3–4 сделки в квартал без выручки, то есть 3,5 × 180 000 ≈ 630 000 ₽ в квартал недополученных продаж (оценка, консервативно). Отчёт не гарантирует, что все эти сделки будут спасены — но без него их даже не видно.

Отдельная выгода — время РОПа. Ручной разбор 6–8 красных сделок в день занимал у Саши около часа. Со скринингом моделью он тратит на ту же диагностику 10–15 минут — просматривает готовые причины и решает, что делать. Экономия примерно 45 минут в день: 45 мин × ~20 рабочих дней ÷ 60 ≈ 15 часов в месяц; 15 часов × ~1 000 ₽/час (ставка РОПа, оценка) ≈ 15 000 ₽ в месяц высвобожденного управленческого времени, которое пошло на работу с живыми сделками, а не на археологию мёртвых.

Чтобы прикинуть цифру на своём отделе: возьмите число открытых сделок в пайплайне, умножьте на вашу долю зависших сверх норматива стадии, умножьте на средний чек и на долю тех, кого вы реально теряете (консервативно берите половину) — получите оценку риска за период. То же самое с временем: минуты ручной диагностики одной сделки × число красных сделок в день × рабочие дни ÷ 60 × ставка часа — это то, что вы платите за отсутствие скрининга сейчас.

Та же логика — сначала честные критерии метрики, потом контроль по ней — сработала и в другом месте того же отдела: менеджеров стали оценивать по вторичным звонкам, не объяснив правил, по которым система их сравнивает. Подробный разбор этого случая без саботажа и цифры внедрения — в статье про контроль звонков.

Чек-лист: с чего начать в понедельник

• Откройте воронку и отфильтруйте сделки старше 60–90 дней без указания причины — их не должно быть больше нескольких единиц на отдел.
• Проверьте, есть ли в карточке сделки поле «дата последнего контакта» и заполняется ли оно реально, а не автоматически при любом клике.
• Выпишите нормативный срок по каждой стадии — по медиане уже закрытых сделок за полгода, а не «как кажется».
• Вынесите нестандартные, долгоцикловые кейсы в отдельную воронку — не удаляйте и не мешайте с обычным потоком.
• Настройте вычисляемое поле «дней в статусе» и элементарный светофор — это делается без ИИ, за один день работы с CRM.
• Только после того как светофор устойчиво работает вручную минимум две недели, добавляйте автоматическую диагностику причины через модель — иначе автоматизируете хаос, а не процесс.

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

Почему воронка продаж не работает, если стадии настроены правильно?

Потому что стадии показывают, где клиент, а не сколько он там стоит. Без даты последнего контакта и норматива по сроку воронка врёт даже с идеальными названиями этапов.

Что делать с клиентом, который завис в воронке на годы?

Вынести в отдельную воронку по типу работ, а не удалять и не тянуть в общей статистике — иначе он искажает конверсию и сроки по всем остальным сделкам.

Как понять, что проблема именно в воронке, а не в менеджерах?

Если отчёт не показывает дни в статусе и дату последнего контакта, вы не можете отличить забытую сделку от медленного клиента — значит, дело в отчёте, а не в людях.

#аналитика и отчётность #контроль и надёжность #ошибки и провалы