Сделка не срывается громко. Она тихо просрочивается
Никто не теряет клиента осознанно. Менеджер просто забыл перезвонить, задача висела на «завтра» три дня, клиент тем временем ушёл к тому, кто ответил быстрее. CRM, которая просто хранит задачи, тут бесполезна — она ждёт, пока человек сам зайдёт и проверит. А он не зайдёт: если бы заходил и проверял, задача бы не просрочилась.
Это ключевая мысль, из-за которой большинство «систем контроля» не работают. Они устроены как витрина: приди и посмотри. Но приходит смотреть тот, у кого и так всё в порядке, а тот, у кого завал, в систему как раз и не заходит — потому что там страшно.
Система должна не показывать просрочки тому, кто и так их не смотрит, а бить тревогу до того, как они стали потерей, — и делать это на трёх уровнях.
Три уровня контроля
Уровень менеджера. Просроченная задача не тонет в общем списке — она подсвечивается и всплывает наверх. Утром первое, что видит продавец: не «всего 47 задач», а «3 просрочено, начни с них». Список из 47 глаз пропускает, а три подсвеченные — нет.
Тут важна не подсветка сама по себе, а то, что просрочки вынесены в отдельный экран, с которого начинается день. Если они просто покрашены красным внутри общего списка, через неделю красный перестаёт читаться — глаз привыкает к цвету быстрее, чем к смыслу.
Уровень руководителя. РОП (руководитель отдела продаж) не должен вручную обходить восемь менеджеров и спрашивать, у кого что висит. Система сама собирает картину: у кого сколько зависших сделок, на какую сумму, сколько висят дольше суток. Это не слежка за людьми, а раннее предупреждение по деньгам — видно, где завал копится прямо сейчас.
Хорошая сводка отвечает не на вопрос «кто плохой», а на вопрос «где сегодня горит». Разница практическая: первая формулировка порождает оправдания, вторая — действия. Поэтому в сводке на первом месте стоят деньги и сроки, а фамилия — на втором.
Уровень автоматики. Самое важное: часть просрочек вообще не должна доходить до человека. Если клиент не ответил на звонок или сообщение — робот сам перезвонит или отправит напоминание. Менеджер подключается только там, где на том конце есть живой контакт, а не тратит день на дозвоны в пустоту.
Это снимает с отдела основную массу механической работы. Большая часть «просрочек» на холодных и полутёплых контактах — это не забывчивость, а физическая нехватка рук: человек не может обзванивать базу и одновременно вести живые сделки. Отдайте машине повторные касания там, где касание типовое, и у людей освободится время на то, где нужен человек.
Почему «напоминалки» не работают
Встроенные уведомления в SaaS-CRM легко отключаются и быстро превращаются в фон, на который перестают реагировать. Через неделю всплывашки — это шум, который закрывают не глядя. Рабочая схема — не уведомление, а эскалация: не отреагировал менеджер за N часов — задача всплывает у РОПа, ещё через интервал — у владельца.
Смысл эскалации в том, что у забытой задачи всегда есть следующий, кто её увидит. Она не может тихо умереть на одном человеке. На своём сервере правила эскалации настраиваются под вашу скорость сделок: где-то «просрочка» — это два часа, где-то трое суток. Усреднённый шаблон вендора этого не знает.
И ещё одно отличие эскалации от напоминалки: у неё есть конец. Уведомление можно закрыть, и оно исчезнет. Эскалация закрывается только действием — задача либо выполнена, либо перенесена с новой датой, либо сделка закрыта с причиной. Третьего состояния «я это видел» не существует, потому что именно оно и превращает контроль в ритуал.
Не всякая просрочка одинаково опасна
Задача по холодному лиду и задача по сделке на финальной стадии с большим чеком — разный уровень тревоги. Если система подсвечивает их одинаково, важное тонет среди мелочи, и эскалация теряет смысл: РОП устаёт от потока «горящего» и перестаёт реагировать даже на настоящее.
Поэтому просрочку нужно взвешивать по сумме сделки и стадии. Зависший договор на этапе оплаты подсвечивается резче и эскалируется быстрее, чем неперезвон по сырому контакту без бюджета. Тогда наверху списка всегда стоит то, где на кону реальные деньги.
Третий множитель, про который обычно забывают, — источник. Лид, за который вы заплатили деньгами рекламы, и лид, пришедший сам по рекомендации, стоят по-разному ещё до того, как менеджер снял трубку. Если платный трафик у вас дорогой, просрочка по нему должна гореть ярче.
Как договориться о слове «просрочка»
Прежде чем настраивать эскалацию, надо решить, что вообще считается просрочкой. Иначе половина споров в отделе будет о том, виноват менеджер или нет.
Рабочий способ — прописать срок реакции отдельно для каждой стадии, а не один на всю воронку:
- Свежая заявка. Здесь счёт идёт на минуты, и это единственная стадия, где стоит быть радикальным: клиент ждёт звонка, пока помнит, что оставлял заявку.
- Первый контакт состоялся, ждём решения. Срок задаётся вашим циклом сделки.
- Отправлено коммерческое или расчёт. Молчание после отправки документа — самая частая точка тихой потери.
- Согласование и оплата. Тут просрочка стоит дороже всего: клиент уже решил купить, и потерять его на этом этапе обиднее, чем на любом другом.
Конкретные цифры сроков я специально не называю — они у каждого свои, зависят от цикла сделки и от того, сколько альтернатив у клиента. Возьмите свои реальные сделки за последний квартал, посмотрите, через сколько после последнего касания клиент переставал отвечать, и оттолкнитесь от этого. Цифры будут ваши, а не из статьи.
Как включить эскалацию и не превратить её в шум
Порядок, который у нас работает:
- Начните с одной стадии, а не со всей воронки. Возьмите ту, где теряете больше всего денег, — обычно это «отправили расчёт, ждём». Настройте эскалацию только там.
- Первый шаг эскалации — не человек, а автоматика. Прежде чем дёргать РОПа, пусть система сама напомнит клиенту и менеджеру.
- Второй шаг — руководитель, но со сводкой, а не с потоком. Не отдельное уведомление на каждую задачу, а один список раз в день, отсортированный по деньгам.
- Третий шаг — владелец, и только по крупному. Если владельцу прилетает всё подряд, он выключит это на второй неделе.
- Замерьте, сколько раз эскалация сработала за первую неделю. Если сработала на большинстве задач — пороги слишком жёсткие, эскалация превратится в фон. Если ни разу — слишком мягкие, вы её не почувствуете.
- Подкрутите пороги и добавьте следующую стадию. И так по одной, а не всё сразу.
Главная ошибка внедрения — включить эскалацию везде в первый же день. Отдел получает лавину, руководитель получает лавину, через неделю все просят выключить, и механизм закапывается вместе с идеей.
Лавина при импорте старой базы
Отдельная ловушка, о которой стоит знать заранее. Когда вы заливаете в новую систему накопленную базу, все контакты с давними касаниями мгновенно становятся «просроченными» — и механизм контроля захлёбывается в первый же час.
Мы через это проходили: при чистке одной базы после отсева нерабочих и дублирующихся номеров осталось 222 номера, с которыми имело смысл работать. Всё остальное было мусором, который при прямом импорте создал бы поток «горящих» задач ни о чём.
Поэтому порядок такой: сначала чистка базы, потом импорт, и только потом включение правил просрочки. Импорт «как есть» с включённой эскалацией — надёжный способ убить доверие к системе на старте.
Сторож тоже ломается — и это самая опасная поломка
Механизм контроля просрочек сам должен быть под контролем. Если он тихо отвалится, вы этого не заметите: пустой список просрочек выглядит ровно как отдел, у которого всё хорошо.
Три наши грабли ровно про это.
Воронка показала конверсию 100% — потому что отказы просто не доезжали до отчёта. Цифра была прекрасная и абсолютно бессмысленная, и заметили это далеко не сразу: красивый отчёт не вызывает подозрений.
Сборщик данных отдавал нули вместо ошибки. Когда у него слетала сессия, он возвращал не «я сломался», а «данных нет». Замершие цифры читались как «роста нет», и поломка пряталась несколько дней подряд.
8 диалогов из 56 были не видны менеджерам из-за прав доступа — и в отчётах это никак не проявилось, потому что отчёт считал по базе, а не по тому, что реально видно на экране.
Вывод для контроля просрочек прямой: любой автоматический механизм обязан отмечаться после каждого прохода — и на успехе, и на падении. Молчание дольше порога надо считать поломкой. Иначе вы однажды обнаружите, что эскалация не работает уже месяц, а список просрочек пуст не потому, что просрочек нет.
Возражения и пограничные случаи
«Это же тотальный контроль, люди взбунтуются». Взбунтуются, если эскалация настроена на людей. Если она настроена на деньги и стадии — она читается как страховка, а не как надзор. Практическая разница в том, кому первым уходит сигнал: если менеджеру и только потом руководителю, схема воспринимается как помощь.
«Клиент сам попросил не беспокоить месяц». Значит, это не просрочка, а запланированная пауза, и в системе должна быть возможность её оформить — с датой и причиной. Если такой возможности нет, менеджеры начнут придумывать обходные пути, и вы потеряете достоверность данных целиком.
«Менеджер в отпуске». Его задачи не должны молча ждать выхода. Либо передача на время отсутствия, либо эскалация сразу на руководителя. Отпуск — самая предсказуемая причина потери сделок и самая простая в закрытии.
«У нас длинный цикл, там нормально молчать неделями». Длинный цикл не отменяет контроля, он меняет пороги. Молчать неделями нормально, а вот не иметь запланированной даты следующего касания — не нормально ни при каком цикле.
Подводные камни
- Слишком агрессивная эскалация обесценивает себя. Если наверх летит каждая мелкая просрочка, руководитель за неделю привыкает и перестаёт реагировать — ровно как с напоминалками. Эскалировать нужно взвешенно, по деньгам и стадии.
- Робот-дожим без порога уверенности бесит клиентов. Автодозвон и авто-напоминания хороши, пока не превращаются в долбёжку. Нужна логика «одно касание — и стоп», иначе автоматика сама сжигает лояльность.
- Эскалация без выделенного времени у РОПа — тупик. Если задачи всплывают наверх, но у руководителя нет ни минуты их разбирать, механизм мёртв. Контроль просрочек — это чья-то ежедневная работа, а не «когда-нибудь посмотрю».
- Пустой список просрочек — повод проверить механизм, а не радоваться. Сторож обязан отмечаться после каждого прохода, иначе тишина неотличима от поломки.
- Импорт старой базы с включёнными правилами даёт лавину. Сначала чистка, потом импорт, потом эскалация.
- Автодозвон и рассылки по базе — это обработка персональных данных. Мы не юристы, но основания для касаний и учёт согласий по 152-ФЗ стоит проверить до запуска, а не после.
Как это проверить у себя
Откройте CRM и найдите сделки, где последнее касание было больше трёх дней назад, а сумма значимая. Если такие есть и никто про них не знал — у вас нет механизма ловли просрочек, есть только их хранилище.
Второй тест: спросите, что произойдёт, если менеджер сегодня не откроет систему. В рабочей схеме ответ — «его задачи всплывут у руководителя». В нерабочей — «ничего, сделки просто зависнут».
Третий тест, самый недооценённый: выключите механизм эскалации на день и посмотрите, заметит ли кто-нибудь. Если не заметит никто — он и не работал, просто вы этого ещё не знали.
Цель простая: ни одна сделка с деньгами не должна молча умереть от того, что про неё забыли.
Разберём ваши узкие места — оставьте заявку в форме или напишите в Telegram.
