Три ознаки, що пора міняти 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-аудит →