Когда бизнесу достаточно готовой CRM, а когда нужна собственная система

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

Коробочная CRM — нормальная отправная точка

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

У коробки уже есть мобильное приложение, права, уведомления, отчёты и десятки мелких функций, которые в собственном продукте тоже придётся когда-то делать. Переписывать всё это только ради ощущения «своей системы» бессмысленно.

Интерес к разработке начинается там, где CRM перестаёт быть инструментом процесса и сама становится ограничением.

Главный сигнал — процесс начинает жить рядом с CRM

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

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

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

Своя CRM начинается со своей модели данных

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

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

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

Роли и состояния важнее количества экранов

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

Поэтому роли в кастомной CRM — это не только «можно открыть страницу / нельзя открыть страницу». Часто нужно ограничивать сами объекты, допустимые переходы статусов и массовые операции.

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

Финансовые процессы быстро показывают пределы универсальной CRM

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

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

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

Интеграции лучше считать частью продукта, а не довеском

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

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

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

CRM и HRM лучше не смешивать только потому, что в обеих есть люди

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

Если основной объект системы — клиент, заказ, задание или операционная заявка, я бы оставался в логике CRM. Если процесс строится вокруг сотрудника от подбора до работы и развития, уже имеет смысл смотреть в сторону HRM.

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

Как понять, что обходы готовой CRM уже стали отдельной системой

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

Я бы оценивал не только стоимость лицензий и разработки. Важнее повторяемые операционные затраты: сколько раз один факт вводится заново, сколько сотрудников участвуют в сверке, какие ошибки нельзя восстановить по истории и сколько изменений требуют одновременно править CRM, таблицу и интеграцию.

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

Сколько постоянных таблиц и реестров существует рядом с CRM.
Какие статусы или сущности невозможно представить без пользовательских обходов.
Сколько ручных переносов данных происходит в одном сквозном сценарии.
Можно ли восстановить причину финансовой или статусной ошибки по истории системы.
Меняется ли один бизнес-факт одновременно в нескольких местах.

Как начинать свою CRM, чтобы не строить её год до первого пользователя

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

Я бы выбирал один сквозной сценарий, где сегодня больше всего ручной склейки. Например: заказ → задания → фактические часы → начисление → заявка на оплату. Если этот путь уже работает в новой системе, команда получает пользу, а архитектура проверяется реальными данными.

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

Вопросы

Когда лучше выбрать готовую CRM?

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

Какие признаки говорят, что нужна CRM на заказ?

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

Можно ли сначала доработать готовую CRM?

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

Чем CRM отличается от HRM?

CRM обычно строится вокруг клиентского или операционного процесса. HRM — вокруг кандидата и сотрудника: найма, оформления, обучения, KPI, документов и других HR-событий.

С чего начинать разработку собственной CRM?

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