Nowy HubSpot może wyglądać na gotowy do pracy już po kilku godzinach. Są kontakty, pipeline, formularz i użytkownicy. Wszystko wydaje się poukładane - dopóki zespół nie zacznie prowadzić w nim prawdziwej sprzedaży.
Wtedy wychodzą braki. Handlowcy zapisują część informacji poza CRM, kolejne etapy pipeline’u nie zawsze odpowiadają temu, co dzieje się z klientem, a po podpisaniu umowy proces przenosi się do arkuszy, poczty albo innych systemów.
To zwykle nie jest problem samego HubSpot. Najczęściej oznacza po prostu, że portal został skonfigurowany szybciej niż został zaprojektowany sposób pracy w nim.
Punkt wyjścia
Wdrożenie HubSpot nie polega na przeniesieniu procesu do CRM. Najpierw trzeba ustalić, jaki proces CRM ma obsługiwać.
Dobrze przeprowadzone wdrożenie łączy sposób pracy ludzi, strukturę danych i możliwości platformy. Konfiguracja przychodzi później. Dzięki temu system nie wymusza na firmie przypadkowego modelu pracy tylko dlatego, że taki pipeline najłatwiej było ustawić na początku.
Poniżej pokazujemy, jak taki proces może wyglądać od pierwszej rozmowy o CRM do momentu, w którym zespół zaczyna korzystać z HubSpot w codziennej pracy.
1. Zanim powstanie pipeline, trzeba zobaczyć cały proces
Na początku projektu nie interesuje nas jeszcze nazwa pierwszego etapu deala ani kolor dashboardu. Znacznie ważniejsze jest ustalenie, co dzieje się z klientem od pierwszego kontaktu z firmą.
Skąd pojawia się lead? Kto go sprawdza? Kiedy trafia do sprzedaży? Co musi wydarzyć się przed przygotowaniem oferty? Kto przejmuje klienta po podpisaniu umowy? W którym systemie pojawia się informacja o płatności?
Dopiero po przejściu całej ścieżki widać, jaką rolę powinien pełnić HubSpot.
Jeżeli proces sprzedaży istnieje wyłącznie jako wiedza zespołu, konfiguracja CRM bardzo szybko zacznie odzwierciedlać wyjątki zamiast reguł.
Na tym etapie często wychodzą rzeczy, których wcześniej nikt nie traktował jako problemu. Informacja przekazywana między działami przez wiadomość na Teams. Ręczne tworzenie dokumentu po wygraniu deala. Osobny Excel z klientami do ponownego kontaktu. Dla wdrożenia CRM są to ważniejsze informacje niż sama lista funkcji HubSpot.
2. As-Is pokazuje, jak firma pracuje dziś. To-Be - jak ma pracować po wdrożeniu
Nie każdy element obecnego procesu powinien zostać przeniesiony do HubSpot.
Jeżeli handlowiec po każdym spotkaniu przepisuje część danych z notatki do arkusza, a później druga osoba przenosi je do CRM, nie ma sensu automatyzować całej tej ścieżki dokładnie w obecnej formie.
Najpierw warto oddzielić sposób pracy, który powstał przez lata, od procesu, którego firma rzeczywiście potrzebuje.
As-Is
Jak wygląda praca dzisiaj
Sprawdzamy, gdzie pojawiają się dane, kto podejmuje decyzje, jakie czynności wykonywane są ręcznie i gdzie proces opuszcza CRM.
To-Be
Jak proces powinien działać
Ustalamy, które działania zostają, które można uprościć, które przejmie automatyzacja i jakie informacje muszą być dostępne w CRM.
To ważny moment wdrożenia, ponieważ późniejsze pipeline'y, workflowy i raporty powinny wynikać z procesu To-Be. W przeciwnym razie HubSpot może bardzo sprawnie automatyzować sposób pracy, którego firma już nie potrzebuje.
3. Model danych trzeba zaprojektować przed importem kontaktów
Przy nowym portalu łatwo rozpocząć od tworzenia właściwości. Każdy dział zgłasza swoje potrzeby, więc pojawia się kolejne pole, lista wyboru i checkbox.
Po kilku miesiącach może się okazać, że ta sama informacja istnieje na kontakcie, firmie i dealu, a różne workflowy korzystają z różnych wersji.
Dlatego struktura danych powinna zostać zaprojektowana jeszcze przed większym importem.
Przykład
Firma sprzedaje usługę na rzecz organizacji, ale w procesie bierze udział kilka osób. Informacja o branży należy do firmy, dane osoby kontaktowej do kontaktu, a wartość sprzedaży i termin decyzji do deala. Jeżeli wszystkie te informacje trafią do jednego obiektu, raportowanie i automatyzacje szybko staną się trudniejsze niż powinny.
Przy bardziej złożonych procesach mogą pojawić się również obiekty niestandardowe. Umowa, subskrypcja, urządzenie, oddział czy projekt nie zawsze powinny być kolejnym polem albo kolejnym dealem.
Dobrze zaprojektowany model danych daje później dużo większą swobodę. Łatwiej budować automatyzacje, raportować i integrować HubSpot z innymi systemami.
4. Pipeline ma opisywać sytuację biznesową, a nie aktywność handlowca
Dobrym testem dla każdego etapu pipeline'u jest pytanie: co musi być prawdą, żeby deal mógł znaleźć się na tym etapie?
Jeżeli odpowiedź brzmi „handlowiec wysłał e-mail”, etap prawdopodobnie opisuje czynność, a nie stan procesu.
Samo wysłanie oferty nie mówi jeszcze, czy klient ją analizuje, czy potwierdził budżet, czy odbyło się spotkanie z osobą decyzyjną. Pipeline powinien umożliwiać odczytanie rzeczywistej sytuacji sprzedażowej bez konieczności otwierania każdego deala i czytania całej historii.
Jeżeli dwie osoby rozumieją ten sam etap inaczej, raport konwersji zaczyna mierzyć sposób używania CRM zamiast skuteczności sprzedaży.
Na etapie wdrożenia warto więc ustalić nie tylko nazwy etapów, ale również warunki wejścia i wyjścia. To później pomaga w automatyzacji, forecastingu i szkoleniu nowych użytkowników.
5. Migracja danych powinna zacząć się od decyzji, czego nie migrujemy
Przeprowadzka do nowego CRM często uruchamia prosty odruch: przenieśmy wszystko.
Tymczasem w starym systemie mogą znajdować się kontakty, z którymi nikt nie rozmawiał od lat, historyczne pola używane przez poprzedni proces, duplikaty i nieaktualne wartości. Przeniesienie ich jeden do jednego oznacza rozpoczęcie pracy w nowym HubSpot ze starym problemem jakości danych.
Przed migracją dobrze jest ustalić zakres historii, sposób identyfikowania rekordów oraz to, które dane są nadal wykorzystywane w procesie. Część starych informacji może pozostać w archiwum zamiast trafiać do aktywnego CRM.
Dużo uwagi wymaga też deduplikacja. Adres e-mail nie zawsze wystarcza jako jedyny identyfikator, szczególnie gdy HubSpot wymienia dane z ERP, platformą klienta albo własnym systemem firmy.
Jeżeli integracja ma działać przez lata, warto od początku przewidzieć stabilny identyfikator, który pozwoli jednoznacznie rozpoznać rekord po obu stronach.
6. Automatyzacja powinna usuwać pracę, a nie ukrywać źle zaprojektowany proces
HubSpot pozwala stosunkowo szybko zbudować workflow, który zmieni właściciela, utworzy zadanie, ustawi właściwość albo uruchomi webhook.
Technicznie można więc zautomatyzować bardzo dużo. Nie oznacza to, że każdą ręczną czynność należy od razu zamienić w workflow.
Jeżeli zespół nie potrafi jednoznacznie powiedzieć, kiedy lead powinien trafić do sprzedaży, automatyzacja nie rozwiąże tego problemu. Przeniesie tylko niejasną zasadę do systemu.
Prosta zasada projektowa
Najpierw warunek biznesowy.
Lead spełnia określone kryteria i powinien zostać przejęty przez sprzedaż.
Później reakcja systemu.
HubSpot ustawia właściciela, zmienia status i tworzy zadanie dla handlowca.
Dzięki takiej kolejności workflow odzwierciedla ustaloną regułę. Kiedy proces zmieni się za rok, znacznie łatwiej będzie również zrozumieć, dlaczego dana automatyzacja istnieje.
7. HubSpot trzeba umieścić pomiędzy pozostałymi systemami firmy
Wdrożenie rzadko kończy się na samym CRM. Firma ma już księgowość, ERP, platformę e-commerce, system podpisywania dokumentów albo własną aplikację.
Na tym etapie ważniejsze od pytania „czy da się zrobić integrację?” jest ustalenie, który system odpowiada za daną informację.
Jeżeli status płatności pochodzi z systemu księgowego, HubSpot powinien go otrzymywać, ale prawdopodobnie nie powinien być miejscem, z którego użytkownik może go dowolnie zmienić. Jeżeli dane właściciela relacji są zarządzane przez sprzedaż w CRM, integracja nie powinna nadpisywać ich podczas każdej synchronizacji.
Integracja bez określenia źródła prawdy działa dobrze do momentu, w którym dwa systemy zaczynają poprawnie synchronizować dwie różne wersje tej samej informacji.
Przy projektowaniu trzeba uwzględnić również błędy, limity API i sytuacje, w których jeden z systemów chwilowo nie odpowiada. Dobrze zaprojektowana integracja potrafi ponowić operację, zapisać błąd i pozwolić ustalić później, którego rekordu dotyczył problem.
To szczególnie ważne, gdy HubSpot staje się centralnym miejscem pracy zespołu, ale część danych nadal pochodzi z innych systemów.
8. Raportowanie projektuje się razem z procesem, nie na jego końcu
Pierwszy dashboard można przygotować bardzo szybko. Znacznie trudniej sprawić, żeby pokazywał liczbę, której naprawdę można użyć do podjęcia decyzji.
Jeżeli zarząd chce widzieć konwersję z kwalifikowanego leada do klienta, wcześniej trzeba dokładnie ustalić, co oznacza „kwalifikowany lead”. Jeżeli potrzebny jest forecast, etapy pipeline'u i zasady aktualizacji deali muszą być wystarczająco spójne, aby prawdopodobieństwo sprzedaży miało sens.
Raport jest końcem łańcucha
Proces generuje dane. Dane zasilają raport. Dashboard nie naprawi procesu, który nie zbiera potrzebnych informacji.
Dlatego wymagania dotyczące raportowania dobrze jest znać już podczas projektowania właściwości, etapów i automatyzacji. Dzięki temu po uruchomieniu systemu nie trzeba nagle dodawać kilkunastu pól tylko dlatego, że brakuje danych do pierwszego raportu zarządczego.
9. Przed uruchomieniem trzeba przejść proces tak, jak zrobi to użytkownik
Administrator może sprawdzić, czy workflow jest aktywny i czy właściwość ma odpowiedni typ. To nie wystarczy, żeby ocenić całe wdrożenie.
Najlepszy test zaczyna się od początku procesu.
Test całej ścieżki
Klient wysyła formularz. Rekord trafia do CRM. System przypisuje odpowiednią osobę. Handlowiec prowadzi deal przez pipeline. Pojawia się oferta. Po sprzedaży dane trafiają do kolejnego systemu. Informacja wraca do HubSpot. Wynik jest widoczny w raporcie.
Dopiero taki test pokazuje, czy poszczególne elementy konfiguracji tworzą jeden proces.
Warto wykonać go również na mniej wygodnych przypadkach. Klient bez numeru telefonu. Deal wracający do wcześniejszego etapu. Firma posiadająca kilka kontaktów. Błąd integracji. Rekord utworzony drugi raz.
W takich sytuacjach właśnie najczęściej wychodzą problemy, których nie widać podczas konfiguracji poszczególnych modułów.
10. Szkolenie powinno dotyczyć procesu, a nie interfejsu HubSpot
Pokazanie użytkownikom, gdzie znajduje się przycisk „Utwórz deal”, nie oznacza jeszcze, że wiedzą, jak pracować w nowym CRM.
Znacznie ważniejsze jest wyjaśnienie, kiedy deal powinien zostać utworzony, kiedy zmienić etap, co musi być zapisane na rekordzie i co stanie się później automatycznie.
Użytkownik powinien rozumieć proces, a HubSpot ma mu pomagać go wykonać.
Jeżeli po szkoleniu najważniejszą instrukcją jest kilkudziesięciostronicowy dokument z listą wyjątków, warto jeszcze raz spojrzeć na samą konfigurację.
Dobrze ustawiony system ogranicza liczbę rzeczy, o których użytkownik musi pamiętać. Pokazuje właściwe dane, wymaga informacji w odpowiednim momencie i automatycznie wykonuje część powtarzalnej pracy.
Ile trwa wdrożenie HubSpot?
Nie ma jednej liczby, która będzie właściwa dla każdej firmy.
Jeżeli celem jest uruchomienie podstawowego procesu sprzedaży dla małego zespołu, zakres może być stosunkowo niewielki. Przy projekcie obejmującym kilka działów, migrację historii, obiekty niestandardowe i integracje z systemami zewnętrznymi wdrożenie staje się normalnym projektem technologicznym.
Czas wynika więc głównie ze złożoności procesów i liczby zależności, a nie z samej liczby użytkowników HubSpot.
Dokładny harmonogram ma sens dopiero po poznaniu zakresu. W przeciwnym razie określamy termin konfiguracji, a nie termin wdrożenia CRM.
Od czego zależy koszt wdrożenia HubSpot?
Podobnie wygląda kwestia budżetu. Konfiguracja podstawowego Sales Hub dla jednego procesu nie jest tym samym projektem co migracja CRM używanego od kilku lat.
Najwięcej pracy zwykle pojawia się tam, gdzie trzeba połączyć kilka procesów, uporządkować dane albo przygotować niestandardową logikę. Integracja z ERP może wymagać więcej projektowania niż wszystkie pipeline'y razem. Przy innej firmie najtrudniejszym etapem będzie migracja albo uporządkowanie istniejącego modelu danych.
Dlatego sensowna wycena wdrożenia powinna opierać się na zakresie prac i oczekiwanym efekcie biznesowym, a nie wyłącznie na nazwie wykupionego pakietu HubSpot.
Wdrożenie HubSpot
Dobra kolejność ogranicza liczbę poprawek później
W uproszczeniu cały proces można zapisać w jednym ciągu:
Analiza procesu → model To-Be → architektura danych → konfiguracja → migracja → automatyzacje → integracje → testy → szkolenie → uruchomienie
Nie każdy projekt wymaga takiego samego zakresu. Istotna jest kolejność. Automatyzacje zbudowane przed ustaleniem procesu zwykle trzeba później poprawiać. Raporty przygotowane przed uporządkowaniem danych pokazują liczby, którym zespół nie ufa. Integracja uruchomiona bez zasad własności danych może tworzyć problemy po obu stronach.
Kiedy można uznać wdrożenie HubSpot za udane?
Nie wtedy, gdy wszystkie zaplanowane workflowy są aktywne.
Dobrze wdrożony HubSpot zaczyna być naturalnym miejscem pracy zespołu. Handlowiec nie potrzebuje osobnej listy klientów. Manager nie przygotowuje ręcznie poprawionej wersji pipeline'u przed spotkaniem. Raport korzysta z danych, które powstają podczas normalnej pracy, a informacje z innych systemów pojawiają się przy kliencie bez ręcznego przepisywania.
CRM nie musi zawierać wszystkiego. Powinien jednak dawać użytkownikowi informacje potrzebne do wykonania kolejnego kroku i pozwalać firmie spojrzeć na proces bez składania obrazu z kilku różnych miejsc.
Najlepszy efekt wdrożenia jest mało spektakularny: zespół po prostu pracuje, dane powstają przy okazji tej pracy, a system pilnuje reszty procesu.
Wdrożenia HubSpot w Velmanta
Najpierw projektujemy sposób działania CRM. Dopiero później konfigurujemy HubSpot.
W Velmanta wdrożenie zaczynamy od poznania procesu i tego, jak z systemu będą korzystać poszczególne zespoły. Na tej podstawie projektujemy strukturę danych, pipeline'y, automatyzacje i raportowanie.
Jeżeli HubSpot ma wymieniać dane z innymi aplikacjami, projekt obejmuje również architekturę integracji i zasady synchronizacji. Dzięki temu CRM nie jest osobnym narzędziem obok reszty infrastruktury, ale elementem całego procesu.
Porozmawiajmy o wdrożeniu HubSpotNajczęstsze pytania o wdrożenie HubSpot
Na czym polega wdrożenie HubSpot?
Wdrożenie polega na dopasowaniu HubSpot do procesów firmy. Obejmuje projekt sposobu pracy w CRM, strukturę danych, konfigurację pipeline'ów, migrację danych, automatyzacje, raportowanie oraz - gdy jest to potrzebne - integracje z innymi systemami.
Czy HubSpot można wdrożyć samodzielnie?
Tak. Przy prostym procesie i niewielkiej liczbie użytkowników wiele firm może samodzielnie skonfigurować podstawowe elementy CRM. Zewnętrzne wsparcie staje się szczególnie przydatne przy migracji danych, rozbudowanych automatyzacjach, kilku zespołach albo integracjach z innymi systemami.
Czy wdrożenie HubSpot wymaga migracji wszystkich danych?
Nie. Warto przenieść przede wszystkim informacje potrzebne do dalszej pracy i raportowania. Stare, nieaktualne albo niewykorzystywane dane mogą pozostać w archiwum zamiast zwiększać bałagan w nowym CRM.
Czy w ramach wdrożenia można zintegrować HubSpot z ERP?
Tak, jeżeli system ERP udostępnia odpowiedni sposób wymiany danych. Przed integracją warto ustalić, które informacje mają być synchronizowane, w jakim kierunku oraz który system jest źródłem prawdy dla poszczególnych danych.
Kiedy warto przebudować istniejące wdrożenie HubSpot?
Najczęściej wtedy, gdy sposób pracy firmy znacząco zmienił się od czasu pierwszej konfiguracji, użytkownicy zaczęli korzystać z dodatkowych arkuszy, raporty wymagają ręcznej korekty albo kolejne automatyzacje zaczynają komplikować zamiast upraszczać proces.
Komentarze