Мёртвая CRM — это система, в которой карточки заводятся, а решения принимаются мимо неё. Практически всегда её делают такой не одним решением, а восемью мелкими настроечными, каждое из которых в момент принятия выглядело осторожным и разумным. Пусть поле будет обязательным — вдруг пригодится. Пусть все видят всё — так удобнее подменять друг друга. Пусть воронка повторяет отчёт, который собственник просит раз в месяц.
Хорошая новость в том, что все восемь диагностируются самостоятельно и быстро: на каждую нужно около десяти минут в интерфейсе, доступ администратора и одна учётная запись рядового менеджера для сравнения. Подрядчик для проверки не нужен — он понадобится только для исправления, и то не всегда.
Ниже — восемь ошибок с проверкой каждой, цена двух из них в рублях на потоке в 500 заявок, разбор трёх, которые не видно в интерфейсе вообще, порядок исправления, при котором не теряются текущие сделки, и честный ответ на вопрос, что делать с данными, уже собранными по неправильной схеме. Управленческие ошибки автоматизации продаж — не тот же процесс и не те же ошибки, они разобраны отдельно в материале про восемь ошибок автоматизации продаж; здесь речь именно про настройки.
Восемь ошибок и проверка каждой за десять минут
Проверки выстроены так, чтобы результат был однозначным: вы либо видите признак, либо нет. Оценочных формулировок вроде «система выглядит перегруженной» здесь нет намеренно — на них нельзя опереться при разговоре с подрядчиком.
| Ошибка | Проверка за десять минут | Признак, что ошибка есть |
|---|---|---|
| Тридцать обязательных полей | Выписать список обязательных полей и вычеркнуть те, что встречались хотя бы в одном отчёте за квартал | Остаётся меньше половины; в карточках попадаются прочерки, точки и «уточнить» |
| Воронка построена под отчёт, а не под процесс | Спросить у трёх менеджеров, что должно произойти, чтобы сделка ушла на следующий этап | Три разных ответа; хотя бы один этап нельзя подтвердить событием в системе |
| Дублирующие воронки | Открыть список воронок и посчитать, в скольких есть сделки за последние 30 дней | Живых меньше половины; одна и та же сделка ведётся сразу в двух |
| Автоматизации без владельца | Открыть список роботов и бизнес-процессов, по каждому спросить, кто менял его последним и зачем | По трети списка ответа нет; есть отключённые с пометкой «мешало» |
| Права «всем всё» | Зайти под учётной записью рядового менеджера и попробовать выгрузить всю базу в файл | Выгрузка получилась; менеджер видит чужие сделки и суммы |
| Нет источника лида | Построить отчёт по сделкам за месяц с группировкой по источнику и посмотреть строку «не заполнено» | Доля незаполненных выше 20 %; в списке источников есть «другое» и «сайт» одновременно |
| Задачи без срока | Отфильтровать сделки в работе, у которых нет ни одной задачи с датой | Доля выше 25 %; есть задачи с датой в прошлом году |
| Интеграции без мониторинга | Спросить, кто узнаёт первым, если обмен с учётной системой встал, и когда это было в последний раз | Ответ «узнаём от клиента» или «не помним»; никто не может назвать дату |
Семь ошибок из восьми стоят вам времени и качества данных, и их можно чинить по плану. Права доступа стоят самой базы: выгрузка контактов и сумм сделок уходит вместе с уволившимся менеджером за две минуты и не оставляет следов, если журнал экспорта не включён. Если проверка под учётной записью менеджера прошла успешно, остальное подождёт — что именно закрывается настройками за один день, разобрано в материале про права доступа в CRM.
Абстрактный нарисованный экран карточки сделки (не скриншот реального продукта). Слева вертикальный столбец из 31 поля со звёздочкой «обязательное». Одиннадцать полей выделены и соединены тонкими линиями с блоком справа «отчёты руководителя». Остальные двадцать оставлены серыми, часть заполнена прочерками и словом «уточнить», рядом выноска «+6 минут к заведению карточки». Внизу подпись: «500 карточек в месяц × 6 минут = 50 часов». Чертёжный стиль, подписи по-русски.
Что две из этих ошибок стоят на потоке в 500 заявок
Модель — отдел из шести менеджеров и 500 заявок в месяц. Считаем две ошибки, которые поддаются прямому счёту: лишние обязательные поля и незаполненный источник лида. Остальные шесть считаются косвенно, через качество решений, и потому в расчёт не идут — так честнее.
Вторую строку часто пытаются закрыть требованием «менеджер обязан заполнять источник». Это не работает по простой причине: менеджер источника не знает. Клиент не помнит, откуда пришёл, а если и помнит, называет последнее касание, а не первое. Источник должен приезжать со стыка — из меток на сайте и подменных номеров телефонии, — и тогда поле заполняется само; как это устроено, разобрано в материале про автозаполнение карточек CRM.
Три ошибки, которых не видно в интерфейсе
Пять ошибок из восьми видны глазами: поля, воронки, права. Три остальные не имеют визуального признака вообще — система выглядит идеально настроенной ровно до того дня, когда становится ясно, что решения принимались на неверных данных.
- 1Воронка построена под отчёт, а не под процесс
Этапы придуманы так, чтобы красиво выглядел месячный отчёт: «в работе», «в проработке», «на согласовании». Ни один из них не соответствует событию, которое совершает клиент, поэтому менеджеры двигают сделки по ощущению, а конверсия по этапам не значит ничего. Признак: три менеджера дают три разных ответа на вопрос, что переводит сделку дальше. Правило исправления: у каждого этапа должно быть событие, которое видно в системе — письмо, документ, запись разговора, оплата.
- 2Автоматизации без владельца
За два-три года в системе накапливаются десятки роботов: кто-то настроил рассылку, кто-то автосмену ответственного, кто-то уведомление в чат. Люди уволились, роботы остались. Признак: по трети списка никто не может сказать, зачем он. Правило исправления: у каждой автоматизации в описании записываются владелец и цель одной строкой; всё, у чего нет владельца, отключается на две недели — если никто не заметил, удаляется насовсем.
- 3Интеграции без мониторинга
Самая дорогая из трёх. Обмен с учётной системой, телефонией или сайтом останавливается молча: в интерфейсе ничего не мигает, отчёты продолжают строиться на неполных данных. Признак: на вопрос «кто узнаёт первым» ответ «узнаём от клиента». Правило исправления: три дешёвые проверки — возраст последней успешной синхронизации на видном месте, контрольная запись, проходящая по обмену каждый час, и суточная сверка счётчиков; подробнее — в материале про мониторинг интеграций.
Мониторинг без ответственного превращается в поток уведомлений в общий чат, который перестают читать через месяц. Рабочая схема состоит из трёх ролей: кто замечает (система, а не сотрудник), кто разбирает первым (администратор или руководитель отдела — он смотрит три сигнала и решает, это сбой обмена или ошибка данных) и кто чинит (ответственный за интеграцию либо подрядчик по договору поддержки). Если третьей роли нет в договоре, чинить будет некому именно в тот момент, когда встанет.
Схема из трёх горизонтальных дорожек. Верхняя: «Воронка под отчёт» → «Менеджеры двигают сделки по ощущению» → «Конверсия по этапам ничего не значит». Средняя: «Автоматизации без владельца» → «Роботы работают после ухода авторов» → «Клиент получает письмо, которого никто не заказывал». Нижняя: «Интеграции без мониторинга» → «Обмен встал молча» → «Отчёты строятся на неполных данных». Справа общая скобка с подписью «в интерфейсе не видно ни одной». Чертёжный стиль, подписи по-русски.
Порядок исправления: что чинить первым
Порядок здесь важнее скорости. Интуитивно хочется начать с воронок — они на виду и раздражают сильнее всего. Это худший из возможных первых шагов: смена этапов на живой базе переносит открытые сделки, и часть из них теряется в момент переноса.
- 1Мониторинг обменов — первым, в первый же день. Пока обмен может встать незаметно, любая правка настроек будет множить расхождения, и вы не отличите последствия своих изменений от последствий простоя. Это работа на два-три часа и она не требует остановки работы отдела.
- 2Права доступа — вторым. Единственная ошибка, цена которой не в часах, а в потере базы целиком. Настраивается за день, менеджеров затрагивает минимально: видимость чужих сделок им обычно и не нужна.
- 3Два невосстановимых поля — третьим. Источник лида и дата следующего шага. Их особенность в том, что задним числом они не появятся никогда: каждый день без них — это безвозвратно потерянные данные. Источник подключается со стыка, дата следующего шага делается обязательной при закрытии карточки.
- 4Чистка полей — четвёртым, и не удалением. У лишних полей снимается обязательность, и они убираются с формы создания. Удалять нельзя: старые отчёты, построенные на этих полях, сломаются, а история заполнения исчезнет. Поле остаётся в системе, но перестаёт мешать.
- 5Воронки — последними и с параллельным периодом. Новые этапы включаются рядом со старыми, открытые сделки переносятся вручную по письменной таблице соответствия, старая воронка закрывается только после того, как в ней не осталось живых сделок. На отделе из шести человек это две-три недели.
- 6Автоматизации — по остаточному принципу, но обязательно. Разбор списка роботов делается последним, потому что после чистки полей и воронок часть из них всё равно придётся переписать. Отключение без владельца на две недели — самый дешёвый способ понять, что нужно.
Горизонтальная лента времени с шестью засечками в порядке: «День 1 — мониторинг обменов», «Дни 2–3 — права доступа», «Неделя 1 — источник лида и дата следующего шага», «Неделя 2 — снятие обязательности с 20 полей», «Недели 3–5 — новая воронка с параллельным периодом», «Неделя 6 — разбор автоматизаций». Под засечкой «параллельный период» подпись «старая воронка закрывается, когда в ней не осталось живых сделок». Слева от ленты вертикальная выноска «нельзя начинать отсюда» напротив воронок. Чертёжный стиль, подписи по-русски.
Что делать со старыми данными
Данные, собранные по неправильной схеме, задним числом не чинятся — они помечаются. Главное правило: у отчётности появляется граница даты. Всё, что строится на новых полях, считается от дня перенастройки; всё, что раньше, отдельно и с оговоркой. Попытка «дозаполнить» год назад руками даёт худший из возможных результатов — данные, которые выглядят достоверными, но собраны по памяти.
| Что потеряно | Восстанавливается | Как | Ограничение |
|---|---|---|---|
| Источник лида | Частично | Сопоставление по времени и номеру с логами сайта и телефонии | Глубина хранения логов, обычно от 3 до 12 месяцев |
| Время первого ответа | Да, по звонкам и почте | Из журнала телефонии и почтового ящика по контакту | Только каналы с журналом: переписка в личных мессенджерах не восстанавливается |
| Причина отказа | Нет | Только опросом менеджеров по сделкам последнего месяца | Это память, а не факт; в отчёты такие значения не ставят |
| Сумма фактической отгрузки | Да | Из учётной системы по номеру документа или ИНН | Нужен ключ связи; при обмене по названию организации не сойдётся |
| Этап сделки на прошлую дату | Только если велась история изменений | Из журнала изменений CRM | Часть систем хранит журнал ограниченный период |
Практическое следствие для отчётов: пока не накопится хотя бы квартал данных по новой схеме, годовые сравнения строить нельзя, и в отчёте это лучше писать прямым текстом. Какие поля под какими отчётами обязаны быть заполнены, разобрано в материале про отчётность руководителю из CRM.
Когда настройку лучше не трогать
Перенастройка живой CRM — это риск потерять текущие сделки, и он оправдан не всегда. Есть четыре ситуации, в которых правильный ответ — не чинить.
- В ближайший квартал запланирована смена системы. Все восемь исправлений придётся делать заново в новой CRM, а перенос данных всё равно потребует чистки. Разумно сделать только два пункта: мониторинг обменов и права доступа — они переезжают вместе с процессом, а не с системой.
- Идёт активный проект внедрения. Правки настроек параллельно с работами подрядчика создают ситуацию, в которой невозможно понять причину любой поломки. Найденное фиксируется списком и передаётся в проект как требования, а не чинится своими руками в обход.
- Отдел из двух-трёх человек и поток до 40 сделок в месяц. Здесь мёртвая CRM не создаёт заметных потерь: руководитель держит сделки в голове, а лишние поля просто не заполняются. Смысл имеет ровно один пункт — дата следующего шага. Почему при таком размере люди объективно быстрее работают мимо системы, разобрано в материале про то, что менеджеры не ведут CRM.
- Причина не в настройках. Если проверки прошли чисто, а системой всё равно не пользуются, вопрос управленческий, а не технический: нет владельца процесса, нет обязательности, работа оценивается по цифрам вне CRM. Настройка в этом случае лечит симптом и через квартал вернёт то же состояние.
Обязательным должно быть поле, без которого не построится отчёт, а не поле, которое кажется полезным.
