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

Контроль заявок на стыке отделов: где конверсия падает с 55% до 22%

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

Самая обидная потеря в бизнесе — не проигранный конкурс и не ушедший к конкуренту клиент. Это заявка, на которую просто никто не ответил.

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

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

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

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

Где именно рвётся ваша цепочка

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

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

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

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

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

Заявки без ответственного: что покажут ваши цифры

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

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

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

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

Похожая история про май того же отдела: команда отвлеклась на апсейл действующей базе (на кону было направление с потенциалом около 500 000 ₽ в месяц) и перестала системно звонить новым контактам. План на месяц — 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 — сделка уходит в очередь на ручной разбор, а не отправляется автоматом». Без этого правила один сбойный ответ модели может улететь клиенту как есть.

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

Экономика: цена одного процента конверсии

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

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

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

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

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

Что делать вам в первую очередь

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

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

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

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

И назовём вещи именем. Умение удержать заявку на стыке — это управленческий навык, а не черта характера дружной команды. Руководитель, который открывает воронку и за минуту говорит, какие сделки стоят дольше норматива и кто по каждой отвечает, стоит дороже руководителя, который умеет только спросить на планёрке «ну как там продажи». Этому нигде не учили. Осваивать придётся на своей же выгрузке, и лучше сейчас, пока это стоит 9 сделок в месяц, а не годовой воронки.

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

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

Что я понял на своей истории

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

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

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

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

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

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

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

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

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

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

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

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

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