CRM для продаж: путь заявки, статусы и ответственность менеджера

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

CRM расшифровывается как customer relationship management — управление отношениями с клиентами. Так называют и рабочий подход, и поддерживающую его программу с карточками, воронками, задачами, правами и отчётами. Правила квалификации и смысл этапов определяет бизнес.

Эта статья разбирает общий процесс, а не выбор программы. Например, Битрикс24 объединяет CRM с задачами и коммуникациями, а у других систем набор модулей и названия сущностей будут иными. Но заявка всё равно должна получить понятный статус, владельца и следующее действие.

CRM не продаёт вместо команды. Она делает видимым, где команда теряет клиента, контекст или следующий шаг.

В разных продуктах названия и логика могут отличаться, но в отделе продаж обычно встречаются несколько базовых объектов.

Один контакт может участвовать в нескольких сделках, а у компании — быть закупщик, технический специалист и руководитель. Если свалить всё в одну карточку «клиент», CRM не покажет число реальных возможностей и их исходы.

Объекты CRM полезны только при обязательной работе команды внутри системы. Иначе карточка становится поздней копией переписки, а не местом, где можно принять следующее решение.

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

Дальше процесс выглядит так:

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

На экране воронка часто выглядит как доска с колонками. В управленческом смысле она описывает последовательность состояний сделки. У каждого рабочего этапа должны быть входное условие, ожидаемое действие, владелец и критерий выхода.

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

Полезный этап можно проверить четырьмя вопросами:

Отчёт по воронке становится достоверным только после того, как команда одинаково понимает смысл её этапов.

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

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

Полезнее разделить данные по моменту возникновения:

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

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

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

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

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

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

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

CRM хранит имена, телефоны, адреса электронной почты, переписку и другие сведения о людях. Для каждой цели обработки компания должна определить применимое законное основание, необходимый состав данных, срок хранения, круг доступа и порядок прекращения обработки, уничтожения или обезличивания. Федеральный закон № 152-ФЗ задаёт общую рамку обработки персональных данных в России, но не устанавливает одного срока для всей CRM-базы и не сводит любую обработку только к согласию или галочке под формой. Конкретные обязанности зависят от процесса, договоров, иных законных оснований и связанных требований законодательства.

Клиентская база — не склад контактов «на всякий случай», а рабочий набор данных с целью, владельцем и правилами доступа.

CRM может считать количество новых обращений, скорость первого действия, долю квалифицированных лидов, переходы между этапами, длительность сделки и причины отказов. Эти показатели описывают работу процесса, если исходные данные сопоставимы.

Количество карточек не равно спросу. В базу попадают тесты, спам, дубли, обращения поставщиков и повторные запросы. Конверсия этапа не равна вероятности продажи, если менеджеры по-разному двигают сделки. Среднее время ответа может выглядеть хорошо, если автоматическое письмо считается ответом, хотя клиент ждал содержательного звонка.

Для связи с маркетингом нужен устойчивый путь идентификаторов: визит или рекламный клик → отправка формы или звонок → контакт и сделка → коммерческий результат. Воронка продаж показывает переходы между определёнными состояниями, CRM — состояние работы с обращением. Это разные слои. Сквозная аналитика отвечает на следующий вопрос: как соотнести рекламский расход с подтверждённым коммерческим результатом. Нельзя заменить один слой другим, просто добавив одинаковое название кампании в отчёт.

Лучше начинать с небольшого набора проверяемых показателей:

Поэтому «лучшей CRM вообще» не существует: сначала описывают объект управления и путь клиента, затем выбирают подходящую модель данных.

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

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

Возьмите не презентацию поставщика, а одну реальную сделку и пройдите её от первого обращения до результата.

Если ответов нет, сравнивать интерфейсы рано. Карта процесса и данных станет основой выбора, интеграции и приёмки.

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

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