Stripe i HubSpot: co naprawdę musi wpaść do CRM, a co tylko podbija rachunek

Do prostego syncu płatności na kontakt konektor wystarcza i sami go ustawiamy. Jesteśmy potrzebni tam, gdzie natywny most się kończy: własne mapowanie subskrypcji, zdarzenia, których konektor nie przenosi, oraz decyzja, które dane w ogóle mają wchodzić do CRM. To ostatnie ma wymiar kosztowy, bo obiekty w HubSpocie nie są darmowe.

Tak i często tak jest taniej. Dane, których sprzedaż nie ogląda, nie muszą przechodzić przez CRM: pozycje rozliczeniowe, historia prób obciążenia, szczegóły faktur. Prowadzimy je ze Stripe wprost do hurtowni albo do systemu księgowego, a w HubSpocie zostawiamy warstwę, na której ktoś naprawdę pracuje. CRM zostaje czysty, rachunek przewidywalny.

To dwa osobne scenariusze. Sync danych przenosi do HubSpota informacje o klientach, płatnościach i subskrypcjach, ale płatności dalej idą przez Stripe i nie są przetwarzane w HubSpocie. Podpięcie Stripe jako procesora sprawia, że płatności przechodzą przez obiekty HubSpota. Źródło: HubSpot Knowledge Base.

Nie. HubSpot payments i Stripe nie mogą być podpięte do HubSpota jednocześnie jako procesor. Trzeba wybrać jeden, a jeżeli już masz HubSpot payments, jest osobna ścieżka przejścia na Stripe. Ustalamy to na starcie, żeby nie przepinać w połowie projektu. Źródło: HubSpot Knowledge Base.

Istniejące subskrypcje Stripe da się przenieść do HubSpota w momencie podpinania Stripe jako procesora. HubSpot ma osobną ścieżkę do migracji subskrypcji przy okazji łączenia kont. Planujemy to jako czyste cięcie, nie jako okres przejściowy, w którym dane wypadają z synchronizacji. Źródło: HubSpot Knowledge Base.

Tak. Gdy natywny sync nie mapuje danych tak, jak potrzebujesz, albo chcesz reagować na konkretne eventy Stripe, budujemy integrację na Stripe webhookach i HubSpot API. Piszemy własny kod w Node albo Pythonie i wpinamy go w workflowy HubSpota. Więcej na stronie automatyzacji.

Ustalamy reguły dopasowania przed pierwszym syncem, zwykle po mailu, i decydujemy, co się dzieje przy konflikcie. Klient Stripe zderza się z jednym rekordem w CRM, a ID Stripe trzymamy w osobnym property. Bez tego co tydzień wpadałyby duplikaty z każdej nowej płatności.

Tak, pod warunkiem że obiekty są powiązane. Gdy płatność i subskrypcja są spięte z dealem i kontaktem, kreator raportów zestawi przychód z pipeline i źródłem leada bez eksportu do arkusza. Jeżeli relacje są zerwane, raport pokaże liczby, które nie kleją się z rzeczywistością.

Zależy od scenariusza. Sam sync danych gotowym konektorem to kwestia konfiguracji i uzgodnienia mapowania. Custom na webhookach z regułami deduplikacji i triggerami wymaga więcej pracy, bo projektujemy logikę pod Twój proces. Na discovery przechodzimy przez Twój stack i wracamy z kierunkową oceną zakresu.