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

Зависшие сделки в воронке: как их вычислить, оживить и не плодить заново

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

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

Зависшая сделка — это не отказ и не потеря

Разница простая. Отказ — клиент сказал «нет», сделку можно закрывать. Потеря — вы прозевали момент, и клиент ушёл к другому. Зависшая сделка — это состояние неопределённости: никто не сказал «нет», но и движения нет. Она живёт в статусе месяцами, потому что менеджеру неудобно её закрыть (жалко бросать) и неудобно её толкать (непонятно, чем).

Проблема не в том, что такие сделки существуют — они будут всегда. Проблема в том, что они искажают всё остальное:

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

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

Как находить зависшие сделки: дашборд и светофор по стадиям

В одной компании руководитель поставил задачу построить отчёт по воронке, обновляемый ежечасно. Логика: для каждого менеджера видно клиента, текущий статус, дату создания сделки, количество дней в этом статусе — и индикатор-светофор на основе нормативных сроков по стадиям. Зелёный — в пределах нормы, жёлтый — превышение, красный — сделка мертва по всем признакам, кроме статуса в CRM.

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

Так этот отчёт выглядит на экране РОПа — не таблица цифр, а живой список сделок с цветным статусом на каждой строке:

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

Про то, что CRM сама по себе может показывать неверные даты — отдельная тема, я разбирал её в статье про сдвиг дат в Битрикс24. Если светофор строится на датах, а даты сдвигаются, светофор врёт вместе с ними — это стоит проверить до того, как строить отчёт, иначе вся механика ниже работает на кривых входных данных.

Почему сделки зависают: не всегда виноват менеджер

За неделю в одной компании факт продажи заметно отстал от плана. Закрыта примерно половина запланированных сделок, конверсия продажи заметно ниже плановой. При этом конверсия во встречу — 55% (несколько десятков встреч проведено), а из встречи в договор — только 22%. Люди доходят до встречи нормально. Проблема — на стадии между встречей и договором. Именно там сделки чаще всего зависают: клиент выслушал, кивнул, взял паузу «подумать» — и дальше тишина. На диаграмме видна именно эта просадка — конверсия рушится не на входе в воронку, а на переходе от встречи к договору.

Причины паузы разные, и лечатся они по-разному:

• клиент хочет посоветоваться — нужен не звонок с напоминанием, а материал, который он покажет второй стороне;
• клиент не готов платить сейчас — реактивация должна прийти не сразу, а через месяц-два, когда ситуация изменится;
• клиент разочаровался в качестве общения с конкретным менеджером — тут реанимация должна идти от другого человека, иначе сделка просто зависнет второй раз.

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

Реанимация: тест на «паузниках» перед атакой на активную базу

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

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

Кейс с 7-летней базой

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

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

ИИ-связка целиком: конвейер реактивации без спама

Схема, которую можно повторить на своей CRM, выглядит так:

• CRM (у меня — Bitrix24) по правилу автоматизации триггерит вебхук, когда сделка не менялась дольше нормативного срока стадии;
• внешний сценарий (n8n, Make или свой сервер) забирает через REST API историю переписки и метаданные сделки;
• эти данные уходят в LLM с промптом на определение причины паузы, тона и черновика сообщения;
• ответ модели записывается в поле сделки и превращается в задачу менеджеру на подтверждение — сообщение не уходит клиенту само, менеджер видит черновик и одобряет или правит;
• каждый вызов логируется в отдельную таблицу мониторинга, чтобы было видно, сколько сделок обработано и сколько реактиваций подтверждено.

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

Ты — ассистент отдела продаж. На входе история переписки и метаданные зависшей сделки.

Задача:
1. Определи наиболее вероятную причину паузы: одна из ["цена", "согласование с третьей стороной", "недоверие к менеджеру", "неактуальность момента", "техническая причина"].
2. Подбери тон реактивационного сообщения: один из ["деловой", "мягкий-заботливый", "информационный-без-давления"].
3. Составь черновик сообщения на 2-3 предложения. Без прямого предложения купить, без давления на срок принятия решения.

Входные данные (JSON):
{
  "deal_id": "D-10245",
  "days_in_status": 47,
  "stage": "переговоры после встречи",
  "deal_amount": 3200,
  "last_message_date": "2026-04-18",
  "messages": [
    "Клиент: нам нужно обсудить это вдвоём, я вернусь на связь",
    "Менеджер: конечно, буду ждать, если появятся вопросы — пишите"
  ]
}

Верни ответ строго в формате JSON: {"reason": "...", "tone": "...", "draft_message": "...", "confidence": 0.0-1.0}

Пример ответа модели на такой запрос:

{
  "reason": "согласование с третьей стороной",
  "tone": "мягкий-заботливый",
  "draft_message": "Здравствуйте! Понимаю, что решение непростое и его нужно обсудить всей семьёй. Если появятся вопросы по срокам или деталям — я на связи, без спешки.",
  "confidence": 0.72
}

Инженерная обвязка простая и без магии. Триггер на «нет изменений N дней» — бизнес-процесс в CRM, вызывающий вебхук раз в сутки батчем, а не в реальном времени: это дешевле и не создаёт гонки при массовом обновлении сделок. Сценарий забирает историю через методы вроде crm.timeline.comment.list и crm.deal.get, отправляет промпт в LLM API, результат пишет обратно в пользовательское поле сделки через crm.deal.update и создаёт задачу менеджеру. Если вызов API упал по таймауту — три повтора с задержкой, и если не помогло — сообщение об ошибке с deal_id в рабочий чат, а не молчание. Сценарий идемпотентен: при следующем суточном триггере он повторно берёт сделки с флагом «не обработано», так что пропущенный день не теряет данные, а просто обрабатывается позже.

Экономика: что это стоит и что даёт

Стоимость внедрения — это в первую очередь часы, а не деньги на подписки. Настройка дашборда со светофором по стадиям — оценочно 8–15 часов работы аналитика или интегратора CRM, в зависимости от того, сколько воронок и нормативов нужно завести. Настройка конвейера реактивации поверх готовой CRM — ещё 10–20 часов на вебхук, промпт и логирование, плюс тестовый прогон на «паузниках» перед масштабированием.

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

Теперь про эффект в деньгах, отдельно от затрат на внедрение. Вернёмся к тому же отделу, что в начале статьи: шесть менеджеров, несколько сотен сделок в пайплайне, около десятой части зависших при консервативной оценке — на практике она часто выше. При среднем чеке, условно равном двум недельным планам продажи отдела (подставьте свой), и допущении, что конверсия из зависшей сделки в оплату после реактивации не выше конверсии «встреча → договор» из фактуры (22%), потенциальный эффект реанимации этой партии — примерно число зависших сделок × два недельных плана × 0,22 ≈ порядка десяти недельных планов продажи отдела (оценка, консервативный сценарий). Важная оговорка: эта величина — эффект всего контура «дашборд нашёл + бот классифицировал причину + менеджер довёл до сделки» целиком, а не одного инструмента. Дашборд без реактивации даст только видимость проблемы, реактивация без дашборда будет бить по случайным сделкам вместо реально застрявших — 22% конверсии реалистичны только при обеих частях контура вместе, и то как верхняя, не гарантированная граница.

Без дашборда и реактивации зависшие сделки просто лежат в воронке. С полным контуром — потенциальный эффект реанимации этой партии, ≈10 недельных планов продажи отдела, консервативная верхняя оценка (см. расчёт выше).

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

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

Как не наплодить новых зависших сделок

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

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

• регулярный, а не разовый цикл касаний по резервной базе — с интервалом, а не единым днём рассылки;
• привязка реактивации к нормативному сроку стадии, а не к «когда вспомнили»;
• фиксация причины паузы в CRM, чтобы второй заход не повторял ошибку первого.

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

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

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

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

Что считать зависшей сделкой в CRM?

Сделку, которая находится в одном статусе дольше нормативного срока для этой стадии. Общий норматив «две недели» ничего не значит, если реальный цикл сделки у вас три месяца.

Нужно ли закрывать зависшие сделки?

Не всегда. Часть нужно выносить в отдельную воронку, чтобы не искажать аналитику, часть — ставить в резерв на реактивацию через 2-3 месяца, и только часть — закрывать как проигранные.

Как реанимировать старую базу без спама?

Сначала разобраться, почему клиент замолчал: не было денег, не было доверия к менеджеру или просто не было предложения. Разная причина требует разного текста и разного канала, иначе вторая попытка провалится так же, как первая.

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