Готовая или собственная CRM: как выбрать по процессам и стоимости, а не по демо

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

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

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

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

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

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

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

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

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

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

Fit-gap — практический способ не спорить абстрактно. «Fit» — то, что решение поддерживает без существенной переделки. «Gap» — разрыв между обязательным сценарием бизнеса и возможностями кандидата.

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

Не доверяйте только словам «это можно сделать». Попросите показать сценарий на демо-данных, а затем проведите короткий пилот на нескольких реальных сделках. У вендоров есть API и механизмы расширения — например, документация Битрикс24 и amoCRM описывает возможности интеграций. Но наличие API не доказывает, что конкретная задача будет дешёвой, безопасной или поддерживаемой после обновления.

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

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

Качество программного продукта не сводится к интерфейсу. ISO/IEC 25010 описывает среди характеристик надёжность, безопасность, сопровождаемость и совместимость. Для выбора CRM это удобный словарь вопросов: как решение переживает ошибку интеграции, как ограничивает права, насколько легко его изменить и как оно взаимодействует с остальными системами. Это не означает, что малому бизнесу нужен полный стандартный аудит.

Проверьте четыре условия одновременно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такой порядок помогает не покупать самый знакомый инструмент и не строить продукт из тревоги перед зависимостью.

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

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