Своя CRM для сервісного центру: коли готова не підходить і що виявилось складним
Клієнт приходить із запитом «зробіть нам CRM» приблизно раз на місяць. Майже завжди правильна відповідь — не робити, а взяти готову. Але приблизно в одному випадку з десяти готова не підходить, і тоді треба чесно розуміти, у що ви заходите. Розповімо на прикладі системи, яку ми довели до продакшену: вона щодня працює у двох сервісних центрах.
Коли готова CRM не підходить
Ринок готових рішень для сервісних центрів в Україні закритий: є RO App (колишній RemOnline), є Gincore, є десяток дрібніших. Це зрілі продукти, і в дев’яти випадках із десяти правильний хід — заплатити абонплату й не витрачати півроку на розробку.
Своя система має сенс за трьох умов одночасно. Загальні причини, чому бізнес узагалі приходить до власної CRM, ми розбирали окремо — для чого створювати власну CRM; тут — про конкретний випадок.
Перше: у процесі є щось, чого в готових немає в принципі. Не «незручно», а «немає». У нашому випадку це приймання техніки поштою. Поштове замовлення — інший процес: інша логіка узгодження ремонту до початку робіт, інша ставка майстру за таке замовлення, інша комунікація з клієнтом, який не може зайти й спитати. Це не налаштовується галочкою, це інша модель даних.
Друге: бізнес готовий бути замовником, а не глядачем. Найдорожче в такому проєкті — не код, а вимоги. Якщо власник не сидить у процесі щодня, ви отримаєте систему, у якій усе технічно працює, і якою ніхто не користується.
Третє: горизонт довший за рік. Своя система — це не проєкт, а зобов’язання. Її треба буде підтримувати, коли зміниться законодавство щодо фіскалізації, коли постачальник SMS-шлюзу підніме ціни, коли з’явиться другий філіал.
Якщо хоч одна умова не виконується — беріть готову.
Що виявилося складним насправді
Технічно CRM для сервісу — не rocket science. Складність в іншому.
Собівартість запчастини. Здається дрібницею, поки не з’ясується, що та сама клавіатура куплена тричі за різною ціною. Середньозважена собівартість, яка перераховується при кожному приході й списується при видачі деталі в замовлення, — це те, заради чого система взагалі рахує маржу. Без цього звіт про прибуток є, але він художній.
Одне джерело правди для чисел. Найпоширеніша хвороба саморобних систем: виручка на дашборді рахується одним запитом, у звіті — іншим, і одного дня вони розходяться. Ми зробили так, що зведення читає ті самі журнали, у які пише решта системи. Жодне число не має власної копії.
Права доступу. «Майстер бачить тільки свої замовлення» — це не одна галочка. Видати запчастину, оприбуткувати, списати — різні дозволи, і вмикатися вони мають з інтерфейсу, а не зверненням до розробника, інакше ви станете вузьким місцем назавжди.
Публічна сторінка статусу. Клієнт відкриває посилання й бачить, що з його пристроєм. Проєктувати її треба з припущенням, що посилання перешлють далі: ані цін, ані внутрішніх коментарів, ані коду розблокування там бути не може. Це рівно та деталь, яку в саморобках забувають.
Фіскалізація — окрема історія
Це найнедооціненіша частина. ФОП, який приймає оплату за послуги готівкою або карткою, зобов’язаний видати розрахунковий документ, і система обліку, яка цього не вміє, змушує касира працювати у двох вікнах.
Ми підключаємо Checkbox: чек видається з системи, а посилання на нього автоматично потрапляє в електронну квитанцію клієнта. Досвід тут у нас із суміжних проєктів — фіскалізацію платежів ми вже робили у вендингових і паркувальних рішеннях, де чек треба видати без касира взагалі. Дотично про цю ж інженерію — розбір, як інтегрувати платіжні системи на сайт.
Скільки це коштує і скільки триває
Чесна відповідь: значно довше, ніж здається на старті, і майже завжди дорожче за кілька років абонплати за готову систему. Перша працездатна версія — місяці, а не тижні. Далі система не «здається», а живе: у ній щотижня щось уточнюється під реальні кейси.
Тому питання «скільки коштує розробити CRM» майже завжди неправильне. Правильне — «що конкретно ми не можемо зробити в готовій». Якщо на нього немає відповіді на два абзаци з конкретикою, розробку замовляти рано.
Чим це закінчилося
Систему довели до стану, у якому нею користуються щодня: замовлення від прийому до видачі, склад із реальною собівартістю, каса по формах оплати, зарплата майстра від виконаних робіт, SMS клієнту, звіти. Далі вона переросла внутрішню задачу й стала окремим продуктом — КМІТ: на старті безкоштовний, далі — символічна абонплата.
Для нас це найкорисніший тип кейсу: продукт, який ми не здали й забули, а супроводжуємо і бачимо, як він поводиться під навантаженням реального бізнесу.
Якщо ви думаєте про свою систему
Напишіть, що саме не виходить зробити в готовій. Якщо виявиться, що виходить, — так і скажемо, це чесніше й дешевше для всіх. Якщо ні — порахуємо обсяг і скажемо реальний строк, а не бажаний.
Написати можна в Telegram або зателефонувати: 096 000 76 03.
