Контроль спящих договоров без потерь для выручки

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

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

Что считать неактивностью

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

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

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

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

Как устроить процесс

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

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

Ответственность я разделяю по ролям. Менеджер отвечает за актуальность контакта и причину простоя. Руководитель продаж — за срок реакции и качество решения. Финансовый блок — за сверку оплат, задолженности и кредитных условий. Юрист или договорной специалист — за корректное закрытие либо продление, если меняется формат отношений. Собственнику не нужен ручной разбор каждого случая. Ему нужен короткий отчёт по воронке договоров, где видно количество переходов между статусами, сумму потерянной выручки, долю возвращённых клиентов и средний срок бездействия.

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

Контроль и решения

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

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

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

Чтобы система не распалась через месяц, я добавляю несколько контрольных метрик. Доля договоров без движения сверх нормы. Средний срок нахождения в статусе «под наблюдением». Доля неактивных договоров, по которым причина не заполнена. Количество возвращённых в активную работу. Сумма выручки, восстановленной по спящим контрактам. Эти показатели я смотрю в динамике, а не по разовой цифре.

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

Я советую начинать внедрение без тяжёлого проекта. Сначала определить критерии неактивности, собрать реестр, назначить владельцев процесса, запустить еженедельный обзор и проверить первые результаты через месяц. После этого уже имеет смысл дорабатывать CRM, автоматические уведомления и дашборд (панель ключевых показателей). Если начать с автоматизации без правил, бизнес получит красивый экран с неточными данными.

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