Уведомления о спящих лидах: как вернуть забытую сделку

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

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

Когда лид действительно считается спящим?

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

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

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

Спящий лид и закрытая сделка — это одно и то же?

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

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

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

Почему напоминаний недостаточно и нужны уведомления?

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

В продукте это соответствует вполне конкретному поведению. Уведомление о спящем лиде автоматически уходит назначенному менеджеру по записям без активности на 14, 30 и 60 дней — вопрос «кто должен был этим заняться» переезжает из чьей-то памяти в отметку времени самой записи. Зеркальная логика работает в Уведомлениях об изменении скоринга: команда получает сигнал, когда балл пересекает 80, пересекает 50 или разом подскакивает на 15 пунктов. Одно ловит тишину, другое — внезапный интерес.

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

Что показывают пороги в 14, 30 и 60 дней?

Каждый порог указывает на свою поломку и требует своего действия. Четырнадцать дней — обычно место, где оборвалась цепочка касаний: разговор был, интерес был, а потом что-то помешало. Тридцать дней — момент, когда запись выпала из повестки и контекст остыл: собеседник, скорее всего, уже не помнит деталей прошлого разговора. Шестьдесят дней — фактическая точка решения: либо переквалифицировать запись, либо записать причину и закрыть.

Неактивность	Что это обычно значит	Ожидаемое действие
14 дней	Цепочка касаний оборвалась, интерес скорее всего сохранился	Короткое сообщение в том же канале
30 дней	Запись выпала из повестки, контекст остыл	Звонок с новым поводом; проверка источника и кампании
60 дней	Формально в списке, фактически вне процесса	Переквалифицировать вопросами или закрыть с причиной
Ответа не было ни разу	Первый контакт не состоялся, отсчёт по сути не начинался	Отдельная очередь, другой канал и другое время суток

Эти числа не священны. При длинном цикле сделки лучше подойдут 30-60-90, а команде, которая закрывает сделку за неделю, — 3-7-14. Неизменным остаётся принцип: у каждого порога ровно одно ожидаемое действие. Уведомление без описанного действия за пару недель превращается в оповещение, которое все закрывают не читая.

Что делать в первые полчаса после уведомления?

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

Второй шаг — проверить, квалифицирована ли запись до сих пор. Что вы знаете про бюджет, процесс принятия решения, объём потребности и сроки? Рамка квалификации вроде MEDDIC здесь работает как короткий чек-лист: какое измерение пустует, то и становится целью разговора о возврате. Звонок с целью «узнать, как дела» почти всегда заканчивается второй тишиной.

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

Как построить сообщение для возврата?

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

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

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

Какие спящие записи будить не стоит?

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

Закрытие — не потеря, а данные. Причины вроде «нет бюджета», «ушли к другому подрядчику», «проект отложен» показывают, какой сегмент действительно имеет смысл поднять в следующем квартале. В Rocketly удалённая запись попадает в Корзину и по умолчанию 30 дней остаётся восстановимой вместе со всей историей активности, то есть неверное массовое решение — исправимая ошибка, а не окончательная.

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

Кому приходит уведомление и что будет, если им никто не займётся?

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

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

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

Из каких шагов состоит настройка?

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

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

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

По каким показателям видно, что это работает?

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

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

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

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

Если хотите проверить пороги на собственном списке, откройте бесплатный аккаунт и настройте их на уже имеющихся записях.

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

Каким должен быть порог спящего лида в днях?

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

Обязательно ли звонить по каждой записи с уведомлением?

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

Можно ли просто отправить спящим лидам массовую рассылку?

Массовая отправка даёт масштаб, но теряет контекст, и доля ответов остаётся низкой. Лучший результат даёт разделение: персональные касания для записей с высоким баллом и кампания для длинного хвоста с низким.

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

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