Jaki problem to rozwiązuje
Dane o przychodzie i dane o kliencie żyją w dwóch różnych światach. Deale zamykają się w HubSpot, potem płatność dzieje się w osobnym narzędziu, a nikt nie umie odpowiedzieć na proste pytanie w rodzaju czy ten klient faktycznie zapłacił, bez otwierania trzech kart. Ustawienie Revenue Hub źle u fundamentu - zły procesor, podatek potraktowany po fakcie, brak czystego modelu obiektów - znaczy, że każda oferta i faktura zbudowana na tym dziedziczy bałagan.
Jak pracujemy
Pierwsza uczciwa rozmowa jest o przetwarzaniu płatności, bo ono determinuje wszystko poniżej. Natywny procesor płatności HubSpot działa tylko w USA; dla firmy w Polsce lub szerszej UE Revenue Hub działa na Stripe podłączonym jako procesor. Potwierdzamy, która ścieżka Cię dotyczy, łączymy ją poprawnie i konfigurujemy waluty oraz ustawienia podatkowe, których faktycznie wymaga Twoja sprzedaż, a nie domyślne.
Potem porządnie stawiamy fundament Revenue Hub: obiekty produktu, pozycji, oferty, faktury i subskrypcji podpięte tak, żeby rekordy łączyły się z powrotem z firmami, kontaktami i dealami, a nie unosiły luźno. Wcześnie decydujemy, co jest źródłem prawdy o płacącym kliencie, żeby raportowanie później było odczytem, a nie kłótnią.
Revenue Hub to dla nas nowszy grunt niż praca w Sales i Marketing, którą prowadzimy od 2021, więc wyceniamy go świadomie i mówimy, gdzie wymaganie wypycha poza to, co warstwa Revenue Hub robi natywnie - zanim na tym zbudujesz, a nie po.
Deliverables
- Podłączony procesor płatności: Stripe dla UE lub natywny HubSpot Payments tam, gdzie kwalifikuje
- Waluty i ustawienia podatkowe skonfigurowane pod Twoją sprzedaż
- Model obiektów Revenue Hub podpięty do rekordów CRM
- Decyzja o źródle prawdy dla płacących i niepłacących klientów
- Transakcje testowe przeprowadzone od początku do końca przed go-live
- Udokumentowany fundament, na którym staną oferty, faktury i subskrypcje