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