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