Собственная CRM или облачный сервис: как принять решение

Покажем на примере проекта, почему обычная задача рассылки потребовала собственной CRM и какие условия оправдывают такой выбор.

Функций готового сервиса было достаточно

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

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

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

Что меняется, когда данные критичны для бизнеса

Зависимость от сервиса обычно воспринимается как плата за удобство. Поставщик отвечает за работу платформы, обновления и часть инфраструктуры.

У этой модели есть обратная сторона. Бизнес принимает правила чужой системы:

• место и порядок хранения данных;
• доступные механизмы интеграции;
• возможности журнала операций;
• сроки реакции технической поддержки.

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

Поэтому заказчик выбрал CRM, работающую внутри его защищенного контура.

Что пришлось создать

Систему разработали на Django. Она объединила клиентскую базу, редактор писем, сегментацию, управление согласиями и журнал действий.

При загрузке контакту назначался уникальный идентификатор. Все изменения фиксировались с указанием времени.

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

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

Как собирали статистику

Подключать внешнюю аналитическую платформу не стали. Открытия писем учитывались с помощью небольшого изображения размером 1×1 пиксель.

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

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

Почему одной CRM оказалось мало

Поэтому интенсивность повышали постепенно. Также настроили SPF, DKIM и DMARC, чтобы принимающие серверы могли проверить источник письма.

После подготовки система приблизилась к скорости 60 000 писем в час. База из 70 000 контактов обрабатывалась в требуемый срок.

Как определяли достаточный уровень защиты

Систему разместили на РЕД ОС в сертифицированном сегменте Selectel. В инфраструктуре использовались Dr.Web и Secret Net Studio для Linux.

Команда рассматривала и более сложные меры. Например, полное шифрование базы и отдельные серверы для защищенного удаленного доступа.

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

Для руководителя это важный принцип: безопасность нельзя оценивать по количеству купленных продуктов. Каждая мера должна закрывать понятный риск.

Что получил заказчик

Бэкенд разработали за 2 недели. Весь проект занял 3 недели без учета согласования дизайна.

CRM работала с базой из 70 000 пользователей. Основные операции с согласиями выполнялись автоматически. Перед мероприятием заказчик мог сформировать актуальную базу и запустить рассылку без обращения к внешней платформе.

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

Когда собственная разработка оправдана

Собственное решение стоит рассматривать, когда одновременно выполняются несколько условий:

1. Данные нельзя передавать внешнему поставщику.
2. Требуется особая логика обработки согласий.
3. Каждое действие должно подтверждаться журналом.
4. Рассылка встроена в другие внутренние процессы.
5. Ограничения платформы создают постоянные ручные операции.

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

Что проверить перед началом проекта

Руководителю стоит начать с процесса, а не с выбора технологии.

Нужно определить:

• какие данные использует система;
• где они должны храниться;
• кто отвечает за их актуальность;
• как фиксируются согласия;
• что происходит после отказа пользователя;
• какую скорость и периодичность рассылок должна выдерживать инфраструктура.

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

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