Portal HubSpota w małej firmie psuje się w pierwszym tygodniu i zostaje taki na dwa lata, bo nikt nie ma czasu tego cofnąć. Pokazuję pięć decyzji konfiguracyjnych, które widzę najczęściej, z kosztem policzonym w minutach i rekordach, oraz to, co robić zamiast nich.
Skąd biorą się zepsute portale w małych firmach
Z kopiowania cudzej struktury zamiast opisania własnego procesu. Mała firma nie ma admina, więc konfiguracja powstaje raz, w pierwszym tygodniu, przy okazji onboardingu, i nikt do niej nie wraca.
W dużej organizacji zła decyzja konfiguracyjna zostaje wyłapana, bo ktoś nią oddycha na etacie. W firmie na sześć osób ten sam błąd żyje tak długo, jak długo da się go obejść ręcznie. Czyli zwykle do momentu, w którym ktoś pyta o raport i okazuje się, że nie ma z czego go zbudować.
Poniższe pięć nie jest listą wad HubSpota. To są decyzje, które ktoś podjął, najczęściej w dobrej wierze, kierując się tym, jak system wygląda, a nie tym, jak firma pracuje. Szerszy obraz przesiadki zespołu i migracji opisałem w wyzwaniach wdrożenia; tutaj schodzę do samej konfiguracji.
Błąd pierwszy: pola zakładane na zapas
Trzydzieści properties na kontakcie, dwadzieścia oznaczonych jako wymagane, bo „przyda się do raportowania". Efekt jest odwrotny do zamierzonego: handlowiec wypełnia je byle czym, żeby okienko zniknęło, i raport dostaje dane gorsze niż brak danych.
Objaw, po którym poznaję to od razu: w widoku kontaktu jest kolumna, w której prawie wszystkie wartości są puste albo brzmią jak wpisane na odczepnego. Pole istnieje, jest wymagane i nie niesie żadnej informacji.
Pole, którego nie wymuszasz, umiera. Pole, które wymuszasz bez powodu, zatruwa bazę. Do tego typ pola przesądza o tym, co da się z niego wyciągnąć: filtr na właściwości tekstowej działa na dopasowaniu wpisanego tekstu, a lista wyboru trzyma zamknięty zbiór opcji, po którym da się segmentować i liczyć. Dlatego branża wpisywana z ręki wraca jako produkcja, fabryka i wytwórnia, czyli trzy grupy zamiast jednej.
Co zamiast. Trzy do pięciu pól, każde z listą wyboru i krótką listą wartości. Jeżeli lista ma być tak długa, że wszyscy klikają pierwszą pozycję alfabetycznie, to jest gorsza niż jej brak. Reszta pól powstaje wtedy, gdy ktoś realnie o coś zapyta, a nie zanim.
Błąd drugi: deal stage'y opisujące pracę handlowca
Etapy w rodzaju „wysłano ofertę", „follow-up", „czekamy" opisują to, co robi sprzedaż, a nie to, co zdecydował klient. Pipeline zbudowany na czynnościach nie prognozuje niczego, bo deal może tkwić w „follow-up" trzy miesiące i formalnie wszystko jest w porządku.
Drugi objaw widać w raporcie: konwersja między etapami wynosi blisko sto procent na każdym przejściu poza ostatnim. To nie znaczy, że sprzedaż jest świetna, tylko że etapy nie odsiewają niczego i deal przechodzi przez nie z rozpędu.
Etap ma odpowiadać na pytanie, co się zmieniło po stronie kupującego: potwierdził problem, dopuścił nas do decydenta, zaakceptował zakres, podpisał. Wtedy czas w etapie znaczy coś konkretnego i widać, gdzie proces się zatrzymuje.
Co zamiast. Cztery do sześciu etapów, każdy nazwany zmianą po stronie klienta, i jedno kryterium wejścia na etap spisane po ludzku. Rozpisałem to szerzej przy błędach w deal stage logic.
Błąd trzeci: brak jednego klucza firmy
Ta sama firma siedzi w bazie w trzech wariantach, bo każdy wpisał ją po swojemu: pełna nazwa ze spółką, skrót, wersja z literówką. Deduplikacja po nazwie nie zadziała, a raport przychodu per klient rozjeżdża się na wejściu.
W polskim B2B klucz jest gotowy i darmowy: NIP. Wpisanie numeru pozwala dociągnąć nazwę, adres, REGON, formę prawną i kody PKD z rejestrów publicznych, więc nazwa przestaje być wpisywana z palca.
Policz to u siebie: uzupełnienie danych firmy ręcznie z wyszukiwarki to 2 do 3 minut na rekord. Przy czterdziestu nowych firmach miesięcznie robi się z tego około dwóch godzin czystego przeklepywania, a przy okazji trzy warianty nazwy zamiast jednego.
Błąd czwarty: automatyzacja przed poznaniem reguły
Workflow powstaje w trzecim dniu wdrożenia, zanim ktokolwiek wie, jak proces naprawdę wygląda. Po miesiącu okazuje się, że reguła jest inna, ale automat już działa i przesuwa rekordy, więc nikt go nie wyłącza, tylko obudowuje wyjątkami.
Rozpoznaję to po workflow z nazwą w rodzaju „kopia dwa poprawiona”. Automat obudowany wyjątkami przestaje być automatem, bo żeby przewidzieć, co zrobi, trzeba przeczytać wszystkie gałęzie.
Najpierw łopatologicznie i ręcznie, automat dopiero wtedy, gdy reguła jest znana i powtarzalna. To nie jest zachęta do klikania w kółko, tylko kolejność: automatyzujemy czynność, którą ktoś wykonał już kilkadziesiąt razy i umie ją opisać jednym zdaniem.
Test przed zbudowaniem workflow. Ile razy w miesiącu ta czynność się dzieje i ile minut zajmuje. Jeżeli wychodzi kilkanaście minut miesięcznie, automat się nie zwróci przy tym wolumenie, natomiast jeżeli wychodzą godziny, to jest pierwszy kandydat.
Błąd piąty: portal bez właściciela
Nikt nie odpowiada za konfigurację, więc każdy zmienia u siebie. Po kwartale są cztery widoki o tej samej nazwie, dwa pipeline'y robiące to samo i workflow, którego autora nikt nie pamięta.
W małej firmie nie chodzi o etat admina, tylko o jedną osobę, która ma prawo powiedzieć nie. Wystarczy, że zmiana w properties, pipeline i workflow przechodzi przez nią, a reszta zespołu zgłasza potrzebę zamiast klikać samodzielnie.
Co zamiast. Nazwisko przy portalu i piętnaście minut co dwa tygodnie na przegląd tego, co doszło. To jest tańsze niż jedno porządkowanie po roku.
Czego w tej piątce świadomie nie ma
Nie ma zakupu za wysokiego albo za niskiego planu. Widzę oba przypadki, ale to nie jest błąd konfiguracji, tylko decyzja handlowa, którą podejmuje się przed wdrożeniem i koryguje przy odnowieniu.
Nie ma też migracji danych, choć potrafi zaboleć najbardziej. Migracja jest projektem samym w sobie, z własnym zabezpieczeniem: backup, identyfikatory rekordów, wyłączone destrukcyjne workflow i akcept mapowania przed startem. Wrzucanie jej do listy błędów konfiguracyjnych spłaszcza temat, który na to nie zasługuje.
Jeżeli szukasz pełnej kolejności czynności po zakupie, a nie listy pułapek, dziewięć kroków opisałem w checkliście wdrożenia.
Od czego zacząć, jeżeli portal już stoi
Nie od przebudowy. Od policzenia skali, bo panika kosztuje więcej niż poprawka. Wyeksportuj kontakty i firmy, policz, ile rekordów ma pusty klucz i ile pól jest wypełnionych w mniej niż jednej piątej rekordów. Zwykle okazuje się, że źle jest w dwóch miejscach, nie wszędzie.
Potem kolejność: najpierw klucz firmy, bo od niego zależą raporty, potem deal stage'y, bo od nich zależy prognoza, na końcu pola i automatyzacje. Sekwencję całego wdrożenia od zera rozpisałem w sześciu krokach konfiguracji.
