Когда собственная модель продаж оправдывает кастомную CRM

В отделе продаж всё уже «почти работает»: заявки приходят в готовую CRM, склад отвечает в учётной системе, договоры лежат в ЭДО, а менеджер всё равно ведёт главный список в таблице. В такой момент легко решить, что нужна собственная CRM. Но таблица часто появляется не потому, что продукт плохой, а потому, что компания не договорилась, какой объект ведёт, кто меняет его состояние и где заканчивается ответственность каждого контура.

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

Собственная система окупается не уникальными экранами, а тем, что снимает повторяющиеся ручные разрывы в важном процессе.

«У нас всё особенное» — слабое основание для разработки. Во многих случаях особенность оказывается названием этапа, формой отчёта или привычным маршрутом согласования. Это решается настройкой готовой CRM, интеграцией или изменением регламента дешевле, чем новым продуктом.

Сигнал сильнее, когда компания управляет предметом, которого готовая CRM не понимает без постоянных обходов. Например, производитель рассчитывает изделие по конфигурации, согласует технические версии, резервирует компоненты и ведёт поставку по нескольким площадкам. Для него центральным объектом может быть не «сделка», а спецификация с ревизиями, ограничениями и связью с заказом. У сервисной сети главным объектом может быть заявка на выезд с маршрутом, оборудованием и нормативным сроком. У B2B-площадки — запрос с ролями участников, документами и решением комитета.

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

У бизнеса обычно есть четыре пути. Граница с кастомной CMS здесь проста: CMS управляет содержанием сайта, а CRM — клиентским процессом и связанными событиями; иногда они обмениваются данными, но не заменяют друг друга.

Сравнение должно включать не только цену первого релиза. У готового решения есть лицензии, доработки и зависимость от его модели. У собственного — исследование, разработка, тестирование, поддержка, мониторинг, резервное копирование, безопасность и последующие изменения. ISO/IEC/IEEE 12207 описывает жизненный цикл программного обеспечения шире, чем создание первой версии: система остаётся обязательством после запуска.

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

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

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

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

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

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

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

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

Первый релиз не должен пытаться заменить все таблицы и мессенджеры. Его цель — доказать один сквозной процесс с минимальным числом ролей. Это тот же принцип, что у MVP: проверять ценность на ограниченном маршруте, а не финансировать большую гипотезу целиком. Для производителя это может быть путь от заявки на расчёт до согласованного предложения; для сервисной компании — от обращения до назначенного выезда; для партнёрского бизнеса — от заявки до подтверждённой поставки.

В MVP обычно достаточно:

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

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

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

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

Отдельный слой — персональные данные. CRM хранит контакты, переписку, документы и иногда данные повышенной чувствительности. Закон № 152-ФЗ задаёт рамку обработки персональных данных в России, но конкретные основания и меры зависят от состава данных, цели, отрасли и роли участников. В проекте нужно отдельно определить основания и сроки обработки, доступы, меры защиты, журналирование, порядок удаления и передачу внешним сервисам. Поле согласия в форме не заменяет весь этот контур.

Локализация баз при сборе данных граждан России и трансграничная передача — разные вопросы. При сборе через интернет закон, за установленными исключениями, не допускает запись, систематизацию, накопление, хранение, уточнение и извлечение таких данных с использованием баз за пределами России. До трансграничной передачи оператор проходит отдельную процедуру по статье 12, включая уведомление Роскомнадзора, и проверяет страну и получателя; применимость исключений и конкретный порядок требуют юридической проверки.

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

Для этого в приёмочном наборе должны быть не только успешные записи. Нужны дубль с тем же идентификатором, неполные данные, конфликт одновременных изменений, просроченная задача, пользователь без нужных прав и восстановление после сбоя. Результат теста фиксируют как ожидаемое состояние в каждой системе, а не как «разработчик посмотрел логи». Такой список потом остаётся регрессионной проверкой для каждой существенной доработки.

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

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

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

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

Кастомная CRM нужна не бизнесу «с нестандартными задачами вообще», а процессу, который нельзя надёжно вести готовыми средствами без ручных разрывов и потери важных данных. Сначала сравните альтернативы, затем опишите объекты и владельцев, выберите один сквозной сценарий для MVP и проверьте его на сбоях. Если в этой схеме пока не видно процесса, разработку лучше отложить: она не заменит управленческое решение.

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