Zakres wdrożenia HubSpot ustalony po podpisaniu umowy rośnie w trakcie i na starcie nikt, ani klient, ani wykonawca, nie potrafi powiedzieć, ile finalnie będzie kosztować. Rozwiązaniem jest rozbicie na dwa kroki: osobno wyceniony warsztat, którego produktem jest dokument zakresu przechodzący na własność klienta, i dopiero potem decyzja o wdrożeniu z bazowym MVP ustalonym z góry oraz resztą rozliczaną zadaniowo.
Opisuję to jako zmianę, którą zrobiliśmy u siebie, bo stary model przestał działać. Nie dlatego, że klienci byli nieuczciwi, tylko dlatego, że obie strony na starcie nie wiedziały wystarczająco dużo.
Jak określić zakres wdrożenia HubSpot przed startem?
Przez osobny, płatny krok, który kończy się dokumentem, a nie przez dłuższą rozmowę handlową. Dokument zakresu opisuje proces, mapę obiektów i pól, listę automatyzacji, granice integracji i to, czego świadomie nie robimy. Dopiero na tym da się zbudować wycenę, która nie zmieni się w trakcie o rząd wielkości.
Kolejność jest odwrotna do intuicji: najpierw płacicie za wiedzę, potem za robotę. Za to po pierwszym kroku macie dokument, który da się zrealizować z nami, samodzielnie albo z kimkolwiek innym.
Dlaczego zakres ustalony po umowie zawsze rośnie
Bo w momencie podpisywania obie strony operują na opowieści o procesie, a nie na procesie. Z naszej praktyki: zdecydowana większość wdrożeń zaczyna się warsztatem, bo na pytanie "czy macie proces" pada tak, a na pytanie "czy macie go spisany" pada nie.
Nawet spisane procesy nie zamykają tematu. To, co jest spisane, zwykle nie jest tym, jak firma działa naprawdę, i różnica wychodzi dopiero na produkcji, kiedy handlowiec mówi, że u niego to się odbywa inaczej. Spisany proces jest dużą wartością i skraca warsztat, natomiast go nie zastępuje.
Druga przyczyna to dosypywanie wymagań w trakcie. Jeżeli lista życzeń przychodzi partiami co trzy tygodnie, projekt wydłuża się w nieskończoność i nikt nie projektuje niczego z myślą o przyszłości, bo nie wie, co jeszcze dojdzie.
Warsztat jako osobny krok, nie jako część sprzedaży
Warsztat ma stałą cenę niezależnie od liczby hubów i kończy się dokumentacją, którą klient dostaje na własność, bez zobowiązania do wdrażania z autorem. To brzmi jak strzał we własną stopę i nie jest: klient, który ma dokument i może pójść z nim gdzie chce, kupuje spokojniej.
Warsztat robimy online, w krótszych sesjach w serii, nie jednym całodniowym spotkaniem. Percepcja siada po dwóch godzinach i lunchu, a slot w kalendarzu online jest po prostu pilnowany lepiej niż spotkanie w biurze, gdzie z trzech godzin robi się dwie i pół, bo ludzie się znają i dyskutują.
Jedna rzecz, której warsztat nie ma robić: przeklikywania status quo. Gdybyśmy wzięli to, co już znacie, i wrzucili do narzędzia, bylibyśmy tylko klikaczami za was. Sens tego kroku jest w tym, żeby proces przy okazji poprawić.
Co musi znaleźć się w dokumencie zakresu
Sześć rzeczy. Bez którejkolwiek z nich wycena jest zgadywaniem, a nie wyceną.
- proces sprzedaży i obsługi z kryteriami wejścia do każdego etapu, nie samymi nazwami
- mapa obiektów i pól, z zaznaczeniem, co jest wymagane, a co uzupełniane automatycznie
- lista automatyzacji z regułą, którą każda z nich realizuje
- granice integracji: co zostaje w systemach źródłowych i który kierunek synchronizacji obowiązuje
- plan szkoleń: ile sesji, dla kogo, w jakich blokach
- lista rzeczy świadomie odłożonych, z powodem
Ostatni punkt jest najważniejszy i najczęściej pomijany. Zakres definiuje się przez to, czego nie robimy, równie mocno jak przez to, co robimy.
MVP z góry, reszta zadaniowo
Sztywno zamknięty pakiet godzin wygląda bezpiecznie i w praktyce daje gorsze efekty niż model mieszany: bazowy zakres MVP ustalony z góry, a reszta realizowana zadaniowo, z wyceną przed każdym większym elementem.
Powód jest prosty. Przy zamkniętym pakiecie każda zmiana staje się negocjacją, więc obie strony unikają zmian, nawet dobrych. Przy modelu zadaniowym zmiana ma cenę, którą widać przed decyzją, czyli klient decyduje, a nie tylko akceptuje.
Do tego zasada, którą stosuję konsekwentnie: cenę techniczną pytania sygnalizuję, zanim klient odpowie. Jeżeli funkcja wiąże ze sobą dużo roboty, mówię to przed decyzją, a nie w kolejnej fakturze.
Co zawęża zakres zamiast go rozdmuchiwać
Najtańsza decyzja w projekcie to decyzja, żeby czegoś nie robić. Jeżeli faktury działają w systemie księgowym, a obsługa zamówień w dedykowanym narzędziu, nie dublujemy ich w CRM. Nie każdy kanał komunikacji nadaje się do wciągnięcia: przy źródłach z zanonimizowanym nadawcą każda wiadomość tworzyłaby kontakt-śmieć.
Podobnie z modelem danych. Pola tworzone na zapas albo property pod jedno wydarzenie kończą się pięćdziesiątką propertisów i raportowaniem nie do życia. Automatyzuje się regułę, którą się zna, a nie tę, którą się przewiduje.
Plan licencji jako twarda granica zakresu
Część zakresu rozstrzyga cennik, a nie projekt, i lepiej wiedzieć to przed umową. Klasyczny przykład: lead scoring wymaga planu Professional lub Enterprise, a punktacja na dealach dostępna jest wyłącznie po stronie Sales Huba. Jeżeli dokument zakresu zakłada scoring, a licencja tego nie obejmuje, macie rozjazd, który wyjdzie w połowie projektu.
Jeżeli zakres obejmuje przeniesienie danych ze starego systemu, warto potraktować to jako osobny projekt z własnymi etapami. HubSpot rozbija migrację danych na zrozumienie wymagań, projekt architektury, harmonogram, testy na osobnym środowisku, obserwowalność i stopniowe przenoszenie. Wciśnięcie tego w zakres wdrożenia jako jednej pozycji jest najczęstszym źródłem przekroczeń.
Gdzie zapisujecie ustalenia
W mailu, po każdej sesji. Nie dlatego, że ktoś kłamie, tylko dlatego, że po roku i po rotacji ludzi po obu stronach mail jest jedynym świadkiem tego, co ustaliliście. Rozmowa "ustalaliśmy co innego" kończy się wtedy w pięć minut zamiast w tygodniu.
Dyscyplina zakresu ratuje projekt bardziej niż perfekcjonizm. Scenariusze podstawowe obsłużone, wyjątki wypisane i świadomie odłożone do decyzji klienta, zamiast wstrzymywania całości do czasu rozwiązania każdego przypadku brzegowego.
Czego nie da się ustalić przed startem
Trzech rzeczy, i uczciwie jest to powiedzieć wprost. Pełnego zakresu integracji z waszymi systemami, dopóki nie zobaczy się API i dokumentacji po drugiej stronie. Modelu scoringu, bo pierwsza wersja kalibruje się na danych po kilku miesiącach. Oraz tego, ile czasu zajmie zespołowi przesiadka, bo to zależy od nacisku ze strony zarządu, a nie od konfiguracji.
Jak układamy pracę na HubSpocie i co wchodzi w poszczególne projekty, opisaliśmy w katalogu usług. Jeżeli portal już stoi, a pytanie brzmi raczej "co w nim naprawić", punktem wejścia jest audyt portalu.
