Ten post odpowiada wprost na pytanie kupującego: jakie problemy realnie pojawiają się przy wdrażaniu HubSpot CRM w firmie B2B - od przesiadki zespołu sprzedaży, przez migrację danych i wybór tieru, po pierwsze 30 dni na produkcji. Sedno: technologia rzadko jest problemem, problem to ułożenie procesu i dobranie licencji do realnych potrzeb, a większość tych rzeczy rozstrzyga się w Discovery, jeszcze przed konfiguracją.
Rozłożę pięć rzeczy, które najczęściej wysadzają wdrożenie HubSpot CRM w polskim B2B: przesiadkę zespołu sprzedaży, migrację danych, wybór tieru licencji, model danych oderwany od procesu i pierwsze 30 dni na produkcji. Piszę to z tego, co widzę u klientów, nie z marketingowego decka. I od razu uczciwie: każde z tych pięciu wyzwań da się rozwiązać, ale tylko jeżeli zaplanujesz je z góry. Wdrożenie, które ich nie planuje, to wdrożenie, które ktoś odkłada na później - a "później" na produkcji jest droższe.
Jakie są główne wyzwania przy wdrażaniu HubSpot CRM w organizacji?
Główne wyzwania przy wdrażaniu HubSpot CRM to: przesiadka zespołu sprzedaży (bez danych w CRM nie ma forecastu), źle zaplanowana migracja danych (duplikaty, niezmapowane pola, zgubiona historia aktywności), zły dobór tieru licencji (Starter bez workflowów, Enterprise "na zapas"), model danych oderwany od realnego procesu sprzedaży oraz brak ownera projektu po stronie klienta po go-live. Wszystkie da się rozwiązać, ale decyzje muszą zapaść w Discovery, a nie po pierwszym kwartale na produkcji.
Poniżej rozkładam każdy z nich na czynniki pierwsze i pokazuję, jak wygląda wdrożenie, które te problemy zdejmuje z góry, zanim ktokolwiek dotknie produkcji.
Przesiadka zespołu: jak sprawić, żeby handlowiec przestał pisać w Excelu
Najczęstsza przyczyna, dla której wdrożenie HubSpot CRM nie daje forecastu, to zespół, który dalej trzyma notatki w Excelu, mailu i głowie, bo nikt mu nie pokazał, że CRM oddaje mu czas zamiast go zabierać. To nie jest bug HubSpota - to robota do zrobienia na etapie wdrożenia, i jeżeli ją pominiesz, cała reszta konfiguracji pracuje na pusto.
Piszę to jasno, bo sam się na tym uczyłem: jeżeli po moim wdrożeniu handlowiec dalej pisze w Excelu, to znaczy, że wdrożenie było niedokończone. Przesiadka zespołu to część mojej roboty, a nie coś, co "klient sobie sam ogarnie po szkoleniu". Zespół, który 10 lat pracował na mailu, nie przesiądzie się na CRM po jednej 4-godzinnej prezentacji ekranowej dzień przed go-live.
Znam też obiekcję, którą handlowiec rzuca pierwszego dnia: "w CRM jest więcej klikaniny niż na mailu". U jednego człowieka czasem faktycznie tak jest. Natomiast bez CRM firma nie odpowie, na jakie kwoty wysłała oferty w zeszłym miesiącu i ile z tego domknęła. To nie jest wygoda jednego handlowca kontra wygoda drugiego, tylko wygoda jednego kontra widoczność całej sprzedaży. I zadaniem wdrożenia jest tak ułożyć CRM, żeby ta wygoda jednostki też była po stronie systemu.
Jak to robię, żeby przesiadka realnie się wydarzyła:
- Pokazuję, że CRM oddaje czas. Każdy rekord w HubSpot CRM przechowuje dane i automatycznie śledzi interakcje - mail, call i meeting trafia na timeline kontaktu bez ręcznego logowania. Po podpięciu skrzynki SDR nie loguje już każdego maila z palca. To jego pierwsze "aha".
- Rano lista tasków zamiast scrollowania spreadsheetu. Task odpalany przez workflow daje handlowcowi gotową listę rzeczy do zrobienia na dziś, zamiast porannego rytuału z arkuszem.
- Trening na ich własnych dealach. Nie prezentacja ekranowa, tylko sesje 60-minutowe na ich pipelinie, ich klientach, ich stawkach. Na tym się przesiadają, bo widzą swoją robotę, nie demo.
Po dwóch takich sesjach zespół, który realnie pracował w CRM w 30%, wchodzi na 80%. Opór to norma i mija w kilka tygodni - głównym blokerem jest zwykle strach przed monitoringiem, nie technologia. O tym, jak dobrać sam CRM pod dopasowanie, a nie pod listę funkcji, pisałem w tekście o wyborze CRM pod dopasowanie.
Migracja danych: nowy CRM wygląda jak stary, tylko gorzej
Migracja danych to drugi najczęstszy punkt zapalny: duplikaty kontaktów, niezmapowane pola, zgubiona historia aktywności, deale bez ownerów. Bez zaplanowanej migracji dzień po go-live nowy CRM wygląda jak stary, tylko gorzej, bo zespół nie wie, gdzie czego szukać - i wraca do Excela, zamykając koło z poprzedniej sekcji.
Realny checklist migracji, który przechodzę u klientów:
- Audyt źródła - ile rekordów w Pipedrive, Salesforce czy Bitrix jest faktycznie aktywnych, a ile to martwy ciężar z 2019 roku, który leży odłogiem
- Deduplikacja przed importem - łatwiej zrobić to raz przed migracją niż ścigać duplikaty przez następny rok
- Mapowanie pól - które custom properties w starym CRM mają sens w nowym, a które były protezą na ograniczenia starego systemu
- Próba w sandboxie - import 100 rekordów, sprawdzenie, czy timeline aktywności wjechał poprawnie i czy associations Contact-Company-Deal się trzymają
- Cutover plan - kto i kiedy wpisuje ostatnie deale do starego systemu, kiedy zamykamy zapis, kiedy odpalamy import produkcyjny
Jedna pułapka, którą widzę najczęściej: znaczniki MQL. W Pipedrive lead ma datę, kiedy stał się MQL. Prosty import 1:1 tę datę gubi, czyli marketing traci odpowiedź na pytanie, skąd przyszły deale i jaki był win-rate per źródło. Timestampy przenosimy jako osobne custom property, a nie jako efekt uboczny statusu. Robię to jako oddzielną usługę migracji CRM, bo łączenie migracji z konfiguracją w jednym sprincie zawsze kończy się tym, że jedno albo drugie jest niedokończone.
Wybór tieru: Starter, Professional czy Enterprise
Dobór tieru licencji to decyzja, której nie cofniesz tanio. Kupujesz Starter, po pół roku potrzebujesz workflowów i przepłacasz upgrade. Kupujesz Enterprise "na zapas" i przez rok 70% feature'ów leży nieużywanych. Decyzja musi wychodzić z Discovery, a nie z rekomendacji sprzedawcy, który akurat sprzedaje wyższy tier.
Progi tierów, które realnie ważą na decyzji w Sales Hubie:
| Funkcja | Starter | Professional | Enterprise |
|---|---|---|---|
| Workflows (automatyzacje na obiektach CRM) | Nie | Tak | Tak |
| Sequences | Nie | Tak | Tak |
| Custom Objects | Nie | Nie | Tak |
Dwa progi, na których najczęściej wykłada się dobór tieru:
Workflows. Jeżeli planujesz jakąkolwiek automatyzację na CRM - lead routing, tworzenie tasków po zmianie stage'a, nurturing - workflowy w HubSpot dostajesz od tieru Professional w górę, nie na Starterze. Czyli jeżeli w Discovery wyszło, że SDR robi 6 godzin tygodniowo ręcznego update'u, Starter tego nie zdejmie. Tu nie ma negocjacji.
Custom Objects. Standardowo HubSpot CRM ma Contact, Company, Deal, Ticket. Jeżeli biznes potrzebuje zamodelować inny obiekt, na przykład Projekt, Subskrypcję albo Wydarzenie, Custom Objects wymagają subskrypcji Enterprise na każdym Hubie, w którym chcesz ich używać. To często przesądza, czy klient kupuje Sales Hub Professional czy Enterprise. Natomiast w 7 na 10 przypadków w polskim B2B SMB Custom Object jest nadmiarowy - da się zamodelować w Deal lub Contact properties. Sequences, jeśli je planujesz, też siedzą od tieru Professional w górę i wymagają przypisanego seata Sales lub Service.
Model danych: handlowiec przewija 20 pól zamiast sprzedawać
Czwarty problem to model danych oderwany od realnego procesu sprzedaży: ile pipeline'ów, jakie stage'e, jakie required properties na każdym stage'u, jak płynie lead vs deal. Źle zaprojektowany model sprawia, że handlowiec przewija 20 pól na każdym dealu, żeby znaleźć to jedno, które naprawdę wypełnia, a w resztę wpisuje śmieci.
Praktyczne zasady, których używam u klientów:
- Jeden pipeline to jeden proces sprzedaży. Nie pakuj inbound, outbound i renewals w jeden pipeline tylko dlatego, że "tak było w Pipedrive".
- 5-7 stage'ów, nie 12. Każdy stage musi mieć jasne kryterium wejścia. Jeżeli handlowiec nie potrafi w jednym zdaniu powiedzieć, kiedy deal jest w "Negocjacji", a kiedy w "Propozycji", masz problem.
- Required properties tylko tam, gdzie biznes ich realnie potrzebuje. Jeżeli pole "Branża" jest wymagane na stage'u "Lead", handlowiec wpisze byle co, żeby przepchnąć deal dalej. Pole tekstowe i tak się nigdy nie zaraportuje - daj dropdown z krótką listą.
- Lead i Deal to dwa różne obiekty. Na Sales Hub Professional masz obiekt Lead do prekwalifikacji. Zapytanie z formularza nie powinno od razu lądować jako Deal w pipelinie. Lead to lejek przed lejkiem - dzięki temu pipeline pokazuje realny forecast, a nie szum z formularzy.
Pierwsze 30 dni na produkcji: czego nikt nie planuje
Piąty problem, najbardziej niedoceniany: pierwsze 30 dni po go-live to nie koniec wdrożenia, tylko jego najtrudniejsza faza. Bugi konfiguracyjne wychodzą dopiero na realnych danych, zespół zgłasza pytania, których nie było na warsztacie, część automatyzacji okazuje się za agresywna albo za słaba. Bez ownera projektu po stronie klienta i bez supportu konsultanta w tym oknie wdrożenie umiera po cichu.
Co się sypie w pierwszych 30 dniach, z moich wdrożeń:
- Workflow tworzy task, którego handlowiec nie rozumie, bo treść pisał konsultant, a nie sales manager
- Lead routing przypisuje deale nie tej osobie, bo w Discovery pominęliśmy, że Anna jest na urlopie w lipcu
- Integracja maila loguje prywatne wiadomości handlowca do CRM, bo nikt nie ustawił filtra "never log"
- Raporty na dashboardzie pokazują dziwne liczby, bo deal stage probability siedzi na wartościach domyślnych, a nie na historycznym win-rate klienta
Każdą z tych rzeczy naprawia się w 30 minut. Natomiast ktoś musi je najpierw zauważyć i zgłosić. Dlatego po go-live trzymam u klientów okno 30-dniowego wsparcia: cotygodniowy call, dedykowany kanał komunikacji, fix bugów bez nowego SOW. To ta sama zasada co przy przesiadce zespołu - wdrożenie kończy się wtedy, gdy zespół realnie w tym pracuje, a nie w dniu go-live.
Czego wdrożenie HubSpot CRM NIE rozwiąże
Wdrożenie HubSpot CRM nie naprawi złego procesu sprzedaży, nie zmusi handlowców do uzupełniania danych, jeżeli nie mają w tym własnego interesu, nie wygeneruje leadów z niczego i nie zastąpi sales managera. HubSpot to platforma, która egzekwuje twój proces. Jeżeli procesu nie ma, CRM go za ciebie nie wymyśli - dlatego dobre wdrożenie zaczyna się od ułożenia procesu, nie od klikania w ustawieniach.
Czyli jeżeli wchodzisz w wdrożenie z myślą "kupimy HubSpot, to się poukłada", to się nie poukłada samo. Najpierw Discovery, w którym definiujemy proces, persony kupujące, stage'e deala i kryteria kwalifikacji. Potem konfiguracja HubSpot pod ten proces. W tej kolejności, nie odwrotnie - i wtedy żaden z pięciu problemów z tego posta nie wybija cię z gry.
Co dalej
Jeżeli planujesz wdrożenie HubSpot CRM albo siedzisz w połowie wdrożenia i widzisz, że coś nie gra, umów discovery call. Przejdziemy przez twój obecny stack, proces sprzedaży i wymagania, a ja wracam z kierunkową oceną, czy HubSpot to dobra odpowiedź i w jakim tierze. Jeżeli wolisz formę pisemną, opisz projekt w briefie - odezwę się w kilka dni roboczych.
