Готовая CRM — логичный первый шаг: карточки, сделки, воронка, напоминания. Для короткого цикла «лид → звонок → договор» этого достаточно.
Дальше процесс обрастает полями, Excel, автоматизациями и инструкциями «если этап X и поле Y — сделай Z». Вопрос уже не в самой CRM, а в том, что ею пытаются заменить операционку.
Часы на лишние клики — в расчёте неудобный интерфейс CRM. Как CRM встроена в портал, а не стоит сбоку — в FAQ про работу менеджеров.
Содержание
Готовая CRM часто выглядит логичным первым шагом автоматизации продаж.
Компания получает:
Для небольшого отдела продаж этого обычно достаточно.
Проблемы начинаются позже, когда бизнес-процесс становится сложнее стандартной схемы:
лид → звонок → предложение → договор → продажа
Компания начинает добавлять обходные решения:
В какой-то момент возникает вопрос:
продолжать дорабатывать CRM или перенести часть процессов в собственную систему?
Разберём, почему компании вообще приходят к такому решению.
Большинство CRM построено вокруг продаж.
У сделки есть:
Но реальные B2B-процессы могут быть значительно сложнее.
Например, заказ кухни:
заявка ↓ замер ↓ проект ↓ согласование ↓ технолог ↓ закупка материалов ↓ производство ↓ доставка ↓ монтаж
На каждом этапе могут существовать:
Попытка представить всё это одной CRM-сделкой постепенно усложняет систему.
Сотрудникам приходится помнить:
«Если заказ находится на этапе X и поле Y заполнено, нужно сделать Z».
То есть реальный бизнес-процесс существует уже не в самой системе, а в инструкциях сотрудников.
Сначала компания добавляет несколько полей:
Потом появляются:
Через несколько лет карточка сделки может содержать десятки или даже сотни дополнительных полей.
Пользователю становится трудно понять:
CRM технически продолжает работать.
Но интерфейс становится неудобным.
CRM предназначена прежде всего для работы с клиентами и продажами.
Но компании постепенно начинают добавлять туда:
Например, менеджер хочет видеть остаток товара.
В CRM создаётся поле:
Остаток
Потом появляется несколько складов:
Остаток Минск
Остаток Москва
Остаток склад 3
Затем появляется резерв.
Потом ожидаемое поступление.
В результате CRM начинает частично дублировать ERP или складскую систему.
Возникает главный вопрос:
Где находится настоящий остаток?
Если ответ зависит от того, кто смотрит данные и в какой системе, архитектура уже становится проблемной.
Очень частая причина недовольства CRM — повторный ввод данных.
Например:
Получается:
сайт ↓ CRM ↓ 1С ↓ доставка ↓ Excel
Если между системами нет нормальной интеграции, CRM становится ещё одной точкой ручного ввода.
Проблема здесь не обязательно в самой CRM.
Проблема в архитектуре.
Но именно пользователи воспринимают это как:
«CRM мешает работать».
Современные CRM позволяют настроить огромное количество автоматизаций.
Это удобно.
Но постепенно может возникнуть конструкция:
если стадия = X и поле A заполнено и сумма > Y и клиент относится к категории Z тогда создать задачу и изменить поле B и отправить webhook.
Когда таких правил становится несколько сотен, систему сложно поддерживать.
Новый сотрудник не понимает, почему произошло действие.
Администратор боится менять автоматизацию, потому что она может повлиять на другой процесс.
Возникает технический долг.
Формально CRM работает без программирования.
Фактически компания уже построила внутри неё собственное приложение.
Готовая CRM рассчитана на универсальный сценарий.
Поэтому интерфейс должен подходить:
Но универсальный интерфейс не всегда удобен для конкретной задачи.
Например, менеджеру по автозапчастям может требоваться один экран:
VIN → автомобиль → запрос клиента → найденные детали → аналоги → остатки → цены поставщиков → маржа
В CRM эта информация может быть разбросана по:
Собственная система может показать всё на одном экране.
Иногда именно интерфейс, а не отсутствие функций становится причиной отказа от готового продукта.
Это особенно заметно в повторяющихся процессах.
Например, менеджер должен создать заказ.
В универсальной CRM ему приходится:
Если операция выполняется два раза в день — проблема небольшая.
Если 200 раз — количество кликов становится существенным.
Тогда компания начинает создавать собственный интерфейс:
клиент + товары + условия → Создать заказ
Один экран заменяет несколько стандартных форм CRM.
Это один из наиболее важных сигналов.
Компания внедрила CRM.
Но рядом продолжают существовать:
заказы.xlsx;остатки.xlsx;план производства.xlsx;график монтажей.xlsx;скидки.xlsx.Почему?
Обычно потому, что некоторые процессы в Excel выполнять проще.
Например:
Если CRM внедрена несколько лет назад, а критические процессы всё ещё ведутся в Excel, возможно, система покрывает только часть реальной работы.
Сначала подключается сайт.
Потом:
Схема начинает выглядеть так:
сайт
|
телефония — CRM — 1С
|
доставка
|
документы
|
BI
На этом этапе CRM превращается в центральный узел всей инфраструктуры.
Это может быть удобно.
Но появляется зависимость:
любое ограничение CRM влияет на половину компании.
Тогда бизнес иногда решает вынести интеграции в отдельный слой.
CRM остаётся инструментом отдела продаж, а управление данными происходит отдельно.
Иногда бизнесу нужны специфические интеграции.
Например:
API готового SaaS может иметь:
Для обычного использования это не проблема.
Но при высокой нагрузке ограничения начинают влиять на архитектуру.
Многие CRM используют модель:
цена × пользователь × месяц
Для маленькой команды это удобно.
Например:
10 сотрудников × 30 $ = 300 $ в месяц.
Но если пользователей становится 200:
200 × 30 $ = 6000 $ в месяц.
Или:
72 000 $ в год.
К этому могут добавляться:
На этом масштабе компания начинает сравнивать стоимость SaaS с собственной разработкой.
Но здесь важно считать полную стоимость.
У собственной системы тоже есть:
Поэтому высокая стоимость SaaS сама по себе ещё не означает, что собственная CRM будет дешевле.
Универсальная CRM содержит множество возможностей.
Например:
Но конкретной компании может быть нужно всего несколько вещей.
Например:
При этом пользователи постоянно видят десятки ненужных разделов.
Это повышает сложность интерфейса.
Собственная система может содержать только те функции, которые нужны конкретной роли.
В CRM могут одновременно работать:
Но каждому требуется разная информация.
Менеджеру:
клиент заказ цена срок
Складу:
артикул количество ячейка резерв
Технологу:
спецификация параметры чертёж версия
Руководителю:
маржа срок просрочки статус
Попытка разместить всё это в одной карточке создаёт перегруженный интерфейс.
Поэтому компании иногда разделяют систему на отдельные рабочие места.
Стандартной модели:
администратор / менеджер / пользователь
может быть недостаточно.
Например:
дилер видит только:
Региональный менеджер видит:
Руководитель видит:
Поставщик видит:
Подрядчик получает доступ:
При большом количестве таких правил управление доступом в готовой CRM может стать сложным.
CRM обычно предназначена для сотрудников компании.
Но B2B-бизнесу может понадобиться интерфейс для клиента.
Например, клиент должен:
Можно попытаться реализовать это средствами CRM.
Но часто удобнее оставить CRM внутри компании, а для клиентов создать отдельный B2B-портал.
Получается:
клиент ↓ B2B-портал ↓ интеграция ↓ CRM
В таком случае компания не обязательно отказывается от CRM полностью.
Она просто перестаёт использовать её как интерфейс для всех процессов.
Продажа услуги и продажа 500 товарных позиций — разные задачи.
В B2B может быть заказ:
237 позиций
Для каждой позиции:
CRM, ориентированная на сделки, может работать с такой структурой неудобно.
Тогда появляется отдельная система заказов.
CRM хранит:
кто клиент и на каком этапе продажа.
А система заказов:
что именно покупается и как заказ выполняется.
Например, цена зависит от:
Если расчёт содержит десятки правил, реализовать его в универсальной CRM бывает трудно.
Часть компаний в результате создаёт отдельный калькулятор.
Например:
CRM ↓ собственный расчётный модуль ↓ готовая цена ↓ CRM
Такой подход позволяет сохранить готовую CRM и не пытаться встроить в неё всю бизнес-логику.
CRM хорошо хранит историю изменений полей.
Но иногда нужен полноценный контроль версий объекта.
Например:
Заказ v1
100 позиций.
Заказ v2
изменено 12 позиций.
Заказ v3
изменён материал.
Необходимо:
Для стандартной CRM это уже довольно специфическая задача.
При использовании SaaS данные находятся в инфраструктуре поставщика.
Для большинства компаний это нормально.
Но иногда существуют дополнительные требования:
В таком случае собственная система или self-hosted решение может быть предпочтительнее.
SaaS может изменить:
Пользователь не контролирует дорожную карту продукта.
Для стандартной CRM это приемлемо.
Но если вся операционная деятельность компании построена вокруг конкретных особенностей продукта, зависимость становится рискованной.
Нет.
Во многих случаях собственная CRM вообще не нужна.
Если процесс компании выглядит так:
лид ↓ контакт ↓ предложение ↓ сделка
готовая CRM, скорее всего, справится отлично.
Также готовая CRM обычно выигрывает по:
Проблема начинается не тогда, когда компания использует готовую CRM.
А когда бизнес вынужден перестраивать реальные процессы под ограничения инструмента.
Это важное различие.
На практике часто оптимальной оказывается схема:
CRM → клиенты и продажи ERP → товары, финансы и учёт WMS → склад B2B-портал → клиентские заказы собственный модуль → специфический процесс
Например, компания оставляет Bitrix24 для отдела продаж.
Но отдельно создаёт:
То есть CRM остаётся.
Просто перестаёт выполнять функции, для которых она изначально не предназначалась.
Можно провести небольшой тест.
Если регулярно встречаются следующие ситуации, архитектуру стоит проанализировать.
Особенно если Excel содержит критически важные данные.
Например:
сайт → CRM → 1С
и на каждом этапе вручную.
Это признак накопленного технического долга.
Особенно если операция повторяется сотни раз.
Например:
«После стадии 4 откройте таблицу X и сделайте Y».
Создаются:
«В CRM это сделать нельзя, поэтому делаем вручную».
Если такие ситуации постоянны, возможно, проблема уже системная.
Даже при наличии ограничений не обязательно писать CRM с нуля.
Есть промежуточные варианты.
Иногда проблема находится не в программе, а в слишком сложном бизнес-процессе.
Можно убрать ручной перенос данных.
Например, оставить CRM, но разработать калькулятор.
CRM остаётся внутри компании, а клиент получает удобный интерфейс.
Собственный интерфейс работает поверх готовой CRM.
Иногда готовая система другого класса решает проблему без собственной разработки.
Полезно сравнить три сценария:
Посчитать:
Посчитать:
Посчитать:
И сравнивать нужно не только стоимость создания.
Лучше смотреть горизонт хотя бы нескольких лет.
Предположим, менеджер тратит 15 минут на ручной перенос одного заказа.
В день:
20 заказов × 15 минут = 300 минут
То есть:
5 часов
За 22 рабочих дня:
110 часов
Это уже почти три рабочие недели одного сотрудника в месяц.
Если такую операцию можно убрать интеграцией, иногда нет необходимости заменять CRM целиком.
Достаточно исправить конкретный узкий участок.
Компания обнаруживает проблемы и делает вывод:
Нужно создать CRM с нуля.
Это очень крупный проект.
Придётся реализовать:
Большая часть этих функций уже хорошо реализована готовыми продуктами.
Поэтому рациональнее сначала найти конкретный процесс, который не работает.
Например:
менеджеры вручную рассчитывают заказ.
Тогда первым проектом может стать не новая CRM, а:
система расчёта заказов.
Компании редко отказываются от готовой CRM просто потому, что хотят собственное программное обеспечение.
Обычно это результат накопившихся ограничений.
Основные причины:
Но это не означает, что компанию обязательно нужно переводить на полностью собственную CRM.
Часто более рациональная архитектура выглядит так:
готовая CRM + готовая ERP + собственные специализированные модули + интеграционный слой
В таком случае готовые системы решают стандартные задачи, а собственная разработка используется только там, где процесс действительно отличается от типового.
Поэтому вопрос стоит формулировать не так:
«Нужно ли отказаться от CRM?»
А так:
«Какие процессы CRM выполняет хорошо, а какие мы уже пытаемся реализовать в ней вопреки её устройству?»
Ответ на этот вопрос обычно показывает, нужно ли менять CRM, дорабатывать интеграции или выносить отдельные процессы в собственную систему.
Нет. Они хорошо закрывают стандартную воронку продаж. Ломаются на процессе, который не является сделкой: замер, версии проекта, производство, совместимость комплекта, кабинет клиента.
Это частая ошибка. Сначала считают ручные обходы, пробуют интеграцию, отдельный модуль или B2B-портал рядом с текущей CRM. Полная замена — когда процесс уже не помещается и обходы стали системой.
Если менеджер знает, что делать, но тратит время на лишние клики и повторный ввод — это модельные часы неудобной CRM. Если логика живёт в инструкциях «если поле Y, сделай Z» — процесс шире карточки сделки.
Типовые вопросы про задачи, права и очередь — в FAQ про CRM и работу менеджеров. Сложный цикл вне воронки — в кейсе кухонь на заказ.
Нужен похожий контур — обсудим. услуги веб-разработки на Laravel.
сколько стоит неудобный интерфейс CRM · SaaS или собственная разработка · FAQ: CRM и работа менеджеров · за какую автоматизацию платят