Компании по-прежнему пытаются внедрять CRM как проект с финальной точкой: описать процессы, согласовать большое ТЗ, настроить систему, обучить команду и сдать результат. Проблема в том, что к моменту запуска часть решений уже приходится пересматривать.
По наблюдениям Анастасии Бурмистровой, фаундера проекта CRM Rating и международного коммуникационного сервиса ablab.pro, рынок постепенно уходит от идеи CRM, которую можно полностью спроектировать до запуска и затем годами не пересматривать. Эту же тенденцию видно в ответах интеграторов: базовый контур запускают раньше, а сложность добавляют после первых данных и обратной связи от пользователей.
Причина проста: до запуска компания знает свои процессы в основном из регламентов, интервью и представлений руководителей о том, как должна работать команда. После запуска становится видно, где реально теряются сделки, какие поля никто не заполняет, какие этапы сотрудники трактуют по-разному и какие автоматизации добавляют работу вместо того, чтобы ее сокращать.
Подробное ТЗ не гарантирует хороший запуск
Михаил Васянин («Ингруппа») среди самых неэффективных сценариев называет внедрения, где ТЗ прорабатывается слишком долго и подробно. Такие проекты рискуют застрять еще до полноценного запуска.
Проблема возникает, когда компания пытается заранее описать все будущие сценарии: каждое поле, исключение, автоматизацию и действие пользователя. Из-за этого подготовка подробного ТЗ может затянуть запуск.
В небольшом бизнесе это особенно заметно: вместо того чтобы запустить стандартную воронку, собрать обращения и посмотреть, как команда реально работает, компания начинает проектировать систему под процессы, которые еще никто не проверял внутри CRM.
Михаил Кузьмин (Scont и Biarch) предлагает для небольших компаний более короткий путь: коробочная конфигурация, основные каналы обращений, базовые правила работы – и дальнейшая настройка уже по результатам использования.
Для крупного бизнеса предварительный аудит необходим, если CRM связывает несколько подразделений, затрагивает учетные системы и меняет зоны ответственности. В таких проектах цена ошибки выше стоимости дополнительного этапа подготовки.
Поэтому объем проектирования должен зависеть от сложности конкретного бизнеса.
Начинать стоит с того, где компания теряет продажи
На первом этапе достаточно собрать обращения из основных каналов, зафиксировать коммуникации, создать понятную воронку, показать сделки без следующего действия и дать руководителю базовую картину продаж.
При таком подходе CRM сначала закрывает критический участок процесса, затем к нему добавляются интеграции, аналитика и автоматизация.
Роман Болдырев (R&D Agency) предлагает сначала добиться базовой дисциплины: сделки, задачи, звонки, коммерческие предложения. После этого становится понятно, что действительно имеет смысл дорабатывать.
Такой запуск быстрее обнаруживает реальные проблемы: может выясниться, что компании не нужна половина функций из первоначального ТЗ, или проявится ограничение, которое не удалось увидеть на этапе интервью с сотрудниками.
Поэтому первая версия CRM должна отвечать не на вопрос «какой будет наша система через три года», а на вопрос «какую потерю в продажах мы должны убрать первой».
Быстрый запуск и быстрый результат – разные вещи
В оценке первых результатов позиции экспертов расходятся. Кузьмин и Болдырев считают, что изменения можно увидеть достаточно быстро: становится меньше потерянных обращений, прозрачнее воронка, понятнее нагрузка менеджеров.
Дмитрий Семин осторожнее оценивает возможность быстрых результатов, поскольку CRM требует изменения привычек: на старте часть ресурса команды уходит на адаптацию, а показатели могут временно просесть.
Компании часто смешивают ожидания от запуска системы и от роста продаж. Итерационное внедрение позволяет раньше увидеть проблемные участки, оценить качество данных и понять, как команда работает в CRM, но само по себе не гарантирует роста продаж через несколько недель или быстрой окупаемости.
Нельзя автоматизировать процесс, который никто не может нормально объяснить
Быстрый запуск не должен становиться поводом для отказа от анализа процессов. Как отмечает Семин, если внутри бизнеса хаос, CRM даст «упорядоченный хаос».
Система не определит сама, что считать квалифицированным лидом, кто отвечает за сделку после передачи между отделами и когда менеджер должен закрыть ее как потерянную. Если внутри компании на эти вопросы отвечают по-разному, CRM просто закрепит расхождения.
Поэтому спор между аудитом и быстрым стартом на практике сводится к одному вопросу: какие решения слишком дороги, чтобы проверять их методом проб и ошибок.
Для простого отдела продаж можно начать с базовой схемы и быстро ее поправить, тогда как работа нескольких подразделений, сложная ERP-интеграция или финансовый контур требуют предварительной проработки.
Качество проекта зависит прежде всего от того, насколько точно команда понимает, какой бизнес-процесс она автоматизирует и зачем.
Сначала данные, потом AI
В 2027 году при внедрении CRM придется учитывать и ее роль как источника данных для AI: анализа звонков, подсказок менеджеру, подготовки follow-up, оценки вероятности сделки и автоматических действий.
Качество этих данных влияет на надежность AI: дубли, незаполненные карточки, разные трактовки этапов и потерянные коммуникации мешают не только аналитике, но и работе автоматических помощников и агентов.
Прежде чем передавать часть работы алгоритмам, нужно наладить стабильный сбор данных и согласовать, как в системе фиксируются основные события. Поэтому подключение AI не должно быть первым этапом проекта: без этой подготовки он может ускорить распространение ошибок.
Автоматизаций тоже может быть слишком много
CRM позволяет автоматически создавать задачи, менять статусы, отправлять уведомления, требовать заполнения полей и запускать цепочки сообщений, однако необходимость каждого правила стоит проверить в работе.
Чем больше правил появляется до того, как команда начала работать в системе, тем выше вероятность, что CRM будет обслуживать собственную логику вместо продаж.
При подключении AI нужно определить, какие действия система сможет выполнять самостоятельно, а какие потребуют проверки менеджера.
Подготовка черновика ответа и отправка сообщения клиенту без проверки предполагают разный уровень ответственности. Аналогично, оценка вероятности сделки и самостоятельное изменение коммерческих условий требуют разных правил контроля.
Поэтому при внедрении CRM в 2027 году важно заранее определить границы автоматизации и действия, за которые отвечает человек.
Интегратор становится важнее еще одного пункта в сравнении CRM
Васянин формулирует это коротко: «выбирайте интегратора, а не вендора».
Большинство зрелых CRM уже закрывают базовый набор задач: контакты, сделки, задачи, коммуникации, аналитику. Разница проявляется, когда систему нужно связать с телефонией, мессенджерами, ERP, BI, внутренними сервисами и AI, сделав ее частью общей IT-инфраструктуры компании.
При выборе CRM попросите показать на ваших типичных задачах, как заявка попадает в систему, назначается менеджеру и проходит по воронке. Проверьте удобство работы, нужные интеграции и возможность менять настройки без сложных доработок. Уточните полную стоимость: лицензии, перенос данных, подключение сервисов, обучение и поддержку. Это поможет сравнить системы по условиям работы, а не только по списку функций.
Одинаковая CRM в двух компаниях может дать совершенно разный результат из-за архитектуры проекта, качества интеграций и того, что происходит после запуска.
Если CRM развивается постоянно, работа интегратора должна включать сопровождение изменений или передачу этой компетенции внутрь компании. Простого выполнения первоначального ТЗ для этого недостаточно.
Возможно, менеджеру вообще не нужно заполнять столько полей
Один из самых устойчивых конфликтов при внедрении связан с тем, что сотрудники «не хотят вести CRM». Причина может быть как в рабочей дисциплине, так и в неудобстве самой системы.
Если после каждого разговора менеджеру нужно вручную написать резюме, изменить статус, заполнить несколько полей и поставить следующую задачу, CRM начинает конкурировать с его основной работой.
Именно здесь AI может дать наиболее понятный эффект: расшифровать разговор, извлечь договоренности, предложить следующий шаг, обновить часть данных.
Менеджер по-прежнему отвечает за качество данных, но часть ручного ввода система может взять на себя.
Поэтому при настройке CRM стоит оценить, какие действия можно выполнять автоматически без потери качества данных и где необходима проверка менеджера.
После запуска CRM все равно нужен человек, который принимает решения
При поэтапном внедрении работа продолжается после сдачи первой версии: нужно регулярно решать, какие поля удалить, какие интеграции добавить, почему менеджеры обходят новый процесс и какие действия можно автоматизировать или передать AI.
Такая работа ближе к управлению продуктом, чем к администрированию программы, поскольку каждую доработку нужно соотносить с задачами бизнеса.
За нее может отвечать CRM owner, специалист по RevOps или руководитель продаж – важно, чтобы этот человек определял приоритеты изменений и оценивал их пользу. Это поможет избежать доработок, которые добавляют функции, но не решают рабочих задач.
Как внедрять CRM в 2027 году
Сначала нужно определить процессы, в которых ошибки приводят к потерям, затем запустить минимальный рабочий контур и собрать реальные данные. На их основе можно дорабатывать архитектуру, подключать интеграции и автоматизировать устойчивые процессы. AI стоит добавлять там, где уже подготовлены данные и понятны правила работы.
CRM-проект имеет смысл оценивать не по тому, насколько законченной выглядит система в день запуска, а по тому, насколько спокойно бизнес способен ее менять после него. Для этого до старта нужно согласовать критичные процессы и интеграции, критерии результата и ответственность за дальнейшие изменения.
Теги:
