Отдел продаж ведёт скидки в одной таблице, бухгалтерия сверяет оплаты в другой, а заявки с сайта падают на почту менеджера, который может быть в отпуске. Три версии правды об одном клиенте: такую мешанину готовая CRM с коробки не решает, если бизнес-процесс у компании нетиповой. В таких случаях выручает создание CRM системы под конкретные процессы, а не подгонка чужого шаблона под них. Пока каждый отдел видит свою версию правды, решения принимаются медленнее, а ответственность за ошибку в итоге не несёт никто.
Коробочные платформы вроде amoCRM или Битрикс24 закрывают стандартные сценарии: воронку продаж, звонки, карточки сделок. Но как только в процессе появляются уникальные сущности (партии товара, объекты строительства, график монтажа), сложные цепочки согласований или интеграция с внутренней ERP, система начинает требовать настроек поверх настроек и внешних сервисов поверх настроек. На этом этапе встаёт вопрос: продолжать дорабатывать коробку или заказать разработку под конкретные процессы. Каждая новая надстройка решает одну проблему и создаёт две новые: систему становится сложнее поддерживать, а скорость работы менеджеров падает.
Кастомная CRM стоит дороже готового тарифа и собирается дольше, чем активируется лицензия. Разберём, когда это оправдано, из чего складывается смета и какие этапы формируют срок проекта.
Когда бизнесу нужна разработка CRM под себя, а не готовое решение
Нетиповой бизнес-процесс не всегда виден сразу: часто компания год работает в коробочной системе, прежде чем понимает, что упирается в её ограничения. Вот признаки, по которым стоит присмотреться к кастомной разработке:
- В процессе участвуют нетиповые сущности: не просто «сделка», а объект недвижимости, вагон, партия сырья или производственный заказ со своим жизненным циклом.
- Один документ или сделку согласуют несколько отделов с разными правами доступа и ролями, а коробочная логика прав это не поддерживает без надстроек.
- Нужна глубокая интеграция с внутренними системами: 1С, собственный биллинг, производственный учёт, а не просто вебхук на внешний сервис.
- Объём данных и число пользователей растут так, что лицензия на коробочное решение дорожает быстрее, чем окупается её функциональность.
- Компании важно владеть кодом и архитектурой, а не зависеть от смены тарифов и политики вендора готовой платформы.
Эти признаки редко проявляются все одновременно: обычно компания замечает один или два симптома, а остальные вылезают по ходу роста бизнеса. Руководителю стоит оценивать не один симптом, а их сочетание. Одна нетиповая сущность в процессе ещё не повод для кастомной разработки, если остальная часть процесса укладывается в стандартную воронку. А вот сочетание нескольких признаков из списка выше обычно означает, что доработка коробочного решения обойдётся дороже, чем разработка с нуля.
Если ни один пункт не про вашу компанию, дешевле и быстрее выбрать готовую платформу: критерии такого сравнения подробно разобраны в статье о выборе CRM системы. А базовое понимание того, какие функции и виды систем вообще существуют, даёт материал CRM система для бизнеса: что это и какие виды бывают.
Из чего складывается смета на создание CRM системы
У кастомной разработки нет прайс-листа с тарифами, как у коробочного решения. Смета строится по часам и зависит от объёма и сложности каждого блока работ.
| Статья сметы | Что входит | Как влияет на бюджет |
|---|---|---|
| Анализ процессов | Интервью с отделами, карта процесса, список сущностей и ролей | Чем сложнее организационная структура, тем длиннее этап и точнее итоговая оценка |
| Проектирование | Архитектура данных, схема API, прототип интерфейса | Ошибка здесь обходится дороже всего: переделка архитектуры после старта разработки |
| Backend и frontend | Бизнес-логика, права доступа, интерфейсы под разные роли | Основная часть бюджета: число экранов и сценариев напрямую определяет часы |
| Интеграции | Телефония, мессенджеры, 1С, маркетплейсы, платежи | Каждая внешняя система: отдельный модуль со своей документацией и ограничениями API |
| Инфраструктура | Сервер, резервное копирование, мониторинг, требования к локализации данных | Для персональных данных граждан РФ обязательно размещение базы на сервере в России |
| Тестирование и запуск | Проверка сценариев, перенос данных из старой системы, обучение команды | Чем больше интеграций, тем больше точек для регрессионного тестирования |
Как технически оформляется переход от сметы к работающей системе: через техническое задание, пилотный запуск и приёмку, по шагам описано в статье о внедрении CRM системы.
Назвать точную сумму до обследования почти невозможно: оценка на глаз, сделанная без изучения реальных процессов компании, часто отличается от итоговой сметы в разы. Поэтому ответственные подрядчики сначала проводят анализ и собирают требования, а фиксируют бюджет уже после этого, а не наоборот.
Какие этапы и сроки проходит разработка
Срок проекта складывается не из одного модуля, а из цепочки этапов, и каждый влияет на следующий:
- Предпроектное обследование: аналитик фиксирует реальный процесс компании, а не идеализированную схему из презентации.
- Техническое задание и прототип интерфейса, по которым заказчик видит будущую систему до начала кодирования.
- Разработка базового функционала: ядро системы, карточки, права доступа, первые отчёты.
- Интеграции с внешними системами: телефония, мессенджеры, 1С, маркетплейсы.
- Тестирование сценариев и перенос данных из прежней системы или таблиц.
- Пилотный запуск на части отдела, сбор обратной связи и донастройка.
- Полноценный запуск на всю компанию и переход на постоянную поддержку.
Проекты с кастомной разработкой редко укладываются в рамки одного спринта: количество ролей и внешних систем растёт быстрее, чем кажется на старте, и именно оно, а не сам факт «написать CRM», определяет реальный срок.
Срок проекта зависит не только от объёма разработки, но и от скорости обратной связи на стороне заказчика. Согласование прототипа интерфейса и тестирование пилотной версии силами сотрудников компании часто растягиваются сильнее, чем сама разработка кода.
Команда, которая нужна для проекта
Для кастомной CRM нужна не пара фрилансеров, а команда с разделением ответственности:
- Аналитик или проектный менеджер: собирает требования, ведёт ТЗ, синхронизирует ожидания заказчика и разработчиков.
- Backend-разработчик: реализует бизнес-логику, права доступа, API для интеграций.
- Frontend-разработчик: собирает интерфейсы под роли и сценарии разных отделов.
- UX или UI-дизайнер: прорабатывает экраны так, чтобы менеджер не терял минуты на лишние клики в карточке сделки.
- QA-инженер: тестирует сценарии и регресс после каждой интеграции.
- DevOps-инженер: настраивает сервер, резервное копирование и мониторинг.
Если в компании нет штатного ИТ-отдела, эти роли закрывает подрядчик: тогда смета включает не только часы разработки, но и управление проектом на стороне исполнителя.
Размер команды не обязан расти пропорционально числу функций системы. На небольшом проекте один разработчик может совмещать роль аналитика и тестировщика, а на проекте с несколькими внешними интеграциями разделение ролей обычно окупается за счёт меньшего числа ошибок при запуске.
Интеграции, которые сильнее всего влияют на бюджет
Интеграции редко оценивают заранее верно, потому что сложность зависит не от CRM, а от документации и ограничений внешнего сервиса:
- 1С и внутренние ERP. Обмен данными о заказах, остатках и оплатах требует отдельного модуля синхронизации и обработки конфликтов данных.
- IP-телефония. Запись звонков, привязка к карточке клиента и статистика по менеджерам: стандартная, но трудоёмкая интеграция.
- WhatsApp Business API. Подключить к CRM личный номер напрямую нельзя, правила платформы это запрещают. Для корпоративной переписки нужен официальный WhatsApp Business API через аккредитованного провайдера, с верификацией юрлица и проверкой шаблонов сообщений.
- Telegram Bot API. Технически проще и, в отличие от WhatsApp, не тарифицируется по количеству сообщений, но исходящие сообщения возможны только после того, как пользователь сам написал боту.
- Маркетплейсы. API Ozon, Wildberries и других площадок меняются чаще, чем внутренние системы компании, и требуют поддержки интеграции после запуска.
- Платежи и ЭДО. Любая интеграция с движением денег требует дополнительного тестирования и логирования операций.
Прежде чем включать интеграцию в смету, стоит заранее изучить документацию внешнего сервиса. Лимиты на количество запросов в минуту, список доступных событий и формат ответов API различаются у каждого провайдера и редко совпадают с первыми ожиданиями команды разработки.
Требования к хранению данных и правам на систему
Два юридических момента стоит закрыть в договоре на разработку CRM ещё до старта, а не постфактум.
Локализация персональных данных
Часть 5 статьи 18 федерального закона № 152-ФЗ обязывает записывать, систематизировать и хранить персональные данные граждан России в базах данных, которые физически находятся на территории страны. Для CRM это значит: карточки клиентов, их телефоны и адреса должны храниться на сервере в России, даже если часть инфраструктуры компании размещена за рубежом.
Права на разработанный код
По статье 1296 Гражданского кодекса РФ исключительное право на программу, созданную по заказу, по умолчанию принадлежит заказчику, если договор с подрядчиком не предусматривает иное. На практике это означает: в договоре нужно явно прописать, кому принадлежит код, иначе возможны споры при смене подрядчика или переносе системы на свою инфраструктуру.
Оба пункта стоит закрыть на этапе коммерческого предложения, а не в процессе разработки. Изменить архитектуру хранения данных или переписать договор об исключительных правах после старта проекта обходится заметно дороже, чем сразу включить эти требования в техническое задание.
Fixed price или Time and Material: как выбрать модель оплаты
| Критерий | Fixed price | Time and Material |
|---|---|---|
| Когда подходит | Требования зафиксированы в ТЗ и не планируют меняться | Процессы ещё уточняются, нужна гибкость в ходе проекта |
| Кто несёт риск превышения часов | Исполнитель, поэтому закладывает запас в смету | Заказчик, но платит только за фактически отработанные часы |
| Изменения в ходе работы | Оформляются допсоглашением и пересчётом сметы | Встраиваются в текущий спринт без дополнительной бюрократии |
Для первой кастомной CRM чаще выбирают гибрид: фиксированную цену на предпроектное обследование и прототип, а дальше Time and Material, когда границы проекта уже понятны обеим сторонам.
Независимо от модели оплаты, в договоре стоит прописать порядок согласования правок и то, как считаются часы на доработки, обнаруженные уже на этапе тестирования. Это снимает большую часть споров на финальной стадии проекта, когда систему уже пробуют на реальных данных.
Частые вопросы
Сколько стоит разработка CRM системы под ключ?
Фиксированного прайса, как у коробочных тарифов, здесь нет: сумма формируется после предпроектного обследования по часам на аналитику, разработку, интеграции и тестирование. На практике интеграции с внешними сервисами нередко занимают сопоставимый объём часов с разработкой основной бизнес-логики, поэтому их список стоит зафиксировать до оценки сметы, а не добавлять по ходу проекта.
Нужно ли хранить данные клиентов на серверах в России?
Да. Часть 5 статьи 18 федерального закона № 152-ФЗ обязывает хранить персональные данные граждан России в базах данных, расположенных на территории страны. Для CRM это требование закладывается на этапе проектирования инфраструктуры, а не донастраивается после запуска.
Кому принадлежат права на CRM после разработки?
По умолчанию, согласно статье 1296 ГК РФ, исключительное право на систему принадлежит заказчику, если договор с подрядчиком не устанавливает иное. Это стоит явно проверить в договоре перед стартом проекта, а не полагаться на умолчания закона.
Можно ли запустить кастомную CRM поэтапно, а не всю сразу?
Да, это стандартная практика для таких проектов. Сначала запускают базовый функционал и ключевые интеграции на одном отделе, затем по обратной связи дорабатывают систему и подключают остальные подразделения и внешние сервисы.
Чем кастомная разработка отличается от доработки готовой CRM?
Доработка ограничена API и архитектурой поставщика коробочного решения: часть сценариев реализовать невозможно в принципе. Кастомная разработка даёт полный контроль над архитектурой и кодом, но требует отдельной команды поддержки вместо техподдержки вендора.
С чего начать
Прежде чем обращаться к подрядчику, стоит подготовить четыре вещи:
- Опишите реальный процесс компании, а не идеальную схему: кто, что и в какой последовательности делает с клиентом сейчас.
- Составьте список систем, с которыми CRM должна работать: 1С, телефония, сайт, мессенджеры, маркетплейсы.
- Зафиксируйте, кто в компании отвечает за бюджет и права на разработку, прежде чем подписывать договор.
- Закажите предпроектное обследование, чтобы получить архитектуру и смету, основанную на процессах, а не на ценнике на глаз.
Часть этих пунктов можно закрыть силами внутренней команды за один-два дня, если выделить время и назначить ответственного. Если разбираться во всём этом самостоятельно некогда, предпроектным обследованием, архитектурой и самой разработкой занимается команда заказной разработки Neurounit.
