Jaki problem to rozwiązuje
Każdy handlowiec prowadzi deale po swojemu: etapy znaczą co innego dla różnych osób, deale gniją na Wysłano ofertę przez jedenaście miesięcy, daty zamknięcia przesuwają się co tydzień, a liczba pipeline'u zmienia się w zależności od tego, kogo zapytasz. Managerowie coachują na ślepo, bo CRM zapisuje wyniki, a nie proces - a pipeline, któremu nikt nie ufa, staje się pipeline'em, którego nikt nie utrzymuje.
Jak pracujemy
Projektujemy pipeline wokół tego, jak Twoi klienci faktycznie kupują, a nie wokół domyślnych ustawień HubSpota czy życzeniowych nazw etapów. Każdy etap dostaje obserwowalne kryterium wejścia - coś, co albo się wydarzyło, albo nie - żeby dwóch handlowców patrzących na ten sam deal umieściło go w tym samym miejscu. Różne ruchy - nowy biznes, odnowienia, ze źródeł partnerskich - dostają osobne pipeline'y, gdy ich etapy naprawdę się różnią, nie wcześniej.
Potem wdrażamy dyscyplinę w Sales Hub, żeby nie zależała od pamięci: wymagane właściwości przy przejściach etapów, automatyzacja stemplująca daty i tworząca zadania follow-up, alerty o gnijących dealach oraz widoki pokazujące każdemu handlowcowi dokładnie, co wymaga uwagi dzisiaj. System czyni właściwe zachowanie łatwym zachowaniem.
Testujemy z zespołem na żywych dealach przed rolloutem, bo pipeline, który działa tylko na warsztacie, jest deliverablem warsztatowym, a nie procesem sprzedaży.
Deliverables
- Architektura pipeline'u i etapów z obserwowalnymi kryteriami wejścia
- Wymagane właściwości egzekwowane przy przejściach etapów
- Automatyzacja etapów: stemplowanie dat, zadania i powiadomienia
- Alerty o gnijących dealach i higienie kolejnych kroków
- Robocze widoki handlowca i managera
- Przejście po żywych dealach i rollout z zespołem