Чому вартість CRM-проєкту може відрізнятися у 5–10 разів

Дві компанії звертаються до інтегратора з однаковим запитом: потрібна CRM для відділу продажів.

Перша хоче вести клієнтів, угоди, дзвінки та завдання. Друга теж говорить про клієнтів, угоди й продажі, але під час обговорення з’являються інтеграція з ERP, кілька напрямів продажу, автоматичний розподіл звернень, план-факт, контроль прострочених угод, погодження документів, звіти для керівництва та перенесення історичних даних.

Називаються обидва проєкти однаково. Обсяг робіт відрізняється у кілька разів.

Саме тому вартість впровадження CRM складно визначити лише за кількістю користувачів або переліком стандартних модулів. Значну частину бюджету формує не сама CRM-система, а те, наскільки глибоко вона має бути вбудована у процеси компанії.

Розберемо, з яких складників формується бюджет CRM-проєкту, що впливає на його зростання найбільше  та як порівнювати пропозиції інтеграторів так, щоб оцінити однаковий обсяг робіт.

Ліцензія CRM і вартість проєкту — різні речі

Під час вибору CRM бізнес часто починає з вартості програмного продукту: скільки коштує користувач, місячна підписка або корпоративна ліцензія.

Це зрозуміла цифра, але вона показує лише частину витрат.

Умовно CRM-проєкт можна розкласти на кілька складників:

• програмна платформа;
• аналіз процесів;
• конфігурація системи;
• інтеграції;
• індивідуальна розробка;
• міграція даних;
• тестування;
• навчання;
• запуск;
• подальша підтримка та розвиток.

У простому проєкті більшість потреб компанії закриває стандартний функціонал. Інтегратор налаштовує структуру карток, етапи продажу, права доступу, довідники та звіти.

У складнішому проєкті програмна платформа залишається тією самою, але кількість робіт навколо неї зростає.

Тому ціна CRM як продукту і ціна її впровадження можуть відрізнятися у кілька разів.

Найдешевша частина проєкту часто вже є в CRM

Контакти, компанії, угоди, завдання, календар, історія взаємодій, базові звіти та ролі користувачів є у багатьох CRM-системах.

Створити додаткове поле «Тип клієнта» теж нескладно.

Складність починається з формулювання: «Якщо клієнт належить до категорії А, купує певну групу товарів, має прострочену дебіторську заборгованість і працює з регіональним менеджером, система повинна виконати одну дію. Але для категорії B — іншу».

Тут ми вже працюємо не з полем у картці, а з бізнес-логікою.

Що більше таких правил, винятків, перевірок та взаємозалежностей, то більше часу потребують проєктування, розробка й тестування.

Саме тому перелік модулів мало говорить про реальний масштаб проєкту.

У двох компаній можуть бути однакові сутності:

• клієнти;
• контакти;
• угоди;
• товари;
• рахунки;
• завдання.

А логіка роботи цих сутностей відрізнятиметься кардинально.

Базова конфігурація і розробка мають різну вартість

Одна з головних меж у CRM-проєкті проходить між налаштуванням готового функціоналу та створенням нового.

Змінити назву поля, додати довідник, створити новий статус або налаштувати права користувача — це конфігурація.

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

Різниця важлива не тільки для бюджету.

Конфігурація використовує можливості, які вже передбачені архітектурою CRM. Розробка додає нову логіку, яку потрібно:

• спроєктувати;
• реалізувати;
• протестувати;
• описати;
• підтримувати після запуску.

Один запит може містити обидві частини.

Компанія хоче вести проєкти після продажу. Сам модуль проєктів уже існує. Але автоматичне створення проєкту після підписання договору, формування набору завдань залежно від типу клієнта та контроль строків можуть потребувати окремої логіки.

Назва функції одна — «робота з проєктами». Обсяг робіт різний.

Інтеграції швидко збільшують бюджет

CRM рідко працює ізольовано.

У компанії вже можуть бути:

• ERP;
• бухгалтерська система;
• телефонія;
• сайт;
• інтернет-магазин;
• служба підтримки;
• корпоративна пошта;
• месенджери;
• маркетингові платформи;
• системи документообігу.

Кожна інтеграція додає окремий блок робіт.

І річ не лише у передачі даних між двома системами.

Потрібно визначити:

• яка система є джерелом конкретних даних;
• що передається в CRM;
• що передається назад;
• коли відбувається синхронізація;
• що робити в разі помилки;
• як обробляти дублікати;
• хто може змінювати інформацію;
• як поводитися, якщо одна із систем недоступна.

Інтеграція телефонії може означати просту функцію click-to-call.

А може охоплювати картку клієнта під час дзвінка, автоматичне створення активності, запис розмови, маршрутизацію, визначення відповідального менеджера та звітність.

Формулювання «інтеграція з телефонією» в обох випадках однакове.

Те саме стосується ERP.

Передавати з ERP залишок товару раз на добу — одне завдання.
Синхронізувати товари, ціни, залишки, замовлення, рахунки, оплати, дебіторську заборгованість і статуси документів у двох напрямах — інше.

Саме тому під час оцінки інтеграції важливо дивитися не на назву системи, а на сценарії обміну.

Один відділ продажів може означати кілька різних процесів

На першій зустрічі компанія може сказати: «У нас звичайний відділ продажів».

Під час аналізу виявляється, що є:

• прямі продажі;
• дилерський напрям;
• тендери;
• повторні продажі;
• ключові клієнти;
• окремі правила для регіонів.

У кожного напряму своя воронка.

Десь угода починається із заявки.
Десь — із тендерної процедури.
Для одного типу клієнтів потрібне погодження з керівником.
Для іншого — з фінансовим відділом.
Один менеджер може бачити лише свої угоди, регіональний керівник — свій регіон, а комерційний директор — усю структуру.

Формально компанія впроваджує одну CRM. Фактично інтегратор проєктує в ній кілька пов’язаних робочих процесів.

Права доступу теж можуть бути окремим проєктом

У команді з десяти менеджерів права доступу часто прості.

Менеджер бачить своїх клієнтів. Керівник бачить клієнтів відділу.

У компанії на 200–300 працівників структура може передбачати філії, регіони, департаменти, функціональні ролі та керівників кількох рівнів.

Тоді виникають запитання:

• чи може працівник одного регіону бачити клієнта іншого;
• хто бачить фінансові показники;
• хто може редагувати картку;
• хто може експортувати інформацію;
• хто бачить документи;
• що відбувається після зміни відповідального;
• які права отримує тимчасовий керівник;
• чи потрібно обмежувати доступ до окремих полів.

Чим складніша організаційна структура, тим більше часу займає не тільки налаштування, а й тестування.

Помилка у кольорі кнопки неприємна.

Помилка у правах доступу може відкрити комерційні дані не тому користувачу.

Тому такі блоки потребують окремої уваги.

Аналітика — це не просто «додати дашборд»

Запит «нам потрібна аналітика» може означати кілька графіків із кількістю угод.

А може означати управлінську систему показників.

Керівник хоче бачити:

• план і факт продажів;
• прогноз до кінця місяця;
• конверсію між етапами;
• середню тривалість угоди;
• причини втрат;
• прострочені активності;
• ефективність менеджерів;
• продажі за продуктами;
• продажі за регіонами;
• повторні покупки;
• динаміку клієнтської бази.

Щоб побудувати звіт, CRM повинна мати структуровані дані.

Якщо компанія хоче бачити причини програшу угод, менеджери мають їх фіксувати.
Якщо потрібна маржинальність, система має отримувати собівартість.
Якщо потрібен план-факт, десь повинні зберігатися плани.

Тому складна аналітика нерідко починається не зі звітів, а з перебудови процесу збору даних.

Міграція старої бази може коштувати дорожче за її імпорт

Імпортувати таблицю з тисячею контактів можна доволі швидко.

Мігрувати десять років роботи компанії — зовсім інше завдання.

У старій CRM можуть бути:

• клієнти;
• контакти;
• угоди;
• завдання;
• дзвінки;
• листи;
• товари;
• рахунки;
• файли;
• коментарі;
• нестандартні поля;
• дублікати.

Потрібно зрозуміти, що переносити, а що залишити в архіві.

Дані доводиться очищувати, зіставляти поля старої та нової систем, перевіряти зв’язки між сутностями.

Окреме питання — якість інформації.

У старій базі одна компанія може бути записана трьома способами. Телефони мають різний формат. Частина клієнтів не має відповідального. Старі статуси більше не використовуються.

CRM не виправить такі проблеми автоматично.

Тому бюджет міграції залежить не тільки від кількості записів, а й від структури та якості даних.

€ 5000 і € 30 000 можуть бути двома чесними оцінками

Уявімо два проєкти. Обидві компанії формулюють завдання однаково: «CRM для відділу продажів».

Проєкт А

Компанії потрібні:

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

Більшість функцій уже є у CRM. Основна робота інтегратора — конфігурація та запуск.

Проєкт B

Компанії потрібні:

• кілька напрямів продажу;
• складна рольова модель;
• інтеграція з ERP;
• інтеграція з телефонією;
• автоматичний розподіл лідів;
• погодження комерційних умов;
• план-факт;
• контроль прострочень;
• товарний асортимент;
• управлінська аналітика;
• дашборди;
• автоматичні сценарії;
• міграція історичної бази;
• навчання різних груп користувачів.

Це вже не налаштування CRM. Це проєкт автоматизації частини компанії.

Тому різниця бюджету у п’ять або десять разів не обов’язково означає, що один інтегратор дорожчий за іншого.

Вони можуть рахувати різний результат.

Чому низька стартова оцінка інколи перестає бути низькою

Є два способи оцінити проєкт.

Перший — рахувати тільки те, що вже точно сформульовано.
Другий — спочатку розібрати процеси й визначити повний обсяг робіт.

У першому випадку початкова цифра майже завжди є привабливішою.

Потім у процесі роботи з’являються уточнення: «Це теж потрібно». «Без цього менеджери не зможуть працювати». «Ми думали, що інтеграція це вже включає». «А звіту тут не буде?»

Так з’являються додаткові бюджети.

Це не завжди означає, що постачальник навмисно занизив ціну. Іноді замовник і виконавець просто по-різному зрозуміли межі проєкту.

Тому перед порівнянням варто дивитися не на загальну суму, а на те, що в неї входить.

Як правильно порівнювати пропозиції інтеграторів

Комерційні пропозиції на CRM-проєкт можуть мати такий вигляд:

• інтегратор А — € 8000;
• інтегратор B — € 15 000;
• інтегратор C — € 25 000.

Із цих трьох цифр неможливо зробити висновок.

Потрібно порівняти склад робіт.
Поставте кожному постачальнику однакові запитання.

Що входить у базову ціну

Чи передбачена сама CRM-платформа? Чи вміщено налаштування?Чи входить міграція та навчання? Чи передбачено тестування?

Як оцінюються інтеграції

Попросіть описати не тільки назву інтеграції, а й функції.

Не «інтеграція з ERP», а конкретно:

• передача клієнтів;
• синхронізація товарів;
• передача залишків;
• створення замовлень;
• отримання оплат.

Тоді пропозиції можна порівнювати.

Що вважається доопрацюванням

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

Усі три підходи допустимі, якщо замовник розуміє межі бюджету.

Які припущення закладені в оцінку

Корисне запитання: «За яких умов ця оцінка залишиться незмінною?»

Так швидко з’ясується, що міграція розрахована на один файл Excel, інтеграція — лише в один бік, а звітність — на стандартних даних CRM.

Саме ці деталі формують реальну вартість впровадження CRM.

Чи можна точно оцінити CRM до початку проєкту

Невеликий типовий проєкт оцінити нескладно. Для великого індивідуального впровадження точність залежить від рівня деталізації вимог.

Фраза «автоматизувати продажі» не дає змоги скласти точний бюджет.
Опис процесу «від заявки до оплати» вже дає значно більше інформації.

Ще точніше, коли визначені:

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

Тому складні проєкти доцільно розподіляти на етапи.

Спочатку — аналіз. Потім — проєктування та оцінка. Після цього — реалізація.

Такий підхід не робить проєкт дешевшим. Він робить бюджет зрозумілішим.

Автоматизація винятків часто складніша за основний сценарій

У презентації майже будь-який процес нагадує послідовність із кількох кроків: отримали заявку, створили угоду, підготували пропозицію, погодили умови, отримали оплату. Така схема добре описує типовий сценарій, але реальна робота компанії рідко складається лише з типових випадків.

Під час обстеження з’являються винятки. Один клієнт працює за передоплатою, інший — з відстроченням. Для окремої категорії товарів потрібне погодження технічного спеціаліста. Якщо сума договору перевищує встановлений ліміт, документ має погодити директор. Для ключового клієнта діє інший маршрут. Якщо менеджер відсутній, завдання переходить його керівнику.

Кожен такий виняток перетворюється на правило, яке потрібно описати, реалізувати та перевірити. Саме тому десять етапів процесу ще не означають десять простих налаштувань.

Під час оцінки корисно розподіляти основний сценарій і винятки. Основний сценарій показує, як працює більшість угод. Винятки показують реальну складність автоматизації.

Якщо винятків небагато, частину з них можна залишити як ручні дії на першому етапі. Якщо вони повторюються щодня та впливають на гроші, строки або якість роботи, їх варто додати в автоматизацію.

Цей підхід також допомагає контролювати бюджет: компанія бачить, які правила критичні для запуску, а які можна реалізувати після того, як основний процес стабільно працює.

Тестування та запуск — це частина впровадження, а не завершальний формальний етап

Коли функція вже розроблена, робота над нею не закінчується. Її потрібно перевірити на реальних сценаріях: з правильними даними, помилковими даними, різними правами доступу та нетиповими діями користувача.

Чим більше систем пов’язано з CRM, тим більше сценаріїв потрібно протестувати. Передача замовлення з CRM до ERP може працювати у стандартному випадку, але що станеться, якщо товар видалений, клієнт заблокований у бухгалтерській системі або ERP тимчасово недоступна?

Окремо перевіряють ролі користувачів. Адміністратор може успішно виконати операцію, а менеджер — не мати потрібного доступу. Або навпаки: отримати доступ до інформації, яку не повинен бачити.

Перед промисловим запуском корисно провести приймальне тестування разом із представниками бізнесу. Вони проходять ключові сценарії так, як працюватимуть після запуску, і фіксують відхилення.

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

Якщо ці роботи відсутні в одному комерційному пропонуванні та вміщені в іншому, дві ціни не можна порівнювати напряму. У другому випадку постачальник продає не тільки налаштування, а й доведення системи до робочого стану.

Навчання залежить від ролей, а не тільки від кількості користувачів

Навчити десять менеджерів працювати з однією воронкою простіше, ніж підготувати кілька груп користувачів із різними ролями.

Менеджеру потрібні клієнти, угоди, завдання та комунікації. Керівнику — контроль команди, звіти та прогноз. Адміністратору — налаштування користувачів, довідників, полів і правил. Працівнику фінансового відділу може бути потрібна тільки частина даних, пов’язана з рахунками та оплатами.

Тому в складному проєкті навчання доцільно будувати за ролями. Це скорочує кількість зайвої інформації для кожної групи й допомагає швидше перейти до роботи.

Вартість навчання також залежить від того, що має залишитися після нього. Одна справа — провести онлайн-зустріч. Інша — підготувати інструкції, записи, навчальний стенд і навчити внутрішнього адміністратора, який надалі підтримуватиме користувачів.

Для компанії це важливо враховувати у кошторисі: система, якою команда не вміє користуватися, не дає очікуваного результату незалежно від якості розробки.

Підтримка після запуску теж впливає на повну вартість

Після запуску починається період, коли користувачі працюють із системою щодня. Саме тоді стають помітними дрібні незручності, які неможливо передбачити під час опису вимог.

Частина звернень стосується помилок. Частина — нових побажань. Частина виникає тому, що бізнес змінив правило вже після запуску.

У різних пропозиціях підтримка може бути організована по-різному: певна кількість годин входить у проєкт, діє окремий щомісячний пакет або всі роботи оплачуються за фактом.

Тому під час порівняння бюджету варто дивитися не тільки на суму до дати запуску. Потрібно зрозуміти, що відбувається після неї: хто приймає звернення, які строки реакції, чи входять оновлення, як оцінюються нові доопрацювання.

Це особливо важливо для систем, які компанія планує розвивати роками. CRM змінюється разом із продуктами, структурою продажів, звітністю та інтеграціями. Витрати на розвиток стають частиною її життєвого циклу.

Як читати кошторис CRM-проєкту

Корисний кошторис не обов’язково містить сотні рядків. Але з нього має бути зрозуміло, що саме отримає компанія за зазначену суму.

Добре, коли роботи розподілені хоча б на великі блоки: аналіз, конфігурація, інтеграції, розробка, міграція, тестування, навчання та запуск. Для складних блоків потрібен короткий опис результату.

Фраза «інтеграція — € 3000» майже нічого не пояснює. Формулювання «двосторонній обмін клієнтами та замовленнями, одностороннє отримання оплат і залишків» уже дає змогу зрозуміти межі робіт.

Так само варто звернути увагу на те, що не входить у суму. Якщо замовник сам готує дані до міграції, це має бути зафіксовано. Якщо доступ до API сторонньої системи оплачується окремо, про це краще знати до старту.

Ще один важливий параметр — спосіб оцінки змін. Після початку великого проєкту нові вимоги майже неминучі. Компанія має розуміти, як вони погоджуються, оцінюються та впливають на строки.

Такий кошторис допомагає не тільки обрати постачальника. Він стає основою для контролю проєкту: замовник бачить, який блок зараз виконується, що вже прийнято і за що сплачено.

Окремо варто узгодити критерії приймання. Для кожного великого блоку має бути зрозуміло, за якою ознакою замовник вважає роботу завершеною. Для інтеграції це може бути успішна передача визначених типів даних, для звіту — набір показників і фільтрів, для міграції — кількість перенесених сутностей та перевірка вибірки.

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

Тому повна ціна проєкту — це не тільки години програмістів. Це ще й аналітика, управління змінами, контроль якості та відповідальність за перехід системи у щоденну роботу.

Як зменшити вартість CRM-проєкту без втрати результату

Економія не обов’язково означає відмову від потрібних функцій.
Частину бюджету можна зменшити завдяки правильній послідовності робіт.

Запускайте систему етапами

Не всі функції потрібні в перший день.

На старті можна запустити:

• клієнтську базу;
• воронку продажів;
• комунікації;
• завдання;
• основні звіти.

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

Використовуйте готовий функціонал

Якщо стандартний механізм CRM закриває завдання на 80–90%, варто оцінити, чи виправдана розробка окремого рішення заради решти. Кожна індивідуальна функція потребує не тільки створення, а й подальшої підтримки.

Автоматизуйте стабільні процеси

Немає сенсу програмувати процес, який компанія змінює щомісяця. Спочатку краще домовитися, як команда працює. Потім переносити це правило в CRM.

Не переносьте непотрібні дані

Стара система може містити десятирічну історію, яку ніхто не використовує. Іноді достатньо перенести активних клієнтів та поточні угоди, а стару CRM залишити як архів.
Це рішення може суттєво скоротити роботу з міграцією.

Де тут місце самої CRM-платформи

Платформа визначає, скільки функціоналу доведеться створювати з нуля.

Що більше потрібних механізмів уже є у продукті, то менше індивідуальної розробки потребує проєкт.

Водночас для середнього та великого бізнесу важливі не тільки стандартні модулі.

Важливо, чи CRM дає змогу:

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

Саме тому ми розвиваємо Aduqa CRM як платформу, у якій значну частину бізнес-логіки можна конфігурувати, а специфічні сценарії — розробляти окремо.

Такий підхід дає змогу розподілити вартість готового продукту та вартість робіт під конкретну компанію.

Це важливо і для оцінки проєкту, і для його подальшого розвитку.

Чекліст перед запитом вартості CRM

Щоб отримати від інтеграторів порівнювані оцінки, підготуйте відповіді на десять запитань.

1. Скільки користувачів працюватиме в CRM?
2. Які відділи використовуватимуть систему?
3. Які процеси потрібно автоматизувати?
4. Скільки різних воронок або сценаріїв роботи є в компанії?
5. З якими системами потрібні інтеграції?
6. Які дані потрібно перенести?
7. Які звіти потрібні керівництву?
8. Які правила доступу діють у компанії?
9. Які операції потрібно автоматизувати?
10. Який функціонал обов’язковий для першого запуску, а що можна перенести на наступний етап?

Цього ще недостатньо для технічного завдання. Але достатньо, щоб розмова про бюджет стала предметною.

Головне — порівнювати не ціну, а результат

У CRM-проєкті немає універсальної ціни за «автоматизацію продажів».

Одна компанія отримує потрібний результат після налаштування стандартної системи.

Іншій потрібні інтеграції, аналітика, складні права, кілька процесів та індивідуальна розробка.

Тому ціна CRM сама собою мало говорить про бюджет впровадження.

Перед вибором постачальника варто відповісти на три запитання:

• який результат має отримати бізнес;
• які роботи входять у запропоновану суму;
• що оплачуватиметься окремо.

Якщо дві пропозиції відрізняються у п’ять разів, це привід не шукати одразу «занадто дорогу» або «підозріло дешеву», а розкласти обидві оцінки на складники.

У більшості випадків причина різниці знаходиться саме там.

Побачити, як формується вартість продукту та окремих робіт у нашій моделі впровадження, можна на сторінці вартості Aduqa CRM.