Разработка CRM на заказ

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

Создаём web-приложения на Laravel, PHP и JavaScript, проектируем базы данных, REST API, личные кабинеты и административные интерфейсы. CRM может работать как самостоятельная система или стать частью существующей IT-инфраструктуры компании.

Обсудить разработку CRM

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

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

Такой подход подходит для B2B-компаний со сложным циклом сделки, сервисных компаний, финансовых организаций, производства, логистики, недвижимости и проектов, где CRM постепенно становится основной рабочей системой.

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

Даже понятие «клиент» требует проектирования. В B2B одна компания может иметь 15 контактных лиц, несколько юридических лиц, десятки договоров и одновременно вести 6 активных проектов. Один договор связан с платежами и документами, отдельные документы относятся к конкретному этапу сделки, доступ к финансовым данным есть только у части сотрудников. Такая структура должна существовать на уровне базы данных и серверной логики, а не собираться из случайного набора полей в интерфейсе.

До активного программирования фиксируем основные сценарии. Разработчик уже понимает, что произойдёт после создания сделки, смены статуса, загрузки договора, поступления оплаты или изменения ответственного сотрудника.

Для большинства корпоративных CRM используем клиент-серверную архитектуру. Серверная часть отвечает за бизнес-логику, права, работу с базой данных, документы, интеграции и API. Web-интерфейс получает только те данные и операции, которые доступны конкретному пользователю.

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

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

Для серверной части корпоративных CRM мы используем PHP и Laravel. Фреймворк даёт готовую инфраструктуру для маршрутизации, аутентификации, валидации, очередей, событий, работы с базой данных, кеширования, планировщика и тестирования. Разработчики концентрируются на бизнес-логике проекта вместо создания базовых механизмов приложения заново.

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

Laravel поддерживает фоновые очереди через Redis, Amazon SQS и другие драйверы. Это полезно для операций, которым не место внутри обычного HTTP-запроса: генерации большого отчёта, импорта нескольких тысяч строк, отправки уведомлений или синхронизации с внешним API. Пользователь сохраняет карточку и продолжает работу, тяжёлая операция выполняется отдельным worker-процессом.

Обсудить разработку CRM

Интерфейс CRM рассчитан на ежедневную работу. Менеджер может проводить в системе 6–8 часов, поэтому скорость выполнения обычных операций важнее декоративных эффектов. Проектируем таблицы, фильтры, карточки, поиск, массовые операции, формы, Kanban, историю изменений и быстрые переходы между связанными объектами.

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

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

В качестве основной реляционной базы для сложных CRM используем PostgreSQL. Большая часть корпоративных данных имеет чёткие связи: компания связана с контактами, сделки — с компаниями, договоры — со сделками, платежи — с договорами. Реляционная модель хорошо подходит для такой структуры и позволяет контролировать целостность данных на уровне самой БД.

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

Часть редко меняющихся или проектно-зависимых параметров можно хранить в JSONB, сохраняя основную структуру реляционной. Такой вариант полезен для дополнительных характеристик сущностей, состав которых отличается между типами объектов. Базовые связи и критичные для отчётности данные оставляем нормализованными.

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

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

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

В корпоративной CRM редко достаточно ролей «пользователь» и «администратор». Менеджер видит свои сделки, руководитель отдела — сделки подразделения, финансовый директор — платежи нескольких юридических лиц. Клиент получает доступ только к своим договорам, поставщик — к связанным с ним заказам, а системный администратор управляет пользователями без доступа к части коммерческой информации.

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

Используем принцип минимально необходимых привилегий. OWASP ASVS отдельно выделяет контроль доступа и защиту от ситуаций, когда пользователь подменяет идентификатор объекта в запросе и получает чужую запись. Для CRM с договорами, финансовыми данными и клиентскими документами это одна из базовых частей архитектуры безопасности.

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

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

Обсудить разработку CRM

CRM почти всегда обменивается данными с другими системами. Для этого проектируем REST API, webhooks и отдельные интеграционные сервисы. В зависимости от проекта связываем CRM с 1С, сайтом, телефонией, платёжными сервисами, службами доставки, электронной почтой, системами электронного документооборота и внутренним ПО заказчика.

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

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

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

Для каждого направления обмена фиксируем идентификаторы объектов, правила создания и обновления, формат данных, обработку ошибок и повторных запросов. В CRM хранится связь между внутренним ID и идентификатором объекта 1С. Журнал интеграции позволяет увидеть время обмена, отправленные данные, полученный ответ и причину ошибки.

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

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

Файловое хранилище отделяем от структуры основной базы. В БД остаются метаданные и связи, сами файлы размещаются в предназначенном для этого хранилище. Для больших проектов используется S3-совместимое объектное хранилище. Такой подход упрощает резервное копирование, масштабирование и работу с крупными объёмами документов.

Загрузка файла проходит серверную проверку. Контролируются допустимые типы, размер и права пользователя на добавление документа к конкретному объекту. Ссылки на закрытые документы не должны превращать файл в публичный ресурс.

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

Часть правил реализуется непосредственно в бизнес-логике, часть выносится в настраиваемые сценарии. Система создаёт задачи, меняет ответственных, отправляет уведомления, формирует документы, обращается к внешнему API или ставит фоновую задачу в очередь. Для критичных операций сохраняется история выполнения.

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

Обсудить разработку CRM

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

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

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

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

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

Соединение с CRM работает по HTTPS. Laravel предоставляет штатные механизмы шифрования данных на базе OpenSSL; зашифрованные значения дополнительно подписываются MAC для контроля целостности. Критичные поля можно шифровать на уровне приложения.

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

Резервная копия имеет смысл только вместе с проверенным восстановлением. Для production-систем настраиваем резервирование базы данных и файлов с подходящей для проекта периодичностью. Копии хранятся отдельно от рабочего сервера.

Перед крупными обновлениями создаётся дополнительная точка восстановления. Для проектов с высокими требованиями к доступности отдельно определяются RPO и RTO: допустимый объём потерянных данных и время, за которое система должна вернуться в рабочее состояние после аварии.

CRM может начать работу с 20 сотрудниками и 3 000 клиентов, а через несколько лет содержать миллионы связанных записей. Рост учитываем в структуре БД, индексах, запросах и архитектуре фоновых операций.

Большие списки выводятся постранично, поиск выполняется на сервере, тяжёлые отчёты не рассчитываются заново при каждом открытии страницы. Часто используемые данные кешируются. Массовый импорт, экспорт и синхронизация уходят в очереди. Для узких мест анализируем SQL-запросы и планы выполнения вместо попытки ускорить систему увеличением мощности сервера.

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

CRM тестируется на нескольких уровнях. Unit-тесты проверяют отдельные правила бизнес-логики. Feature- и integration-тесты проходят через HTTP API, базу данных и связанные сервисы. Критичные пользовательские сценарии проверяются целиком.

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

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

Обсудить разработку CRM

Исходный код хранится в Git. Работа ведётся через отдельные ветки и проходит code review. Для проекта используются как минимум отдельные среды разработки и production; для крупных систем добавляется staging, где проверяется релиз перед публикацией.

Автоматизированный pipeline может запускать тесты и статический анализ перед сборкой. Миграции базы версионируются вместе с кодом. Разработчик получает возможность поднять нужную версию приложения вместе с соответствующей структурой данных.

Обновления выпускаем небольшими частями. Такой режим проще тестировать и откатывать. Большой проект на 6–12 месяцев не должен превращаться в один гигантский релиз в последний день разработки.

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

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

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

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

У кастомной CRM нет содержательной фиксированной цены за «одну систему». Проект на 5 ролей, 40 экранов и 3 внешние интеграции отличается по объёму от внутренней CRM одного отдела в несколько раз.

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

Первичную оценку можно сделать после обсуждения процессов. Для крупного проекта сначала проводим аналитику и проектирование, затем формируем архитектуру, состав модулей и смету разработки. Такой расчёт намного точнее оценки по количеству страниц технического задания.

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

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

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

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

Обсудить разработку CRM