Власна CRM або готовий продукт: як бізнесу зробити правильний вибір

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

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

Коли саморобне рішення доречне

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

У мене був такий кейс ще до NetHunt CRM. Паралельно з основною роботою я брав фриланс-замовлення на Upwork та інших біржах. Тоді ще не було сучасних AI-інструментів, щоб за вечір зібрати собі CRM, тому я зробив максимально просту зв’язку і об‘єднав багато вхідних джерел в один інтегромат і в Google-таблицю таблицю. При появі в ній нової строки телеграм бот надсилав мені сповіщення в канал, де я оперативно бачив інформацію по запиту.  

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

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

Як зрозуміти, що команді час переходити на готовий продукт

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

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

Падіння швидкості

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

Втрата стабільності

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

Відставання від оновлень

WhatsApp і Telegram оновлюють свої API, з’являються нові протоколи безпеки. У готовій CRM розробники адаптують систему до цих змін, часто непомітно для користувачів. Із самописною збіркою ситуація інша: компанія може дізнатися про оновлення лише тоді, коли інтеграція перестане працювати. Повідомлення від клієнтів приходять на телефон, а відповісти на них із самописної CRM вже неможливо.

Підписуйтеся на наші соцмережі

Залежність від однієї людини

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

Яких помилок припускається бізнес, коли обирає готову CRM

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

Немає відповіді на запитання «навіщо?»

Керівник подивився вебінар про автоматизацію і наступного ранку каже: «Нам потрібна CRM». А далі хтось іде шукати систему, не розуміючи, яку проблему вона має розв’язати.

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

Купити CRM і працювати в таблицях

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

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

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

Вибір CRM доручили не тій людині

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

Набагато корисніше ставити конкретні запитання:

Відповідь «Є месенджери» ще не означає, що серед них буде Signal. Так само зі звітністю. Запит «Нам потрібна наскрізна аналітика» мало що дає, бо за ним можуть стояти десятки різних показників. Потрібно розуміти, які цифри команда хоче бачити і для ухвалення яких рішень.

Не протестувати продукт

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

Команда не бачить цінності CRM

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

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

Зрештою співробітник звільнився. Компанія залишилася без нормально налаштованої системи і повернулася з питанням: що тепер робити?

Неперевірений інтегратор

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

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

Поспіх із впровадженням CRM

Компанії звертаються із запитом «Нам потрібна CRM на вчора». Наприклад, керівник доручає співробітнику підібрати систему, але протягом місяця процес майже не рухається. А потім посеред тижня з’являється складне технічне завдання з десятками вимог, яке потрібно реалізувати буквально за два дні.

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

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

Код тут не найбільша проблема. Його можна прочитати. Втрачається розуміння, чому все зроблено саме так. Чому заявка йде в цей відділ, чому тут така формула, чому статус змінюється на цьому кроці. Це вже бізнес-процеси компанії, перекладені мовою системи. І коли людина йде, вона може забрати із собою це розуміння.

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

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

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

Є просте запитання: якщо завтра людина, яка все це побудувала, перестане відповідати, хто розбереться в системі післязавтра? Якщо відповідь — ніхто, ризик у моделі її підтримки.