Как наладить контроль просроченных решений по возврату лидов
Просроченное решение по возврату лида бьет по выручке тише, чем отказ клиента, но ущерб дает не меньший. Деньги уже вложены в привлечение, интерес уже был, контакт уже состоялся, а дальше лед завис без решения. Я встречал одну и ту же картину в разных компаниях: менеджер обещал перезвонить, руководитель не видел задержку, собственник узнавал о потере через месяц по слабой конверсии. Проблема не в лени сотрудников. Проблема в том, что у возврата лида нет срока, владельца решения и понятного статуса.
Под возвратом лида я имею в виду повторную работу с контактом, который не купил с первой попытки, ушел на паузу, попросил вернуться позже, не ответил после предметного диалога или выпал из процесса после расчета. Если компания не различает такие случаи, сотрудники закрывают задачу формально. Для контроля нужна не общая идея заботы о клиентах, а короткий набор правил: когда лид уходит на возврат, кто принимает решение по сроку следующего касания, сколько дней дается на реакцию, что считается просрочкой, кто видит нарушение в день его появления.
Сначала я советую убрать путаницу в определениях. У лида на возврате есть два ключевых поля: причина возврата и дата следующего решения. Не дата звонка ради активности, а дата, к которой сотрудник обязан принять решение. Решение выглядит просто: вернуть в работу, закрыть как потерянный, передать другому менеджеру, отправить в отложенный список с новым сроком. Пока в системе нет поля именно для решения, команда прячет бездействие в заметках и задачах. Собственник видит движение, но не видит зависание.
Основа системы
Рабочая схема начинаеттся с единого статуса. Я не дроблю его на десятки вариантов. Хватает трех уровней: новый возврат, в работе, просрочен. Причина хранится отдельно. Тогда отчет не разваливается на мелкие категории, а руководитель за минуту видит объем проблемы. Если статусов слишком много, сотрудники выбирают удобную формулировку вместо действия.
Дальше задается норматив срока. Он разный для причин возврата, но не разный для каждого менеджера. Если клиент попросил связаться в определенный день, в системе фиксируется эта дата. Если контакт пропал после сметы, срок решения короче. Если разговор остановился из-за внутреннего согласования у клиента, срок длиннее, но у него все равно есть предел. Без единой нормы отдел живет личными привычками, а не правилами компании.
Следующий элемент — владелец решения. У каждого лида на возврате есть один ответственный. Не группа, не отдел, не менеджер плюс руководитель. Если подключается старший сотрудник, он получает задачу как новый владелец, а прежний перестает числиться ответственным. Иначе в спорной ситуации никто не виноват, потому что отвечали сразу двое.
После статусов и сроков я ввожу триггер просрочки. Триггер — это событие, после которого система переводит лид в список нарушений. Событие простое: дата решения прошла, а новый статус не установлен. Не нужно усложнять логику количеством попыток дозвона и длиной комментария. Решение либо принято, либо нет. Значит, просрочка наступила.
Как настроить контроль
Контроль не сводится к еженедельному отчету. При таком ритме потеря уже состоялась. Нужен дневной контур. Утром руководитель продаж открывает список просроченных решений по возврату лидов и видит четыре колонки: ответственный, дата просрочки, причина возврата, последняя активность. Этого хватает для разбора. Длинные таблицы с десятками полей мешают, а не управляют.
Я советую разделить контроль на два уровня. Первый уровень — оперативный. Руководитель отдела снимает просрочку в день появления: требует решение, меняет владельца, разбирает причину зависания. Второй уровень — собственник смотрит не каждый лид, а динамику: сколько возвратов создано, сколько просрочено, сколько возвращено в активную воронку, сколько закрыто без результата. Такой обзор нужен раз в неделю на одной странице. Если собственник погружается в каждую карточку, он подменяет руководителя. Если смотрит только выручку, он пропускает ранний сигнал.
Отдельно я фиксирую правило комментария. По каждому просроченному решению сотрудник оставляет короткую запись в одном формате: что мешает, какое решение принято, когда следующая контрольная точка. Свободный текст без шаблона не годится. В нем прячут эмоции, оправдания и лишние детали. Нужна запись, по которой руководитель понимает ситуацию за десять секунд.
Дальше идет разбор причин просрочки. Их обычно немного: перегрузка менеджера, неясный регламент, слабая дисциплина, спорный лид без хозяина, некорректная постановка задач в CRM. Если сваливать все в категорию человеческого фактора, система не лечится. Я всегда смотрю, где именно возник разрыв: сотрудник не увидел срок, увидел и отложил, не понял полномочия, не захотел закрывать пустой контакт, потому что боялся ухудшить личную статистику. У каждой причины свой способ исправления.
Чтобы контроль не превратился в наказание ради наказания, нужна связка с метрикой результата. Я измеряю не только число просроченных решений, но и долю возвращенных лидов, которые снова вошли в активную продажу, а потом купили. Тогда видно, где отдел реально теряет деньги, а где спорит о дисциплине на пустом месте. Если возвраты не дают продаж, вопрос уже не в сроках, а в качестве первичной квалификации, скрипте, предложении или составе базы.
Типичные ошибки
Первая ошибка — считать возврат лида второстепенной задачей. Менеджер закрывает новые заявки, а старые контакты откладывает на конец дня. Конец дня не наступает. Возврату нужен выделенный слот в расписании и отдельный план. Иначе он всегда проигрывает входящему потоку.
Вторая ошибка — хранить срок в личном календаре сотрудника. Компания теряет управление, потому что событие видно только владельцу. Срок решения живет в CRM, а не в мессенджере, блокноте или памяти. Руководитель обязан видеть просрочку без запроса к менеджеру.
Третья ошибка — путать активность с решением. Пять звонков без итога не закрывают вопрос. Комментарий «не дозвонился» не продлевает срок автоматически. Если контакт недоступен, сотрудник принимает решение по правилам: еще одна попытка в заданный период, перевод в другой сценарий, закрытие с причиной. Пока сотрудник просто фиксирует действия, лид продолжает висеть.
Четвертая ошибка — наказывать за каждую просрочку без разбора потока. Если у менеджера перегружен портфель, просрочка предсказуема. В таком случае меняют норму нагрузки, перераспределяют базу, сокращают число возвратов в работе. Иначе компания получает красивый отчет и ту же потерю выручки.
Пятая ошибка — не отделять качество лида от качества работы с ним. Возврат слабого контакта и возврат горячего клиента после расчета нельзя оценивать одинаково. Я ввожу приоритет по стадии и потенциалу сделки. Тогда руководитель сначала снимает просрочки там, где деньги ближе.
Если собственник хочет внедрить систему без лишнего сопротивления, путь простой. Сначала описать четыре правила: когда лид уходит на возврат, какой срок решения, кто владелец, что считается просрочкой. Потом настроить поля и отчет в CRM. После этого провести две недели ручного контроля, чтобы поймать обходные действия и спорные случаи. На третьей неделе закрепить разбор на уровне руководителя отдела. Через месяц собственник уже видит не ощущения команды, а точную картину: где лиды застревают, кто задерживает решения, сколько денег уходит из-за просрочки. С этого момента возврат лидов перестает быть серой зоной и становится управляемым участком продажа.
