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

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

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

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

Потерянные заявки в продажах: где именно рвётся цепочка

Три точки разрыва встречаются в разных отделах продаж почти одинаково.

Первая — смена статуса без владельца. Сделка перешла с этапа переговоров на этап «ожидание документов», и в этот момент менеджер решил, что мяч на стороне клиента. Клиент решил ровно то же самое про менеджера. Оба ждут. Через полтора года получаем зависшую карточку, которую случайно находят при аудите воронки.

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

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

Заявки без ответственного: что показывают цифры недели

Недельная динамика одного отдела продаж хорошо показывает, как выглядит разрыв в цифрах, а не в ощущениях. Факт продаж за неделю — 80% от плана. Закрыто 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. При этом конверсия во встречу держалась на уровне 55% — 49 встреч фактически состоялось, то есть люди доходили до разговора, и до этого момента процесс работал нормально.

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

Похожая история про май того же отдела: команда отвлеклась на апсейл действующей базе (на кону была сумма, заметная для месячного оборота по одному направлению) и перестала системно звонить новым контактам. План на месяц — 60+ звонков, сделали 15. При этом повторное касание по 19 тёплым лидам, оставшимся с апреля, дало 4 рекомендации. Ресурс, который просто лежал без внимания, оказался продуктивнее нового потока — потому что до него наконец дошли руки. Это тоже потерянная заявка, только растянутая на месяц: не пропала, а простояла без движения ровно до момента, пока кто-то не вспомнил о её существовании.

Механика по шагам: как найти и закрыть разрыв

Порядок, который реально работает — без сложной автоматизации на старте.

Шаг 1. Откуда данные. Выгружаете из CRM (Bitrix24, amoCRM или любая другая) все сделки с датой последнего изменения статуса, датой создания, текущим этапом и ответственным менеджером. Это стандартный экспорт, доступен в любой системе без доработок. Здесь важна оговорка: дата в поле CRM не всегда равна дате реального последнего касания — иногда система показывает дату технического сдвига, а не звонка. Прежде чем строить на этих данных отчёт, стоит свериться с логами звонков хотя бы выборочно, я подробно разбирал этот случай отдельно, когда Bitrix24 сдвигал даты сам.

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

Шаг 3. Кто и что делает с превышением. Сделки, превысившие норматив, помечаются как зависшие. Дальше — развилка: часть из них реально мёртвая (клиент год не отвечает, есть смысл вынести в отдельную воронку реактивации, чтобы не портить статистику активных сделок), часть — живая, но без ответственного (тут нужен именно контакт, а не архивация). Именно так поступили с клиентом, зависшим на полтора года: его не удалили и не форсировали звонком «на всякий случай», а перенесли в отдельную воронку, чтобы он перестал искажать конверсию остальных сделок.

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

Шаг 5. Кто и когда смотрит. Руководитель отдела — ежедневно, по красным меткам. Собственник или коммерческий директор — раз в неделю, по агрегированной динамике: растёт ли доля зависших сделок или падает.

ИИ-связка: реактивация и скоринг зависших сделок

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

Конвейер выглядит так: CRM (amoCRM или Bitrix24) → вебхук при переходе сделки в статус «пауза» дольше нормативного срока → запрос к модели с историей переписки и звонков → результат (причина паузы, тон, черновик сообщения) пишется в кастомное поле сделки и создаёт задачу менеджеру на согласование → менеджер утверждает или правит текст → отправка. Автоматика не отправляет сообщение сама — она готовит черновик, решение остаётся за человеком. Это осознанное ограничение: компания, с которой я работал, сначала тестировала реактивацию именно на «паузниках» — клиентах, которые и так не двигались, — чтобы не рисковать активной базой, если модель ошибётся с тоном.

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

Определи:
1. Вероятную причину паузы клиента. Выбери одну категорию: "цена", "не готов морально", "не устроил менеджер", "технический сбой / нет ответа", "неизвестно".
2. Рекомендуемый тон обращения при реактивации: "мягкий", "деловой", "срочный".
3. Черновик первого сообщения для реактивации, не длиннее 400 символов, без давления и без прямого упоминания причины паузы.

Верни строго JSON без пояснений вне JSON:
{"deal_id": число, "pause_reason": "строка", "tone": "строка", "confidence": число от 0 до 1, "reactivation_message": "строка"}

Входные данные:
{
  "deal_id": 48213,
  "last_contact_date": "2025-01-14",
  "status": "пауза",
  "days_in_status": 47,
  "messages": [
    {"from": "client", "text": "Нам нужно посоветоваться, возьмём паузу"},
    {"from": "manager", "text": "Хорошо, на связи, звоните когда решите"}
  ]
}

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

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

{
  "deal_id": 48213,
  "pause_reason": "не готов морально",
  "tone": "мягкий",
  "confidence": 0.71,
  "reactivation_message": "Добрый день! Не тороплю с решением, но если появятся вопросы — я на связи и всегда рад помочь разобраться."
}

Второй, более простой сценарий — для компаний, у которых пока нет ресурсов на вебхуки в CRM. Выгрузка зависших сделок в Google Sheets, скрипт на Apps Script раз в сутки отправляет строки в модель для быстрой сегментации: «мёртвая» или «живая без ответственного».

Ты сортируешь список сделок из выгрузки CRM (Google Таблица) по вероятности реактивации.
На входе строка: имя клиента, дата последнего касания, текущий статус, количество дней в статусе, сумма сделки (тыс. руб.).

Отнеси сделку к одной из категорий:
- "реактивация" — стоит звонить в ближайшую неделю
- "резерв" — вернуться через 2-3 месяца
- "архив" — переносить в отдельную воронку, не считать в текущей конверсии

Верни одну строку в формате: категория; краткое обоснование (не длиннее 12 слов).

Данные:
Клиент: ООО Ромашка, последний контакт: 2024-03-02, статус: "ожидание документов", дней в статусе: 540, сумма: 70

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

архив; 540 дней без движения, сумма ниже среднего чека, причина паузы не зафиксирована

Инженерная обвязка здесь простая, но обязательная: лимит на количество запросов в минуту (чтобы не упереться в rate limit при массовой выгрузке в сотни строк), лог каждого ответа модели с deal_id — иначе при сбое непонятно, какие сделки уже обработаны, и fallback-правило «если API недоступен или confidence ниже 0,4 — сделка уходит в очередь на ручной разбор, а не отправляется автоматом». Без этого правила один сбойный ответ модели может улететь клиенту как есть.

Экономика: во что обходится каждый потерянный процент конверсии

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

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

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

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

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

Если внедрять всё сразу — не начнёте ничего. Порядок действий на ближайшую неделю такой:

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

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

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

Как понять, что заявки теряются между отделами?

Выгрузите из CRM все сделки без движения дольше нормативного срока по стадии и сравните дату в системе с датой реального последнего звонка. Если руководитель не может назвать причину паузы за 10 секунд, глядя в карточку, — заявка потеряна, а не «на паузе».

Кто должен отвечать за заявку при передаче между отделами?

Один именованный сотрудник на каждом этапе, зафиксированный в CRM, с конкретным сроком реакции. Как только ответственный определяется правилом «первый свободный» или «кто увидит», заявка проваливается — проверено на нескольких отделах.

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

Выносить в отдельную воронку реактивации, не смешивая со свежими сделками. Иначе он искажает конверсию всего отдела и маскирует реальную скорость закрытия остальных заявок.

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