CRM уже стоит, но не работает: что делать и с чего начать

Обычно всё начинается правильно. CRM выбрали, настроили, обучили команду, запустили. Первые недели — энтузиазм, новые возможности, ощущение контроля.

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

Самое неприятное — ощущение тихих потерь. Никто не кричит, ничего явно не ломается. Но сделки зависают, клиенты пропадают, и непонятно, сколько именно теряется и где. В этот момент часто возникает мысль: «Наверное, CRM плохая. Надо менять». На практике — почти никогда. И прежде, чем что-то менять, стоит понять, что именно сломалось.

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

Что проверить в первую очередь:

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

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

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

Менеджеры обходят систему. Клиенты ведутся в Telegram и MAX, звонки не фиксируются, CRM заполняется задним числом — для галочки. Это сигнал, что система существует параллельно с продажами, а не внутри них. Если менеджеры обходят CRM, это не всегда саботаж: часто система неудобна или не помогает в работе. Подробно разобрали, почему менеджеры обходят CRM, в отдельной статье.

Отчётам нельзя доверять. Графики строятся, но выводов из них не сделать: непонятно, где узкое место — в лидах, в менеджерах или в процессе.

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

Чтобы перейти от ощущения «что-то не так» к конкретным точкам проверки, удобно идти по таблице. Левая колонка — что вы видите. Средняя — что это может означать. Правая — что проверять.

На диагностике обычно выясняется не одна «поломка», а несколько точек потери управляемости одновременно:

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

Каждая из этих причин заслуживает отдельного разбора — что именно ломается и почему. Подробно это разобрано в статье «Почему amoCRM не приносит результата: 7 причин, из-за которых CRM не даёт управляемости продаж». Здесь же важно другое: причин обычно несколько, они переплетены, и чинить их вслепую по одной — значит плодить новые костыли. Поэтому начинать нужно не с ремонта, а с того, чтобы увидеть всю картину.

Первая реакция на неработающую систему — сменить её на другую. «amoCRM не подошла, попробуем что-то ещё». Это ловушка.

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

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

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

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

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

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

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

И только теперь — выбор сценария: чинить отдельные настройки, упрощать CRM, пересобирать воронку, обучать команду или менять систему. Последнее — только если причина техническая и текущая платформа действительно не подходит.

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

Что проверяем:

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

Что получает собственник на выходе:

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

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

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

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

Короткая развилка по результатам диагностики:

• Доработка — если основа жива: воронка в целом отражает процесс, нужно лишь добавить задачи, контроль и убрать лишнее.
• Пересборка — если воронка не соответствует процессу, задачи не используются, а CRM заполняют для галочки. Чинить по кусочкам тут дороже, чем собрать логику заново.
• Замена CRM — только если есть технические ограничения, а не потому, что «эта не понравилась».

Замена оправдана, если:

• текущая система технически не поддерживает нужные процессы;
• нет критичных интеграций и их невозможно реализовать;
• система устарела и не развивается;
• поддержка старой системы дороже разумного перехода;
• хаоса столько, что пересборка с нуля дешевле ремонта.

Если на этом этапе вы выбираете подрядчика, отдельно стоит разобраться, как выбрать интегратора amoCRM, чтобы не получить второе формальное внедрение.

iFabrique не начинает с «давайте всё перенастроим». Сначала нужно понять, где именно система перестала давать управляемость. Логика спокойная: сначала диагностика, потом список работ, потом исправление, потом обучение и сопровождение.

Что входит в диагностику:

1. Смотрим текущие воронки и этапы — насколько они отражают реальный процесс.
2. Проверяем, как заявки попадают в CRM и какие каналы остаются вне системы.
3. Смотрим сделки без задач и с просрочками.
4. Проверяем обязательные поля и причины отказа.
5. Сравниваем CRM с реальным процессом продаж и фиксируем расхождения.
6. Проверяем, какие данные видит руководитель и можно ли им доверять.
7. Смотрим, где менеджеры обходят систему и почему.
8. Формируем список исправлений и делим его: что срочно, что можно позже, а что вообще не нужно.

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

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

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

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

Да, если основа не разрушена. Часто достаточно убрать лишние поля, привести этапы к реальному процессу, настроить задачи, подключить каналы и закрепить правила работы. Полная пересборка нужна не всегда. Решение лучше принимать после диагностики.

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

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

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

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