Три признака, что пора менять CRM, — и когда достаточно написать модуль

Автор: Андрей Марьясов · 15 сент. 2026 г. · 6 мин чтения

Когда хватит модуля: три признака

Признак 1. Болит один конкретный процесс, а остальная система работает нормально

Если менеджеры не жалуются на карточки клиентов, воронку, отчёты и права, но каждый месяц мучаются из-за одного специфического сценария (расписание, расчёт, нестандартный статус) — это не проблема платформы. Это недостающий инструмент на правильной платформе. Менять всю систему из-за одного узла, который не закрывает коробка, — значит нести расходы на миграцию без реального выигрыша в функциях.

Признак 2. Все нужные данные уже есть в CRM

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

Признак 3. Команда знает платформу и понимает, как в ней работать

Переход на новую систему стоит не только денег: 2–3 месяца адаптации, параллельная работа в двух системах, часть людей, которые не хотят учиться заново. Если платформа подходит по всем параметрам, кроме одного, эту цену платить не нужно. Модуль появляется в привычном интерфейсе, и команда начинает им пользоваться без перестройки.

Когда нужна новая CRM: три признака

Признак 1. Платформа не расширяется или не поддерживается

Если вендор не даёт API для кастомных разработок, объявил о прекращении поддержки или архитектура системы не позволяет добавить изолированный модуль без изменения ядра — модуль не спасёт. То, что нельзя дописать безопасно, превращается в хак, и каждое обновление системы становится риском: смена одной версии может сломать всё, что было надстроено сверху.

Признак 2. Модель данных платформы принципиально не подходит бизнесу

Некоторые CRM построены вокруг B2C-логики: один клиент — одна сделка. Другие — вокруг B2B: компания → контакт → сделка → проект. Если ваш бизнес вырос и сегодня вы втискиваете сложную иерархию в структуру, которая для этого не предназначена, ни один модуль не исправит основу. Модуль расширяет то, что есть, но не перестраивает фундамент.

Признак 3. Болевых точек больше одной, и они в разных местах системы

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

Пять вопросов, чтобы решить за 10 минут

Если вы сейчас стоите перед этим выбором, ответьте на пять вопросов:

Сколько процессов болит? Один — скорее всего, модуль. Три и больше в разных частях системы — стоит смотреть на платформу в целом.
Данные для решения проблемы уже есть в CRM? Да — модуль. Нет (нужно брать из другого источника) — сложнее, но часто всё равно модуль с интеграцией.
Вендор даёт API для кастомных разработок? Нет — модуль становится хаком, и поддержка будет дорожать. Да — продолжаем проверку.
Команда готова переучиваться? Если нет — ещё один аргумент в пользу модуля: люди уже знают систему и сразу начнут им пользоваться.
Смена платформы — отдельный проект или хочется решить вопрос сейчас? Если нужно решить сейчас — начинайте с модуля. Миграция — это отдельная инициатива с бюджетом и сроками, а не исправление текущей боли.

Кейс: учебный центр, который думал, что нужна новая CRM

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

Вначале вопрос стоял так: «Может, нужна новая платформа?» Проверили по критериям выше: платформа расширяется через API, все данные есть, остальная система работает, команда знакома с интерфейсом. Единственная болевая точка — один специфический процесс. Auspex написал поверх имеющейся CRM отдельный модуль: одно нажатие — и расписание сформировано, ещё одно — зафиксировано. Ноль изменений в ядре платформы; модуль изолирован и переносится при миграции.

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

С чего начать

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

Частые вопросы

Сколько стоит кастомный модуль для CRM?

Фиксированного прайса нет — всё зависит от сложности правил и платформы. Ориентир из нашей практики — модуль расписания для учебного центра с отраслевыми правилами: оценка на старте — 60 часов разработки, рабочая версия — через две недели после первого коммита. Модулю без сложной логики обычно нужно меньше часов. Auspex сначала смотрит на процесс и имеющуюся конфигурацию, затем называет оценку. Бесплатный аудит CRM занимает 30 минут.

Не сломается ли модуль после обновления CRM?

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

Когда лучше менять CRM, а не дописывать модуль?

Когда болевых точек три или больше в разных частях системы. Или когда модель данных платформы принципиально не подходит бизнесу — например, сложная B2B-иерархия втиснута в B2C-структуру. Или когда вендор не даёт API для кастомных разработок и любая доработка становится хаком.

Что такое изолированный модуль и чем он отличается от настроек CRM?

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

Сколько времени занимает разработка и внедрение модуля?

Зависит от сложности. Из кейса учебного центра: рабочая версия — через две недели после первого коммита, полный цикл с приёмкой и правками — дольше. Медиана запуска проектов Auspex — 30 дней, сложные интеграции — до 6 недель. Мы показываем обе цифры: написать код и сдать систему в эксплуатацию — разные по длительности вещи.

Бесплатный CRM-аудит →