Aktualizacja:
Pięć błędów w konfiguracji deal stages w HubSpot, które najczęściej widzę na audytach polskich portali B2B - od źle ustawionych prawdopodobieństw po brak required properties i rotting alertów. Bottom line: większość leaky pipeline w HubSpocie to nie problem sprzedaży, tylko 30 minut nieprzemyślanej konfiguracji w Sales Hub.
Klient z PL produkcji, Sales Hub Professional od 14 miesięcy, 4 handlowców. Forecast pokazywał 480k PLN na kwartał. Zamknęli 190k. Discovery zajęło 40 minut, bo wszystko sypało się w jednym miejscu - default pipeline HubSpota, nie ruszony od onboardingu, z prawdopodobieństwami 20/40/60/80/100% i zerem required properties. Handlowcy klikali "Proposal Sent" na dealach, na których nie wysłali jeszcze oferty, bo tak wyglądał ich tydzień. Forecast to odzwierciedlał.
To nie jest edge case. To wzorzec. Poniżej pięć błędów które widzę praktycznie w każdym audycie portalu, plus konkretnie co zmienić w Sales Hub Professional, żeby pipeline zaczął pokazywać prawdę. Posty oparte na realnych audytach portali HubSpot, które robimy w Spectage - więc liczby i wzorce są z polskiego B2B, nie z amerykańskich SaaS templates.
Czym jest leaky pipeline w HubSpot i dlaczego forecast kłamie
Leaky pipeline to sytuacja, w której deal stages w CRM nie odzwierciedlają realnego procesu sprzedaży - prawdopodobieństwa są ustawione od linijki, handlowcy przechodzą etapy bez wypełnienia kluczowych danych, a deale gniją w jednym stage'u tygodniami bez alertów. Efekt: weighted forecast w HubSpot pokazuje liczbę, która nie ma związku z rzeczywistością.
HubSpot liczy weighted pipeline value jako sumę Amount przemnożoną przez Deal probability dla wszystkich deali wraz z Closed Won. Czyli jeżeli masz stage "Proposal Sent" z probability 60%, a w tym stage'u siedzi 800k PLN dealów - forecast zalicza ci 480k. Niezależnie od tego, czy ten 60% ma jakiekolwiek pokrycie w twojej historycznej conversion rate.
To jest matematyka. Jeżeli wejście do funkcji jest zmyślone, wyjście też.
Błąd 1: Domyślne prawdopodobieństwa stage'y (20/40/60/80/100%)
Domyślny pipeline HubSpota ma prawdopodobieństwa rozłożone równomiernie - co stage +20 punktów procentowych. To są placeholdery, nie rekomendacja. Każdy portal który nigdy tego nie ruszył, ma forecast w którym matematyka nie ma związku z conversion rate firmy.
Co zrobić: weź ostatnie 12 miesięcy zamkniętych deali, policz ile dealów ze stage'a X faktycznie zamknęło się jako Won. To jest twoja realna probability. U klientów B2B w PL widzę typowo coś takiego:
| Stage | Default HubSpot | Realna conversion (przykład klienta) |
|---|---|---|
| Appointment Scheduled | 20% | 8% |
| Qualified to Buy | 40% | 22% |
| Presentation Scheduled | 60% | 35% |
| Decision Maker Bought-In | 80% | 55% |
| Contract Sent | 90% | 70% |
Różnica między 60% a 35% w stage'u w którym siedzi 600k PLN dealów to 150k PLN w forecastie. Czyli więcej niż MRR średniego SMB klienta. Jeżeli masz Pipedrive history za sobą - uwaga, Pipedrive pozwala na probability powyżej 100%, HubSpot przy migracji ustawia to na 100%. Sprawdź po Smart Transfer, czy ci się gdzieś nie wkleiła stuprocentowa probability na stage'u, który nie jest Closed Won.
Błąd 2: Brak required properties per deal stage
Required properties per stage to feature Sales Hub Professional, który wymusza wypełnienie konkretnych pól zanim handlowiec przesunie deal do następnego etapu. Bez tego ludzie klikają przez pipeline jak chcą - i forecast zlicza deale, na których nie ma close date, owner, decision maker contact, nic.
Mechanika jest prosta. W Settings -> Objects -> Deals -> Pipelines wybierasz stage, klikasz Edit, dodajesz właściwości jako required. Od tego momentu handlowiec, który próbuje przesunąć deal do tego stage'u bez wypełnionego pola, dostaje błąd.
Co minimalnie wymuszać per stage (rekomendacja z naszych wdrożeń):
- Qualified to Buy: Close Date, Deal Amount, Decision Maker (associated contact), BANT/MEDDIC fields jeżeli używasz
- Presentation Scheduled: Next Activity Date, Competitors (jeżeli śledzicie)
- Contract Sent: Contract document attached (custom property), Legal review status
- Closed Won/Lost: Loss Reason (przy Lost), Won Reason (przy Won) - bez tego nie zrobisz win/loss analysis
Drobiazg który zmienia wszystko: handlowcy nagle muszą faktycznie zakwalifikować deal zanim go ruszą. To boli pierwsze dwa tygodnie. Potem boli forecast, który dla odmiany pokazuje prawdę.
Błąd 3: Brak rotting deals alertu
Deal rotting alert w HubSpot to konfiguracja, która oznacza deal jako "gnijący" gdy nie był zaktualizowany przez zdefiniowaną liczbę dni. Bez tego, deale siedzą w stage'u "Proposal Sent" przez 4 miesiące i ktoś dalej liczy je w forecastie.
Konfiguracja jest per stage. Na Discovery typowo daję 14 dni, na Proposal Sent 21, na Contract Sent 10. Liczby zależą od twojego sales cycle - jeżeli średni cycle to 60 dni, a deal w środkowym stage'u nie ruszył się 30, to znaczy że nie żyje. Deal stage calculated properties (Date entered current stage, Latest time in [stage ID]) są dostępne na Sales Hub Professional i Enterprise - i to one są fundamentem tej mechaniki.
Następny krok: workflow, który przy wykryciu rotting deal'a tworzy task "Follow up albo zamknij jako Lost - [contact name]" przypisany do ownera. Brak zaplanowanej aktywności na aktywnym dealu plus rotting flag to sygnał, że pipeline trzeba przejrzeć - nie jutro, dzisiaj.
Błąd 4: Brak deal stage duration tracking
Bez śledzenia ile czasu deal spędził w każdym stage'u, nie jesteś w stanie odpowiedzieć na podstawowe pytanie: gdzie w pipeline utykają nam deale? A to jest pytanie, które decyduje o tym, gdzie kierujesz coaching, sales enablement, content do handlowców.
HubSpot ma to natywnie - deal stage calculated properties to: Date entered current stage, Date entered [stage ID], Date exited [stage ID], Latest time in [stage ID]. Wszystkie wymagają Sales Hub Professional lub Enterprise. Bez tych właściwości nie zrobisz reportu "Average time in stage" - a to jest pierwszy raport, który pokazuje gdzie się sypie.
Co z tymi danymi zrobić:
- Stwórz custom report: average time in stage, ostatnie 90 dni, breakdown po deal owner
- Porównaj średni czas w stage'ach Won-only vs wszystkich deali. Won-only stages są zwykle szybsze - to twój benchmark
- Stage, w którym non-Won deale siedzą 3x dłużej niż Won deale, to twój wąskie gardło. Tam jest robota
U klienta, który robił 6-tygodniowy sales cycle, średni czas w "Proposal Sent" dla Won = 8 dni. Dla Lost = 34 dni. Czyli jeżeli klient nie odpowiada w 14 dni od oferty, deal jest praktycznie martwy. Z tej jednej liczby zrobiliśmy regułę: rotting alert na Proposal Sent po 14 dniach plus automatyczny task z follow-up template'em.
Błąd 5: Domyślny pipeline bez dopasowania do procesu sprzedaży
Ostatni i największy: używanie default pipeline HubSpota bez modyfikacji. Stage'y "Appointment Scheduled", "Qualified to Buy", "Presentation Scheduled" są generyczne - i większości polskich B2B nie pasują. Producent maszyn ma inny proces niż agencja, agencja ma inny niż SaaS, SaaS ma inny niż gabinet prawny.
HubSpot pozwala na dodawanie, edytowanie i usuwanie stage'y w Settings -> Objects -> Pipelines. To podstawa konfiguracji, którą każdy portal powinien przejść w pierwszym tygodniu po onboardingu. Jeżeli twój proces ma etap "Wizyta techniczna u klienta" albo "Wycena z konstruktorem" - to ma być stage, nie property.
Reguła którą stosuję: stage = moment, w którym deal może utknąć na dni/tygodnie z czekaniem na akcję drugiej strony albo decyzję wewnętrzną. Jeżeli to coś co się dzieje w ciągu godziny, to nie jest stage, to jest task. Mniej stage'y, lepsze sygnały. Cztery do siedmiu stage'y to sweet spot - powyżej dziewięciu, pipeline staje się nieczytelny.
Dla kogo to wszystko jest
Dla Sales / RevOps Leada w B2B SMB, który ma Sales Hub Professional lub Enterprise i czuje że forecast nie zgadza się z rzeczywistością. Dla foundera, który patrzy w dashboard i nie wie, czy 480k PLN na kwartał to prawda. Dla in-house admina, który dostał polecenie "naprawić forecast" i nie wie od czego zacząć.
Required properties per stage, rotting alerts i calculated properties wymagają subskrypcji Sales Hub Professional lub Enterprise. Na Starter część tych mechanik nie zadziała - to jest realne ograniczenie tieru. Natomiast custom stage'y i custom probabilities są dostępne na każdym poziomie, więc błąd 1 i błąd 5 możesz naprawić nawet na Starterze.
Czego ten post NIE rozwiązuje
Nie zastąpi sales coachingu. Jeżeli handlowcy nie potrafią kwalifikować leadów, najlepiej skonfigurowany pipeline ci tego nie naprawi - pokaże tylko czarno na białym, że nie potrafią. Co jest swoją drogą wartością samą w sobie.
Nie rozwiąże problemu attribution. Jeżeli chcesz wiedzieć, który kanał marketingowy generuje najwięcej Won deals, potrzebujesz Marketing Hub Enterprise do revenue attribution na dealach z formularzy. To inna konfiguracja.
Nie naprawi zbyt długiego sales cycle'u. Pokaże ci, gdzie się wydłuża - co zrobić z tą informacją, to praca dla sales managera, nie dla CRM-a.
Jak to ogarnąć w praktyce
Audyt pipeline'u w portalu, którego nikt nie ruszył od 12+ miesięcy, to typowo 4-6 godzin pracy plus warsztat z sales leadem. Realne probabilities trzeba policzyć z historycznych danych, required properties trzeba uzgodnić z zespołem (bo to oni z tym żyją), rotting thresholds zależą od sales cycle, calculated properties trzeba podpiąć pod custom report. To nie jest "klik klik gotowe".
W Spectage robimy to jako audyt portalu HubSpot - karta oceny, lista napraw z priorytetami i szacunkiem pracochłonności. Jeżeli wolisz konsultację bez pełnego audytu, umów discovery call i pogadamy 30 minut o tym, co u ciebie najbardziej cieknie.
