Rozmowa o własnym CRM zaczyna się prawie zawsze tak samo. Firma ma system z abonamentem, płaci za niego od kilku lat, a obok trzyma arkusz, w którym dzieje się prawdziwa praca. W CRM są kontakty i etapy. W arkuszu terminy, kwoty, zaliczki i notatki, kto z kim o czym rozmawiał. Ktoś w końcu pyta, czy nie dałoby się zbudować czegoś własnego.
Najczęściej odpowiadam, że nie teraz. Gotowy CRM z porządnie ustawionym procesem i kilkoma automatyzacjami wokół załatwia sprawę taniej niż cokolwiek pisane od zera. Ale zdarzają się firmy, w których pudełko naprawdę przestaje wystarczać, i wtedy trzymanie się go kosztuje więcej niż budowa. Poniżej: jak rozpoznać jedną sytuację i drugą oraz gdzie leży największe ryzyko.
TL;DR: Własny CRM ma sens wtedy, gdy model danych Twojej firmy nie mieści się w modelu gotowego systemu, a nie wtedy, gdy brakuje kilku pól albo abonament wydaje się drogi. Zanim zbudujesz, wyciśnij konfigurację i automatyzacje wokół pudełka. Jeśli po tym proces nadal żyje w arkuszu, wtedy warto rozmawiać o budowie.
Pięć sygnałów, że gotowy CRM uwiera
Żaden z nich osobno nie jest powodem do budowy. Trzy albo cztery naraz oznaczają, że warto policzyć.
Pola na siłę. W systemie jest „Pole tekstowe 3" na datę wyjazdu i „Notatka 2" na numer polisy. Nikt już nie pamięta, co znaczy „Tak/Nie" w polu o nazwie skróconej do sześciu znaków. Pierwszy objaw tego, że rzeczywistość firmy nie ma gdzie usiąść.
Proces żyje obok systemu. CRM jest wypełniany po fakcie, a decyzje zapadają w arkuszu albo w głowie jednej osoby. Zespół nie sabotuje wdrożenia. Robi robotę tam, gdzie da się ją zrobić.
Eksport do Excela, „bo się nie da". Rozliczenie prowizji, zestawienie zaległości, raport dla właściciela: wszystko przez pobranie CSV i sklejanie w arkuszu. Jeżeli ten sam eksport powtarza się co miesiąc od dwóch lat, to nie wyjątek, tylko brakująca funkcja.
Koszt za użytkownika przestaje mieć związek z korzyścią. Osoba zaglądająca do CRM raz w tygodniu kosztuje tyle samo co handlowiec siedzący w nim po osiem godzin. Do tego dodatki płatne osobno.
Integracje kończą się na „prawie". Telefonia, którą da się podpiąć, ale bez powiązania rozmowy z rezerwacją. Faktury, które wychodzą, ale nie te prowizyjne. Płatności bez rozbicia na raty uczestników.
| Sygnał | Co zrobić, zanim uznasz, że trzeba budować |
|---|---|
| Pola na siłę | Sprawdź, czy brakujący obiekt da się dołożyć jako osobną tabelę |
| Proces obok systemu | Zmapuj proces, przebuduj etapy, potem oceniaj narzędzie |
| Stały eksport do Excela | Zbuduj raport poza CRM, na danych z API |
| Rosnący koszt za użytkownika | Podziel role, część osób na dostęp tylko do odczytu |
| Integracje „prawie" | Sprawdź API, zanim uznasz sprawę za przegraną |
Czego nie robić: własny CRM nie jest punktem startu
Najdroższe wdrożenia, jakie widziałem, zaczynały się od zdania „żaden gotowy CRM nam nie pasuje", wypowiedzianego przez firmę bez opisanego procesu sprzedaży. System szyty na miarę odwzorowuje wtedy bałagan, tyle że za kilkadziesiąt tysięcy złotych i bez pomocy technicznej.
Trzy powody, dla których nie warto budować:
- Żeby oszczędzić na abonamencie. Przy zespole kilkunastu osób punkt wyrównania kosztów leży tak daleko, że w praktyce nie nastąpi.
- Bo zespół nie chce uzupełniać danych. Nowy interfejs nie zmieni tego, że nikt nie rozumie, po co wypełnia pole.
- Bo gotowy system jest niewygodny. Niewygodę zwykle usuwa konfiguracja, ukrycie połowy pól i automatyzacja, która wypełni resztę za człowieka.
Kolejność, którą polecam każdemu: opisany proces, gotowy CRM ustawiony pod ten proces, automatyzacje wokół niego, a rozmowa o własnym systemie na końcu. Nie masz pierwszego kroku? Zacznij od oceny, czy w ogóle potrzebujesz CRM. Klikacie ręcznie rzeczy, które powinny dziać się same? Zobacz dziesięć gotowych workflow na przykładzie Pipedrive. Bardzo często temat budowy zamyka się na tym etapie.
Co musi być prawdą, żeby custom się opłacił
Sześć warunków, które sprawdzam przed każdą taką decyzją.
- Model danych firmy nie mieści się w modelu pudełka. Nie chodzi o brakujące pola, tylko o obiekty i relacje. Gotowe CRM-y zakładają, że świat składa się z firm, osób, szans sprzedaży i zadań. Jeśli centralnym obiektem jest u Ciebie rezerwacja z wieloma uczestnikami, konfiguracja tego nie naprawi.
- Proces jest źródłem przewagi, nie kosztem. Robicie coś inaczej niż konkurencja i dlatego klienci wybierają Was? Wtedy warto mieć własne narzędzie. Proces typowy obsłuż typowym systemem.
- Jest właściciel systemu po stronie firmy. Jedna osoba decydująca o zakresie. Bez niej budowa zamienia się w zbieranie życzeń od wszystkich działów.
- Dane, które i tak zbieracie, opłaca się scalić. Sprzedaż w CRM, płatności w arkuszu, dokumenty na dysku, rozmowy w telefonie. Wartość bierze się nie z nowych funkcji, tylko z tego, że wszystko wreszcie stoi w jednym miejscu.
- Budżet obejmuje utrzymanie, a nie samą budowę. System bez kogoś, kto go poprawia, po roku rozjeżdża się z firmą.
- Umiesz wskazać rzeczy, których pudełko nie zrobi ani po konfiguracji, ani po automatyzacji dookoła. Najostrzejszy test. Jeśli po dwóch dniach z dobrym wdrożeniowcem lista topnieje do trzech pozycji, budowa nie ma sensu.
Cztery spełnione z sześciu i rozmowa o budowie jest uczciwa. Przy dwóch zostań przy pudełku i wydaj pieniądze na porządną konfigurację.
„Własny CRM prawie nigdy nie wygrywa funkcjami, bo gotowe systemy mają ich więcej i lepiej dopracowane. Wygrywa tym, że jego model danych wygląda dokładnie tak jak firma. Jeżeli klient nie potrafi mi narysować tego modelu na kartce, to znaczy, że jeszcze nie jest gotowy budować." — Mikołaj Brunka, założyciel NoCodeWork
Dwa przykłady z naszych wdrożeń
Dwa systemy, które zbudowaliśmy zamiast gotowych narzędzi. Opisuję je bez nazw, ale z tym, co przesądziło o decyzji.
Biuro podróży, które odeszło od branżowego systemu. Firma korzystała z gotowego oprogramowania dla agencji turystycznych i utknęła na jego modelu danych. Rezerwacja nie jest szansą sprzedaży: ma uczestników, terminy, powiązanie z ofertą operatora i własne życie długo po sprzedaży. Rozliczenie jest trzystronne, bo pieniądze płyną między klientem, biurem i touroperatorem, a biuro zarabia na prowizji, którą trzeba osobno zafakturować. Do tego oddziały z własnymi wynikami, rezerwacje grupowe, telefonia i SMS-y wpięte w kartotekę, żeby historia rozmowy siedziała przy rezerwacji, oraz generowanie umów z pomocą AI na danych już wprowadzonych do systemu. Powód odejścia od pudełka nie brzmiał „brakuje nam funkcji", tylko „nasz proces nie mieści się w cudzym modelu danych".
Firma szkoleniowa, która wyrosła z Excela i maili. Zapisy szły przez formularz i skrzynkę, płatności notowano w arkuszu, dostępy do nagrań wysyłano ręcznie. Przy setkach kursantów przestało to działać. Zbudowaliśmy system, w którym zapis, harmonogram płatności i dostęp do materiałów są jednym obiegiem: rata ustalana indywidualnie dla uczestnika, tabela zaległości pokazująca w jednym widoku, kto i ile zalega, biblioteka nagrań z dostępem na token i znakiem wodnym identyfikującym oglądającego, do tego automatyczna wysyłka dostępów przez komunikator używany przez kursantów na co dzień. Zadecydowała skala oraz to, że produktem jest sam dostęp do materiałów, więc kontrola nad nim musiała siedzieć obok informacji o płatnościach.
W obu przypadkach system przestał być listą kontaktów z etapami. Stał się miejscem, w którym firma prowadzi główną operację, razem z pieniędzmi i dokumentami. Gotowy CRM tego nie obiecuje i nie powinien.
Jak wygląda budowa: discovery, model danych, MVP, iteracje
Discovery to rozmowa nie o funkcjach, tylko o procesie i danych: kto co robi, w jakiej kolejności, gdzie zapisuje wynik i co się psuje. Chcesz przyjść przygotowany? Zacznij od mapowania procesów.
Model danych to etap, którego błędy naprawdę bolą później. Zła decyzja o tym, czy rata należy do rezerwacji, czy do uczestnika, potrafi za pół roku kosztować przepisanie połowy systemu.
MVP obejmuje jeden proces przeprowadzony od początku do końca, a nie dwadzieścia procent każdej funkcji. Po kilku tygodniach zespół realnie pracuje w nowym systemie na jednym wycinku, zamiast oglądać makiety. Widełki rozpisaliśmy w tekście o tym, ile kosztuje zbudowanie MVP aplikacji.
Iteracje i migracja to krótkie cykle zamykane czymś, co wchodzi na produkcję. Uwagi od ludzi, którzy już w tym pracują, są warte więcej niż lista życzeń sprzed startu. Stary system pozostaje włączony, dopóki nowy nie obsłuży pełnego okresu rozliczeniowego bez awarii.
| Etap | Typowy czas | Najczęstszy błąd |
|---|---|---|
| Discovery | 1–2 tygodnie | Rozmowa o funkcjach zamiast o danych |
| Model danych | kilka dni | Układ arkusza skopiowany jeden do jednego |
| MVP | 4–8 tygodni | Zakres rozdmuchany do pełnej wizji |
| Iteracje | cykle 2–4 tygodni | Brak właściciela ustalającego priorytety |
| Migracja | 1–3 tygodnie | Zaplanowana na ostatni dzień projektu |
Koszty: abonament kontra budowa i utrzymanie
Abonament jest wygodny, bo widać go w jednej pozycji na fakturze. Własny system ma inny rozkład: duży wydatek na starcie, mniejszy i stały później. Na utrzymanie składają się cztery rzeczy: hosting z bazą, opieka techniczna (aktualizacje, kopie zapasowe, monitoring), poprawki błędów i rozwój, czyli nowe rzeczy dokładane w miarę zmian w firmie. O tej ostatniej pozycji zapomina się najczęściej, a to ona decyduje, czy system za trzy lata nadal będzie używany.
| Gotowy CRM | Własny system | |
|---|---|---|
| Start | dni, koszt konfiguracji | tygodnie, koszt budowy |
| Koszt bieżący | za użytkownika, rośnie z zespołem | hosting plus opieka, niemal niezależne od liczby osób |
| Zmiana procesu | w granicach tego, co przewidział producent | dowolna, ale za każdym razem płatna |
| Ryzyko | zmiana cennika lub polityki dostawcy | zależność od wykonawcy |
| Wsparcie | dokumentacja, społeczność, producent | tylko to, co ustalisz w umowie |
Nie liczyłbym tego jako „za ile miesięcy budowa zwróci się w oszczędności na licencjach". Ta rachuba prawie zawsze wychodzi na niekorzyść własnego systemu. Liczy się co innego: ile kosztuje Was dzisiaj to, czego pudełko nie robi. Godziny na sklejanie raportów, pomyłki w rozliczeniach, płatności wyłapane po terminie. Te liczby da się zebrać w tydzień i to one przesądzają. Szerzej o tym rachunku piszemy w porównaniu wad własnej aplikacji i gotowego narzędzia. A jeśli Twój problem to bardziej arkusze niż CRM, zobacz, czym zbudować aplikację wewnętrzną zamiast Excela.
Ryzyka i jak się przed nimi zabezpieczyć
Największe ryzyko to uzależnienie od wykonawcy. Przy gotowym CRM w najgorszym razie zmieniasz dostawcę i eksportujesz dane. Przy własnym systemie firma, która go zbudowała, ma kod, dostępy i wiedzę o tym, jak to działa. Jeśli przestanie odbierać telefon, zostajesz z systemem, którego nikt nie umie zmienić.
Cztery rzeczy załatwiają większość tego ryzyka i wszystkie ustala się przed startem:
- Repozytorium po Twojej stronie od pierwszego dnia. Konto organizacji zakładane na firmę klienta, wykonawca dostaje do niego dostęp. Nie „przekażemy kod po zakończeniu", tylko kod od początku leży u Ciebie.
- Infrastruktura i konta na firmę. Serwer, domena, baza, usługi zewnętrzne i klucze API opłacane z firmowej karty. Konto na prywatnym mailu wykonawcy to najczęstszy powód bolesnych rozstań.
- Dokumentacja jako warunek odbioru. Opis modelu danych, instrukcja uruchomienia środowiska, lista integracji. Ma pozwolić innemu programiście wejść w projekt.
- Plan wyjścia w umowie. Zapisany zakres i stawka za przekazanie projektu innemu wykonawcy. Sama gotowość do wpisania takiego punktu mówi o firmie więcej niż całe portfolio.
Pilnuj też, żeby stack był standardowy, a nie autorski. Typowa baza i popularny framework oznaczają, że projekt może przejąć wielu ludzi. „Nasze własne" rozwiązanie, którego nikt poza wykonawcą nie zna, jest formą zamknięcia drzwi.
Te zapisy w wersji rozpisanej znajdziesz w tekście o tym, co musi zawierać umowa na automatyzację. Ten sam zestaw stosuje się do budowy systemu. Jeśli już masz odziedziczony projekt, pomoże instrukcja przejęcia po poprzednim wykonawcy.
Do pilnowania zostają jeszcze trzy rzeczy: funkcje zamawiane „na wszelki wypadek", z których potem nikt nie korzysta; odejście osoby znającej uzasadnienie połowy decyzji; obowiązki wokół danych osobowych, bo przy własnym systemie spadają na Ciebie, a nie na dostawcę SaaS.
FAQ
Kiedy własny CRM opłaca się bardziej niż gotowy?
Wtedy, gdy model danych firmy nie mieści się w modelu gotowego systemu: centralnym obiektem jest u Was rezerwacja, edycja kursu albo zlecenie z własnym cyklem życia, a nie szansa sprzedaży. Drugi warunek to proces będący źródłem przewagi konkurencyjnej. Jeśli chodzi o brakujące pola, koszt licencji albo niewygodny interfejs, gotowy CRM z dobrą konfiguracją wyjdzie taniej i szybciej.
Ile kosztuje zbudowanie własnego CRM?
Zależy od zakresu i technologii. Systemy na narzędziach no-code zaczynają się w okolicach kilkunastu tysięcy złotych, podejście low-code mieści się zwykle między kilkunastoma a czterdziestoma tysiącami, a system pisany kodem, z integracjami płatności i dokumentów, startuje od kilkudziesięciu tysięcy w górę. Do tego utrzymanie: hosting, kopie zapasowe, poprawki i rozwój. Budżet bez tej pozycji jest niepełny.
Jak długo trwa budowa customowego CRM?
Do pierwszej działającej wersji obsługującej jeden proces od początku do końca zwykle około dwóch miesięcy: discovery, model danych i MVP. Pełne zastąpienie starego systemu, z migracją i pracą równoległą przez jeden okres rozliczeniowy, zajmuje od trzech do sześciu miesięcy. Projekty ciągnące się dłużej miały zwykle rozdmuchany zakres MVP.
Co zrobić, żeby nie uzależnić się od wykonawcy własnego systemu?
Załóż repozytorium na swoją organizację i daj wykonawcy dostęp, zamiast czekać na przekazanie kodu po odbiorze. Zarejestruj infrastrukturę, domeny i konta usług na firmę. Wpisz dokumentację jako warunek odbioru, a plan wyjścia ze stawką za przekazanie projektu do umowy. Wymagaj standardowego stacku, bo od tego zależy, ilu wykonawców może projekt przejąć.
Czy da się zacząć od gotowego CRM i przejść na własny później?
Tak i to zwykle najrozsądniejsza droga. Rok czy dwa pracy na gotowym systemie porządkuje proces, pokazuje, których danych naprawdę używacie, i daje gotową listę rzeczy, których pudełko nie zrobi. Ta lista jest najlepszym materiałem wejściowym do discovery. Warunek: od początku sprawdź, co i w jakim formacie da się z systemu wyeksportować.
Podsumowanie
Gotowy CRM przestaje wystarczać rzadziej, niż wydaje się właścicielom firm, i częściej, niż przyznają dostawcy oprogramowania. Granica biegnie na poziomie modelu danych. Dopóki Waszą pracę da się opisać firmami, osobami, szansami i zadaniami, pudełko wygra ceną i tym, że ktoś inny utrzymuje je za Was. Kiedy centralnym obiektem staje się rezerwacja z uczestnikami albo edycja kursu z indywidualnymi ratami, konfiguracja przestaje pomagać. W obu wdrożeniach, które opisałem, decyzja nie wzięła się z listy brakujących funkcji, tylko stąd, że firma prowadziła swoją główną operację w arkuszu obok systemu, za który płaciła.
Zanim zdecydujesz, zrób najtańszy możliwy test: wypisz wszystko, czego gotowy system nie robi, i sprawdź z kimś doświadczonym, ile z tego da się załatwić konfiguracją i automatyzacją. Zostaną trzy pozycje? Masz odpowiedź. Zostanie dwadzieścia i połowa dotyczy tego, jak wyglądają Wasze dane? Rozmowa o budowie jest uzasadniona.
Chcesz ustalić, po której stronie tej granicy jest Wasza firma? Umów bezpłatną konsultację — powiemy wprost, jeśli wystarczy lepiej ustawiony gotowy CRM i żadna budowa nie jest potrzebna.
