Краткий ответ
Кастомная CRM нужна не всем. Она окупается, когда у бизнеса есть нестандартная воронка, несколько ролей с разными правами, собственные сущности данных и дорогие ручные передачи между отделами. Если процесс стандартный и интеграций мало, готовая CRM обычно выгоднее. Ниже — жёсткий чек-лист, по которому можно понять, где нужен заказной контур, а где лучше не переплачивать.
Если продажи живут в одном окне, а выполнение заказа начинается в другом, CRM перестаёт быть «программой для отдела продаж» и становится частью операционной модели. На этом стыке чаще всего и возникает хаос: менеджер уже поменял статус сделки, а руководитель исполнения узнаёт о ней только через день, когда клиенту уже обещан срок и зафиксированы ожидания.
Проблема в таких проектах редко в дисциплине. Обычно она в том, что готовая система не совпала с тем, как бизнес реально работает: сделки идут по разным маршрутам, доступы у ролей не совпадают, а данные приходится собирать вручную из нескольких мест. В этом случае разработка CRM на заказ решает не только задачу продаж, но и задачу управляемого обмена между отделами.
Есть и обратная сторона. Если компания пока живёт на одной простой воронке, без сложных согласований и без внешних интеграций, заказная разработка будет лишней тратой времени и денег. Поэтому главный вопрос не в том, «нужна ли CRM вообще», а в том, когда типовой продукт уже не выдерживает вашу логику.
Когда готовой CRM уже недостаточно
Порог обычно виден не по размеру команды, а по количеству исключений. Пока у вас один маршрут сделки, один набор статусов и одна логика доступа, типовая CRM может работать без боли. Как только появляются разные типы клиентов, отдельные ветки согласования, специфические поля и ручные обходы, система начинает жить поверх процесса, а не внутри него.
Самый честный сигнал, сотрудники перестают доверять данным и держат параллельный учёт в таблицах, чатах или заметках. Тогда CRM уже не снижает хаос, а дублирует его. В этот момент кастом нужен не ради «уникальности», а чтобы убрать разрыв между процессом и системой.
Ещё один красный флаг, права доступа. Если менеджер, руководитель, финансист и партнёр должны видеть разный набор полей, разную логику переходов и разные действия в карточке, готовая CRM быстро превращается в компромисс. Чем больше компромиссов, тем выше цена ошибки: лишние правки, путаница в статусах, задержки согласований.
Когда в проекте участвуют несколько отделов, одно и то же событие читается по-разному. Продажи считают, что сделка закрыта, исполнение ждёт старт работ, а бухгалтерия смотрит только на счёт и оплату. Если эти слои не сведены в один контур, каждый отдел живёт в своей версии правды, а команда тратит часы на сверку и выяснение, где потерялась информация.
Именно здесь сильнее всего проявляется ценность кастомной CRM: она не просто хранит клиентов, а связывает продажи, исполнение и финансы так, чтобы не было ручных «мостиков» между системами. Для бизнеса, который хочет видеть целую цепочку, а не отдельные карточки, это уже не удобство, а управляемость.
Чек-лист для отбора вендора
- У нас одна воронка или несколько разных маршрутов сделки?
- Есть ли поля, которые нельзя нормально уместить в стандартную карточку клиента?
- Сколько ролей реально работает в системе каждый день?
- Нужны ли разные права доступа для менеджера, руководителя, партнёра и финансов?
- Есть ли согласование, без которого сделка не должна двигаться дальше?
- Какие системы уже должны обмениваться данными с CRM: 1С, ERP, телефония, биллинг, портал, склад?
- Нужно ли синхронизировать не только карточки, но и статусы, события и документы?
- Сколько ручных действий происходит после каждой сделки?
- Можно ли измерить, сколько времени уходит на поиск данных и сверку статусов?
- Есть ли у нас владелец процесса, который будет принимать решения, а не просто собирать пожелания?
- Что важнее в первый релиз: скорость запуска или полный охват функций?
- Какие изменения мы ждём через год: рост команды, новые каналы, новая линейка продуктов?
- Сможем ли мы сами поддерживать систему после запуска или будем зависеть от подрядчика?
- Что будет считаться провалом проекта через 90 дней?
Этот список нужен не для галочки, а как фильтр от лишнего кастома. Если на половину вопросов ответ «нет», готовая CRM ещё может справиться. Если же ответы «да» идут один за другим, вы уже выбираете не интерфейс, а модель работы компании.
Сильный подрядчик обычно не обещает «любые интеграции» и «любой функционал». Сначала он уточняет, где именно ломается процесс, какие данные теряются и какой участок дороже всего чинить вручную. По этой логике легко отличить команду, которая проектирует систему, от команды, которая продаёт набор общих обещаний.
Нестандартная воронка и несколько маршрутов сделки
Если одна и та же заявка может пойти в три разных сценария, стандартная схема начинает вредить. Типичный пример, проектные продажи: сначала квалификация, потом техническое согласование, затем коммерческий этап. В готовом продукте такие цепочки часто запихивают в один длинный список статусов, и отчёты начинают врать.
Кастомная CRM позволяет развести маршруты по типам сделок, а не заставлять всех идти по одному коридору. Это убирает ложные статусы и сокращает ручные пометки в Excel. На практике такой разрыв нередко экономит менеджерам и руководителям продаж часы в неделю, потому что исчезает постоянная сверка «что у нас на самом деле происходит».
Роли, права доступа и многоуровневое согласование
Как только в системе появляется партнёрский доступ, финансовое согласование или ограничения по подразделениям, вопрос уже не в удобстве. Вопрос в том, кто что видит, кто что меняет и где система должна остановить сделку до подтверждения. Для типовой CRM это частая зона компромисса.
Хорошая заказная разработка строит доступ не только по роли, но и по состоянию сделки, типу клиента и зоне ответственности. Это особенно важно там, где ошибка в доступе может создать не просто путаницу, а юридический или финансовый риск. Одно неверное изменение статуса иногда запускает лишний круг согласований и задерживает закрытие сделки на несколько дней.
Собственные сущности данных и связка объектов
Когда в системе появляются не только клиенты и сделки, а ещё объекты, договоры, выезды, услуги, рекламации и счета, готовая CRM начинает напоминать набор костылей. Связь между сущностями приходится собирать вручную, и в итоге менеджер видит одно, бухгалтерия, другое, а руководитель — третье.
Заказная разработка нужна там, где важна не отдельная карточка, а связь между карточками. Сделка может быть привязана к нескольким объектам, каждый объект. К собственному договору, а каждый договор — к своей цепочке документов. Когда эти связи спроектированы нормально, команда перестаёт искать информацию по разным окнам и получает целую картину процесса.
API-контур: 1С, ERP, телефония, биллинг, портал
Интеграция сама по себе не решает задачу. Решает глубина связки. Если CRM только отправляет лиды в другую систему, а потом статус всё равно меняют руками, компания живёт с двойным вводом данных. Это и есть скрытая цена плохого выбора: снаружи автоматизация есть, а внутри процесс всё ещё ручной.
В сложном проекте важно заранее описать, какие события должны ходить между системами, кто создаёт эти события и где находится источник истины. Для одной компании это номер счёта, для другой. Статус заявки, для третьей, факт выезда специалиста. Без такой схемы даже сильная команда сделает красивую оболочку, но не рабочий контур.
Когда готовая CRM всё ещё достаточна
Если у вас короткий цикл сделки, один отдел продаж и почти нет внешних связок, заказная разработка часто не нужна. В таких условиях готовая CRM быстрее даст результат и обойдётся дешевле на старте. Особенно это верно, если процесс ещё меняется и вы пока не можете стабильно описать его в правилах.
Здесь разумнее не строить систему с нуля, а сначала добиться дисциплины использования обычного продукта. Иначе компания платит за кастом не потому, что он нужен, а потому, что внутри нет ясности по процессу. Это плохая причина для проекта.
Когда кастом не нужен совсем
Если бизнес работает с узким кругом постоянных клиентов и почти не растёт, CRM как отдельный проект может не окупиться. Та же история, когда задача сводится к хранению контактов и нескольким заметкам. В такой ситуации больше пользы даст настройка простого решения, чем полноценная разработка CRM на заказ.
Ещё один стоп-сигнал, отсутствие владельца процесса. Если никто не готов принять решение по статусам, правам и обязательным данным, проект быстро расползается. Без этого заказная разработка превращается в долгую переделку чужих догадок.
Для команд, которым важен именно пользовательский контур с большим числом связанных сущностей, близкая тема — разработка личного кабинета для сайта. Логика там похожа: система ценна не внешним видом, а тем, как она удерживает данные, права и сценарии действий.
Если задача касается кадровых процессов и нескольких согласований, полезно посмотреть и на автоматизацию hr процессов. Там хорошо видно, как меняется цена ручного труда, когда один и тот же путь должен пройти через несколько ролей и проверок.
Что входит в первый релиз
Минимальный разумный MVP, это не урезанная версия «всего и сразу». Это рабочий контур, который закрывает самый дорогой разрыв в процессе. Обычно в него входят карточка клиента, основные статусы, маршрутизация по ролям, обязательные поля, базовые отчёты и одна-две критичные интеграции.
Если первый релиз не даёт команде работать без Excel-надстроек, он слишком слабый. Но если в MVP пытаются уместить все редкие сценарии сразу, проект становится дорогим и медленным. Здоровый баланс — закрыть 60–70% частоты использования и оставить редкие исключения на вторую очередь.
Что лучше отложить в post-MVP
Редкие ветки согласования, экзотические отчёты, расширенную аналитику и «красивый» интерфейс для всех ролей почти всегда можно перенести на вторую фазу. Сначала нужно проверить, что основная воронка реально работает. Только после этого имеет смысл расширять систему вокруг точек, где команда каждый день теряет время.
Такой подход снижает риск переделок. Команда не строит монолит, который потом больно разбирать. Она собирает первый рабочий контур, на котором уже видна ценность.
Какие данные собрать до старта
До разговора с подрядчиком лучше принести не презентацию, а рабочие артефакты. Нужны список ролей, перечень статусов, описание переходов, примеры реальных карточек и список систем, с которыми CRM должна обмениваться данными. Этого достаточно, чтобы не обсуждать абстракции.
| Поле | Тип | Кто владелец | Обязательно | Где используется |
|---|---|---|---|---|
| Deal_stage | Список | Отдел продаж | Да | Прогноз продаж, отчёты |
| Client_type | Список | Коммерческий директор | Да | Маршрутизация по сценариям |
| Contract_id | Текст | Финансы | Да | Счета, акты, сверка |
| Site_visit_date | Дата | Сервисная команда | Нет | Выезды, SLA, планирование |
| Integration_status | Список | ИТ | Да | Обмен с 1С и ERP |
| Approval_level | Число | Руководитель направления | Да | Согласование сделок |
Такой шаблон помогает быстро увидеть, где у процесса настоящая сложность, а где её придумали. Если список полей и владельцев не получается собрать за один-два прохода, значит, проект ещё не готов к оценке.
Сравнение: готовая CRM, кастомная CRM и вариант подождать
| Подход | Когда подходит | Когда ломается | Сигнал по бюджету |
|---|---|---|---|
| Готовая CRM | Одна воронка, мало интеграций, понятные роли | Появляются сложные статусы и разные права доступа | Низкий вход, но растут затраты на обходы |
| Кастомная CRM | Несколько сценариев, свои сущности, глубокие связки | Нет владельца процесса и процесс ещё меняется | Выше старт, ниже цена изменений потом |
| Пока не заказывать | Процесс не описан, мало пользователей, нет явной боли | Команда начинает строить систему до того, как поняла задачу | Самый дешёвый вариант сегодня |
Если смотреть без иллюзий, готовая CRM выигрывает там, где процесс уже стандартный и почти не меняется. Кастом выигрывает там, где каждый месяц появляются новые правила, новые роли и новые точки интеграции. А третий вариант, это пауза, которая экономит деньги, если компания ещё не готова формулировать задачу.
Важно сравнивать не цену входа, а цену жизни решения. Иногда внешне дешёвая система за год съедает больше бюджета на костыли, чем полноценная разработка CRM на заказ. Именно поэтому считать надо не лицензию, а стоимость переделок, ручных обходов и потерянного времени.
Для команд, которые хотят смотреть на автоматизацию через рост продаж, а не только через ИТ, полезен и материал как увеличить продажи в интернет магазине. Он помогает отделить автоматизацию ради отчётности от автоматизации ради реального движения денег.
Таблица выбора по сценарию
| Сценарий | Что брать первым | Почему |
|---|---|---|
| Сложные роли и согласования | Кастомная CRM | Нужно управлять доступом и логикой переходов |
| Стандартные продажи | Готовая CRM | Нет смысла строить систему с нуля |
| Нет описанного процесса | Пауза и аналитика | Сначала нужен порядок работы, потом автоматизация |
| Нужны внешние связки и свои сущности | Кастомная CRM | Типовой продукт быстро упирается в потолок |
От чего зависят стоимость и сроки
Бюджет проекта чаще всего растёт не от количества кнопок, а от числа связей. Одна система с тремя ролями и одной интеграцией — это один уровень сложности. Система с пятью ролями, согласованиями, миграцией данных и двумя внешними API, уже другой. Разница в сроках легко доходит до двукратной, даже если интерфейс на экране выглядит почти одинаково.
На цену сильнее всего влияют пять вещей: объём данных, число интеграций, сложность бизнес-логики, требования к интерфейсу и глубина тестирования. Миграция старых данных и перенос истории часто оказываются дороже, чем ожидают на старте. Если это не учесть, проект начинает буксовать уже на валидации.
По срокам важна не только разработка, но и скорость решений со стороны бизнеса. Когда владелец процесса отвечает быстро, MVP можно собрать раньше. Когда каждую неделю меняются правила, календарь проекта расползается, а команда тонет в переделках.
Цена ошибки здесь прямая. Если готовая CRM не покрывает логику, компания платит дважды: сначала за внедрение, потом за обходные процессы, ручную сверку и доработки. В реальности это почти всегда незаметные, но постоянные потери времени и денег.
Какие риски у кастомной разработки
Главный риск, зависимость от подрядчика. Если система спроектирована без нормальной документации, а знание живёт в одной команде, любое изменение становится дорогим. Вы покупаете не только продукт, но и способность его поддерживать.
Второй риск, расползание объёма работ. Сегодня нужен один сценарий, завтра ещё три исключения, послезавтра отдельный отчёт для руководства. Если границы MVP не зафиксированы, проект растёт быстрее, чем польза. Это особенно опасно там, где бизнес ещё сам до конца не описал свои правила.
Третий риск, попытка повторить готовый продукт с нуля без реальной уникальной логики. Тогда компания тратит деньги на копию коробки, вместо того чтобы решать своё узкое место. Такой проект почти всегда проигрывает по срокам и по стоимости владения.
Наконец, после запуска система не заканчивается. Она начинает жить: меняются команды, каналы, интеграции, отчётность. Если это не учесть заранее, через полгода любая правка будет восприниматься как новый проект.
Как подготовиться к обсуждению проекта с подрядчиком
На встречу лучше приходить не с формулировкой «сделайте удобно», а с фактами. Нужны список ролей, схема текущего процесса, примеры проблемных кейсов и перечень систем, с которыми должен быть обмен данными. Это резко сокращает время на разговоры о пустом.
Полезно отдельно выписать, где именно компания теряет деньги сегодня. Это может быть ручная сверка, задержка согласований, дублирование карточек или потерянные заявки. Без такой диагностики подрядчик будет предлагать абстрактные улучшения вместо точечного решения.
Ещё один шаг — зафиксировать границу MVP. Что входит в первый релиз, что идёт позже и по какому признаку вы поймёте, что первая версия уже полезна. Если границу не поставить, обсуждение легко превращается в бесконечный список хотелок.
Как Animar Media подходит к CRM-проектам
Когда компании нужна не просто карточка клиента, а рабочий цифровой контур с ролями, интеграциями и понятной логикой развития, Animar Media подходит как формат полной разработки под бизнес-задачу. Такой подход полезен там, где проект нужно собрать от анализа и прототипа до тестирования и запуска, а не пытаться натянуть готовую коробку на чужой процесс.
Это особенно важно в сценариях, где CRM должна жить не только в офисе, но и на любом устройстве, обмениваться данными с внешними сервисами и держать единый порядок работы для разных ролей. В таких проектах ценность создаёт не «ещё одна система», а нормальная связка между данными, интерфейсом и автоматизацией. Именно это быстрее убирает ручные обходы и снижает цену ошибок.
Обычно лучше всего работают проекты, где уже есть понятный владелец процесса, видны основные интеграции и можно собрать первый релиз без лишней архитектурной тяжести. Если у компании пока только черновой процесс, разумнее сначала описать его и проверить границы MVP. Иначе кастом превращается в долгую переделку ещё не устоявшейся модели работы.
Если задача уже понятна и вы хотите перейти от оценки к обсуждению реализации, удобная точка входа, Animar Media. Так проще обсудить структуру данных, роли, интеграции и ограничения до того, как решение начнёт стоить дороже времени.
Animar Media: если CRM должна работать как часть операционной модели
Когда CRM нужна не ради отчёта, а ради того, чтобы продажи, исполнение и финансы не жили в разных системах, решает не внешний вид, а полный цикл разработки. В Animar Media можно собрать аналитику, проектирование, дизайн, разработку, тестирование и запуск в одном контуре, не разбивая проект на отдельные куски и не теряя логику по дороге.
Для таких проектов критичны четыре вещи: доступ с любого устройства, автоматизация ручных шагов, связка с API и внешними сервисами, а также настройка под реальные правила компании. Это не абстрактные плюсы, а критерии, которые обычно и отличают рабочую систему от красивой оболочки. Если процесс уже сложный, а данные живут в нескольких местах, именно эти свойства быстрее всего дают эффект.
Чаще всего такой формат выбирают команды, у которых есть понятный владелец процесса, несколько ролей и желание убрать переделки между отделами. Им не нужна ещё одна коробка со скидкой на лицензии, им нужна система, которую можно встроить в свою модель работы и потом развивать без постоянной переделки основы.
Если задача уже понятна и вы готовы обсуждать реализацию, начните с Animar Media как с точки входа в проект: так проще проверить структуру, объём и ограничения до старта разработки.
По fit-сигналу продукта: Подходит компаниям, которым нужен сайт или веб-приложение как рабочий бизнес-инструмент: для привлечения заявок, автоматизации процессов, интеграции с внешними сервисами и дальнейшего масштабирования. Особенно уместно для проектов на стадии запуска или редизайна, когда важно пройти полный цикл — от аналитики и UX/UI до разработки, тестирования, запуска и.
Хотите собрать такую платформу под себя?
Если это похоже на вашу задачу, следующим шагом посмотрите страницу продукта. Там видно, как собрать платформу и какие части запуска закрывает платформа.
Часто задаваемые вопросы
Как понять, что готовой CRM ещё достаточно?
Если у вас одна воронка, мало интеграций и нет сложных прав доступа, готовой CRM обычно хватает. Если процесс ещё меняется каждую неделю, кастом почти наверняка преждевременен.
Какие признаки говорят, что кастомная CRM уже нужна?
Главный сигнал, несколько маршрутов сделки, собственные сущности данных, разные роли и дорогие ручные переходы между отделами. Если этих признаков несколько сразу, типовая система быстро упирается в потолок.
Что будет, если начать разработку без владельца процесса?
Проект почти всегда расползается. Решения по статусам, полям и правам начинают принимать по ситуации, и система превращается в набор компромиссов.
В чём главная ошибка при заказной CRM?
Пытаться повторить готовую CRM с нуля без реальной уникальной логики. Тогда вы платите за копию коробки, а не за устранение своего узкого места.
Когда кастомная CRM не окупится?
Когда процесс не описан, пользователей мало и внешних связок почти нет. В такой ситуации сначала выгоднее навести порядок в работе и проверить, что именно нужно автоматизировать.
Что нужно собрать перед оценкой MVP?
Список ролей, основные статусы, обязательные поля, критичные интеграции и границу первой версии. Если MVP не убирает ручную сверку хотя бы в одном важном участке, его стоит пересобирать.
Аккаунт-менеджер Scrile. Пишет про B2B sales-циклы, коммуникацию вендор-клиент и непарадную середину enterprise-сделок.