Как найти горячую заявку среди мусорных

Почему горячие заявки тонут среди мусорных

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

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

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

Что должно произойти в первые минуты после заявки

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

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

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

Робот-квалификатор — первый фильтр до менеджера

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

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

В действующем проекте GetGate 27% заявок приходят вечером и в выходные — раньше на них отвечали только утром следующего дня. С роботом ответ идёт сразу, независимо от времени суток, и заявка не остывает, пока ждёт начала рабочего дня.

Скоринг и роутинг в AmoCRM: как это настроено

Разметка «горячий / тёплый / холодный» — это не абстрактная система в CRM, а конкретные поля и теги в карточке сделки. Под каждый признак — источник обращения, тип запроса, готовность клиента отвечать — заводится своё поле, а digital pipeline двигает сделку по этапам воронки автоматически, без ручного перетаскивания карточек.

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

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

Как отличить горячую заявку от мусорной

Для B2B и услуг триггером обычно служит не сам факт обращения, а то, что человек говорит: конкретные сроки, названная задача, готовность обсуждать условия. Фраза «расскажите подробнее» без деталей — это одно, а «нужно решить вопрос до конца недели, вот бюджет» — совсем другое, даже если оба пришли с одной формы на сайте.

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

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

Что видит менеджер, когда заявка уже размечена

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

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

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

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

Скоринг на входе решает только половину задачи. Даже с правильной разметкой заявка может потеряться дальше — если менеджер увидел статус «горячая», но не позвонил вовремя или отложил звонок на потом. Тут нужен отдельный контур, который проверяет не заявку, а действие человека с ней.

Контроль качества — это когда ИИ слушает звонки и читает переписки, оценивает их по чек-листу и проверяет, отреагировал ли менеджер на горячую заявку так, как положено. Здесь же ищут «сливы» — случаи, когда заявка формально обработана, но по сути потеряна.

В нашей проверке на реальной переписке в 80% случаев ответ ассистента был не хуже ответа человека при слепом сравнении. Это не гарантия качества конкретного диалога, а ориентир: автоматический ответ на этом этапе можно сопоставлять с работой менеджера, а не считать заведомо хуже.

С чего начать, если заявки уже теряются

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

Дальше собирается CRM под процесс, робота обучают под нишу конкретного бизнеса и подключают нужные каналы — там, где реально приходят заявки, а не там, где удобнее интеграция. Это описано в построении отдела продаж — вместе со скриптами, регламентами и разбором причин отказов.

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