Розробка CRM-системи з нуля проходить через шість базових етапів:
Нижче — розбір кожного етапу з реальними архітектурними рішеннями, цінами й термінами з наших проєктів у fintech та Web3.
Класична CRM-платформа буває трьох типів: операційна автоматизує продажі та маркетингові завдання, аналітична рахує метрики й будує прогнози, а колаборативна синхронізує комунікацію між відділами. Проблема виникає тоді, коли бізнес виростає за межі одного типу одночасно — і потребує автоматизації, аналітики та рольової логіки для sales-, retention- та affiliate-команд в одній системі.
Ми зіткнулися з цим на проєкті брокерської платформи: класичні CRM (Zoho, HubSpot, AmoCRM) не витримували multi-role логіку — sales, retention, affiliate-команди й маркетингові воронки одночасно. Кастомізація готового рішення давала лише часткове покриття — потрібного бізнесу рівня автоматизації вона все одно не забезпечувала.
Наш досвід: клієнт масштабував відділ продажів до 60 агентів кол-центру на базі стандартної CRM. Система не тримала одночасно sales-, retention- і affiliate-воронки — менеджери передавали ліди між відділами й вели історію взаємодій напівручним способом поза системою.
Рішення: ми запропонували двофазну міграцію. На короткій дистанції інтегрували поточну CRM через API — IP-телефонія, токени доступу, синхронізація контактів, щоб не зупиняти продажі. Паралельно спроєктували власну CRM з нативним тегуванням лідів, маршрутизацією між відділами та окремим шаром аналітики кол-центру. Канали лідогенерації — CSV/Excel-імпорт, лендинги, реєстраційні форми — ми завели на автоматичне створення акаунтів і auto-routing всередині CRM.
Результат: CRM перестала бути допоміжним інструментом і стала revenue engine бізнесу — до 70% ефективності продажного контуру тепер залежить безпосередньо від неї. Архітектура витримує масштабування з 10 до 60+ агентів без рефакторингу core-логіки.
Якщо ви плануєте запуск подібної платформи, ми детально розбираємо суміжний кейс у матеріалі про те, як відкрити брокерську фірму — там пояснюємо, чому CRM у форекс-бізнесі стає центральною системою, а не додатковим модулем.
Порівняння варто робити не за списком фіч, а за тим, у що конкретно впирається ваш бізнес через рік роботи з готовим інструментом.
| Критерій | Готове рішення (Salesforce, HubSpot, Zoho) | CRM на замовлення |
| Вартість запуску | Нижча на старті, зростає з кожним новим користувачем | Вища на старті, фіксована незалежно від кількості агентів |
| Рольова модель | Обмежена шаблонами вендора | Проєктується під конкретні відділи та процеси |
| Інтеграції | Через маркетплейс додатків, з обмеженнями API | Прямі інтеграції з будь-якою внутрішньою системою |
| Володіння даними | Дані живуть на інфраструктурі вендора | Повний контроль над зберіганням і доступом |
| Масштабування | Оплата за користувача зростає лінійно | Масштабується без збільшення вартості ліцензій |
| Кастомізація воронки продажів | Часткова, у межах логіки вендора | Повна — під ваш реальний sales-процес |
У наших проєктах бекенд CRM зазвичай будуємо на Laravel або Node.js, фронтенд — на React, а дані зберігаємо в PostgreSQL або MongoDB залежно від того, наскільки жорстко бізнесу потрібна реляційна цілісність. Для обробки лідів у реальному часі — вхідні заявки з лендингів, синхронізація контактів, сповіщення — використовуємо Redis і Kafka як messaging layer: окремі worker-и обробляють чергу, поки веб-сервіси відповідають на запити користувачів.
Навіть коли фреймворк не підтримує Kafka нативно, ми інтегруємо її через кастомну бібліотеку з коректним lifecycle-менеджментом сесій — це закриває проблему на рівні архітектури, а не костиля.
У production CRM з високим навантаженням ми розділяємо control plane і worker-ноди на Kubernetes, а секрети — токени доступу, ключі API — виносимо у HashiCorp Vault з JWT-автентифікацією. CPU/RAM requests та limits на рівні Kubernetes контролюють навантаження і запобігають деградації продуктивності під піковим трафіком.
Окремо для CRM з ризик-скорингом лідів чи угод ми проєктуємо risk-engine як ML-ready з першого дня — навіть якщо перша версія працює на правилах, а не на моделі. Це дає можливість підключити прогнозну аналітику пізніше без переписування ядра системи; детальніше про підхід до впровадження ШІ в бізнес-процеси ми розповідаємо в матеріалі про розробку штучного інтелекту для бізнесу.
Наш досвід: продукт потребував одночасної підтримки фінансових операцій і небанківських заявок у межах однієї платформи. Окремий сервіс під кожен тип заявки означав дублювання бізнес-логіки й подвоєння state machine з кожним новим напрямом.
Рішення: ми спроєктували єдину модель заявки з умовними полями під тип угоди, зберігаючи один status-driven pipeline: очікує оплати → в процесі → верифікація → завершено. Ролі Client, Agent та Administrator отримали окрему логіку доступу поверх спільної моделі даних, а не окремі бекенди.
Результат: команда розширює наявний data layer замість написання нового сервісу під кожен продуктовий напрям — це скорочує time-to-market і прибирає дублювання state-машини під час масштабування бізнесу на нові вертикалі.
Той самий принцип unified pipeline ми застосовуємо в маркетплейсах з рольовими адмін-панелями — детальніше про типову архітектуру ролей і модерації розбираємо в матеріалі про те, як створити маркетплейс.
Дозволи на основі ролей обмежують доступ кожного користувача лише до даних, що стосуються його ролі. Це базовий рівень, але для CRM, яка працює з фінансовими даними чи персональною інформацією клієнтів, цього недостатньо — потрібен ще й аудит-трейл: кожна зміна порогу, права чи статусу угоди фіксується разом зі старим і новим значенням, інакше систему неможливо провести через зовнішній аудит.
Наш досвід: на high-load продакшн-системі один SQL-запит без коректного індексу почав блокувати авторизацію — і для звичайних користувачів, і для адміністраторів. Паралельно 2FA-логіка вимагала окремого підтвердження на кожну зміну кожного поля в адмін-панелі, а при 70+ категоріях налаштувань це перетворювалося на сотні зайвих запитів заради однієї конфігурації.
Рішення: ми додали індекс на проблемному запиті й винесли throttling для важких legacy-запитів. OTP-логіку розділили на два незалежні сервіси зі спільною бібліотекою, але різними конфігураційними шарами — TTL, grace period і заборону повторного використання коду виносимо в env/config, без релізу коду. Секрети керуємо через HashiCorp Vault з JWT-автентифікацією, а кожну зміну прав чи порогу логуємо разом із old_value/new_value.
Результат: auth-флоу і адмін-панель стабілізуються під навантаженням без деградації швидкодії, операційне навантаження на конфігурацію доступів падає в рази, а audit trail закриває вимоги compliance-аудиту.
Подібну послідовність етапів проходить будь-яка складна розробка — детальніше про типові фази ми розписували в матеріалі про етапи розробки мобільних додатків. Для CRM послідовність виглядає так:
Для CRM із вбудованою комунікацією між менеджером і клієнтом (чат усередині картки угоди) ми застосовуємо ті самі архітектурні принципи, що й у розробці окремих месенджерів — детальніше про підхід читайте в матеріалі про те, як створити месенджер.
Замість орієнтовних "вилок", які кочують з блогу в блог, наводимо цифри з реальних кошторисів проєктів із подібною архітектурою — рольовою адмін-панеллю, керуванням правами та pipeline угод.
| Рівень | Що входить | Вартість | Термін |
| Базовий (MVP) | Рольова адмін-панель, dashboard, керування користувачами, базова звітність | $26 000 – $48 000 | 1.5–2.5 місяці |
| Стандартний | Рольова модель адміністраторів (створення/редагування прав), 2FA, мобільний доступ | $36 000 – $61 000 | 2.5–3 місяці |
| Enterprise | Pipeline угод, контроль бюджетів, транзакційна історія, складна аналітика | $116 000 – $140 000 | 5–7 місяців |
Якщо потрібна не унікальна логіка, а адаптація вже готового продукту під ваш бренд, кастомізація коштує суттєво менше — від $44 000 за 2–2.5 місяці, що економить до 45% бюджету й часу порівняно з розробкою з нуля. Різницю варто розуміти чітко на старті, щоб не переплачувати за enterprise-архітектуру там, де вистачить базового рівня.
Кастомна CRM виправдовує себе тоді, коли готове рішення починає обмежувати не інтерфейс, а бізнес-логіку — рольову модель, воронку, інтеграції. Ми проєктуємо CRM-архітектуру так, щоб вона витримувала зростання команди в рази без рефакторингу ядра, і підкріплюємо кожне архітектурне рішення реальним досвідом із fintech- та Web3-проєктів, а не шаблонами з чужих кейсів.
Це програма, яка зберігає всі дані про клієнтів і угоди в одному місці та автоматизує рутинні дії відділу продажів — від першого контакту до закриття угоди.
Custom CRM проєктується під вашу рольову модель і бізнес-процеси без обмежень чужого продукту, а оплата не зростає лінійно з кожним новим користувачем.
Базовий рівень із рольовою адмін-панеллю коштує $26 000–$48 000, enterprise-рівень із pipeline угод і складною аналітикою — $116 000–$140 000, залежно від обсягу функціоналу.
MVP займає 1.5–3 місяці, enterprise-рішення з глибокими інтеграціями — 5–7 місяців, включно з дискавері-фазою та тестуванням.
Так, якщо стартап масштабує продажі й натикається на обмеження готових рішень у рольовій логіці чи інтеграціях — базовий рівень CRM закриває це без переплати за enterprise-функціонал.
Так — ризик-скоринг лідів чи угод варто проєктувати як ML-ready модуль із першого дня, навіть якщо перша версія працює на правилах, а не на моделі.