Potrzeba integracji z HubSpot często zaczyna się od prostego pytania: czy da się połączyć CRM z systemem, którego już używamy?
W wielu przypadkach odpowiedź można znaleźć w HubSpot Marketplace. Dostępne aplikacje potrafią zsynchronizować kontakty, przekazać dane z formularza, połączyć kalendarz albo uruchomić działania w innym narzędziu bez pisania własnego kodu.
Problem zaczyna się dopiero wtedy, gdy proces firmy nie mieści się w logice gotowej integracji. Dane mają trafiać tylko dla określonego typu klientów, jeden system używa własnych identyfikatorów, a po zmianie statusu trzeba wykonać kilka operacji w określonej kolejności.
W takim projekcie pytanie nie brzmi już „czy HubSpot ma integrację z tym systemem?”. Trzeba ustalić, czy gotowa aplikacja potrafi obsłużyć konkretny proces.
Dobry punkt wyjścia
Najlepsza integracja nie musi być najbardziej rozbudowana. Powinna obsłużyć proces bez dokładania zespołowi kolejnych obejść.
Dlatego wybór między aplikacją z Marketplace a własną integracją API dobrze zacząć od procesu i danych, a dopiero później od technologii.
1. Gotowa aplikacja jest dobrym wyborem, gdy proces jest standardowy
Jeżeli firma potrzebuje typowej wymiany danych pomiędzy popularnymi systemami, tworzenie własnej integracji od zera często nie ma większego sensu.
Dobra aplikacja z HubSpot Marketplace ma już przygotowaną autoryzację, obsługę podstawowych obiektów i mechanizm synchronizacji. Dostawca odpowiada również za dostosowanie rozwiązania do zmian po stronie API.
To pozwala uruchomić integrację znacznie szybciej niż przy tworzeniu własnego rozwiązania.
Jeżeli gotowa aplikacja pokrywa cały potrzebny przepływ danych, własne API może tylko podnieść koszt utrzymania rozwiązania.
Przed instalacją warto jednak sprawdzić coś więcej niż samą obecność aplikacji w Marketplace. Dwie integracje łączące te same systemy mogą obsługiwać zupełnie inny zakres danych.
2. Sam napis „integruje się z HubSpot” niewiele mówi
Załóżmy, że firma chce połączyć HubSpot z systemem do obsługi płatności. Gotowa aplikacja istnieje, więc na pierwszy rzut oka temat wydaje się zamknięty.
Po sprawdzeniu dokumentacji okazuje się jednak, że integracja potrafi utworzyć kontakt i zapisać informację o transakcji, ale nie przekazuje statusu płatności do właściwości wykorzystywanej przez dział sprzedaży.
Technicznie systemy są połączone. Biznesowo brakuje informacji, dla której integracja miała powstać.
Przed instalacją
Warto sprawdzić konkretne obiekty i pola, kierunek synchronizacji, częstotliwość aktualizacji oraz zachowanie integracji po zmianie danych w obu systemach. Nazwa integracji nie odpowiada na żadne z tych pytań.
Dopiero taki przegląd pozwala ocenić, czy aplikacja rzeczywiście obsłuży proces bez dodatkowej pracy ręcznej.
3. API zaczyna mieć sens, gdy logika firmy nie mieści się w gotowym konektorze
Gotowe integracje są projektowane tak, żeby działały u możliwie dużej liczby klientów. Z tego powodu zwykle obsługują najbardziej typowe scenariusze.
Firma może jednak potrzebować własnych zasad. Rekord ma zostać przekazany dopiero po spełnieniu określonych warunków. Dla jednej grupy klientów trzeba uruchomić inny proces niż dla pozostałych. Aktualizacja w ERP ma zmienić kilka rekordów powiązanych w HubSpot.
W takich sytuacjach nie chodzi już o prostą synchronizację dwóch tabel. Integracja zaczyna obsługiwać fragment procesu biznesowego.
API daje możliwość dopasowania integracji do własnego modelu danych, własnych identyfikatorów i reguł procesu. Cena tej elastyczności to konieczność zaprojektowania, utrzymania i monitorowania rozwiązania.
4. Najpierw trzeba ustalić, który system odpowiada za dane
Jednym z najczęstszych problemów nie jest sama komunikacja między systemami. Problemem jest brak decyzji, gdzie dana informacja powinna być zarządzana.
Adres klienta istnieje w HubSpot i ERP. Użytkownik poprawia go w CRM. Godzinę później ERP wysyła podczas synchronizacji starszą wartość i zmiana znika.
Oba systemy zadziałały zgodnie z konfiguracją. Błąd powstał wcześniej, przy projektowaniu zasad wymiany danych.
Źródło prawdy
Dla każdej ważnej informacji powinno być wiadomo, w którym systemie powstaje i który system może ją zmieniać.
Dopiero później można określić kierunek synchronizacji. Bez tego nawet bardzo dobra integracja API może tylko szybciej przenosić niespójne dane.
5. Synchronizacja dwukierunkowa nie zawsze jest zaletą
W opisach aplikacji możliwość synchronizacji w obie strony brzmi zwykle jak bardziej rozbudowana funkcja. W praktyce nie każda informacja powinna poruszać się w obu kierunkach.
Status płatności może pochodzić wyłącznie z księgowości. Wartość umowy może być ustalana w systemie ERP. HubSpot może potrzebować tych danych do segmentacji, raportowania albo uruchamiania workflow, ale nie musi mieć prawa ich modyfikować.
Więcej kierunków synchronizacji oznacza więcej miejsc, w których trzeba rozstrzygnąć konflikt pomiędzy danymi.
Jeżeli proces wymaga tylko przekazania informacji do HubSpot, prostsza integracja jednokierunkowa może być bardziej przewidywalna i łatwiejsza w utrzymaniu.
6. Własne API wymaga obsługi sytuacji, w których wszystko nie działa idealnie
Pierwsza wersja integracji często jest testowana na prostym scenariuszu. HubSpot wysyła dane, drugi system odpowiada poprawnie, rekord zostaje zaktualizowany.
Produkcja wygląda inaczej. API może chwilowo zwrócić błąd. HubSpot może ograniczyć liczbę żądań. Ten sam webhook może pojawić się drugi raz. Połączenie może zostać przerwane w połowie procesu.
Jeżeli integracja obsługuje istotny fragment sprzedaży albo obsługi klienta, takie przypadki muszą być częścią projektu.
Przykład z produkcji
System otrzymuje informację o podpisanej umowie i ma zaktualizować HubSpot. W tym momencie API zwraca 429. Jeżeli integracja nie ma mechanizmu ponowienia operacji, klient może pozostać w starym statusie mimo poprawnie zakończonego procesu po drugiej stronie.
Więcej o samych limitach pisaliśmy w artykule HubSpot API - limity i rate limiting.
7. Integracja bez monitoringu może nie działać przez kilka dni i nikt tego nie zauważy
Błąd formularza użytkownik zwykle zobaczy od razu. Błąd integracji działającej w tle może pozostać niewidoczny znacznie dłużej.
Dane przestają aktualizować się w poniedziałek, ale pierwszy sygnał pojawia się dopiero w czwartek, gdy handlowiec zauważy brak nowego statusu na rekordzie klienta.
Dlatego własne rozwiązanie powinno pozwalać ustalić, czy operacja się udała, którego rekordu dotyczył błąd i czy system spróbował wykonać ją ponownie.
Przy integracji obsługującej kilkadziesiąt operacji miesięcznie ręczne sprawdzenie błędu może być wykonalne. Przy tysiącach operacji potrzebny jest monitoring, logi i możliwość odnalezienia konkretnego przypadku.
8. Pomiędzy gotową aplikacją a własnym API jest jeszcze middleware
Nie każdy przypadek wymaga budowania osobnej aplikacji od zera.
Jeżeli proces składa się głównie z przekazywania danych pomiędzy kilkoma usługami, rozwiązaniem może być warstwa pośrednia oparta na narzędziu automatyzacyjnym.
Pozwala to dodać warunki, mapowanie danych albo kilka kolejnych kroków bez utrzymywania pełnej aplikacji. Jednocześnie taki model nadal wymaga rozsądnego projektu, szczególnie gdy przepływ staje się krytyczny dla działania firmy.
Jeżeli automatyzacja w narzędziu no-code zaczyna zawierać dziesiątki warunków, własne kolejki, skomplikowane retry i dużą liczbę transformacji danych, warto sprawdzić, czy prostsze nie będzie przeniesienie części logiki do kodu.
Kiedy wybrać gotową aplikację, a kiedy własną integrację?
Gotowa aplikacja
Ma najwięcej sensu, gdy dostępny konektor obsługuje potrzebne obiekty i pola, proces nie wymaga nietypowej logiki, a sposób synchronizacji oferowany przez dostawcę odpowiada temu, jak firma pracuje.
Warstwa pośrednia
Sprawdza się przy umiarkowanie niestandardowych przepływach, w których trzeba połączyć kilka usług, przekształcić dane albo dodać własne warunki, ale nie ma potrzeby tworzenia dużego rozwiązania programistycznego.
Własne API
Jest uzasadnione, gdy integracja obsługuje własny model danych, niestandardową logikę biznesową, większą skalę operacji albo proces, którego działanie trzeba dokładnie kontrolować i monitorować.
Najdroższa integracja to często ta, którą trzeba obejść ręcznie
Gotowy konektor może być tańszy od własnego rozwiązania, ale tylko wtedy, gdy rzeczywiście rozwiązuje problem.
Jeżeli po wdrożeniu pracownik nadal codziennie eksportuje rekordy, poprawia dane w arkuszu i ręcznie przenosi wyjątki do drugiego systemu, koszt integracji nie kończy się na opłacie za aplikację.
Z drugiej strony własne API napisane dla procesu, który dobrze obsługuje istniejąca aplikacja, również nie daje dodatkowej wartości. Dochodzi hosting, monitoring, utrzymanie kodu i odpowiedzialność za każdą zmianę.
Decyzję najlepiej podejmować na podstawie kosztu całego procesu po wdrożeniu, nie wyłącznie ceny samego konektora albo liczby godzin programistycznych.
Integracja powinna wynikać z architektury całego wdrożenia
Jeżeli HubSpot ma być głównym CRM firmy, dobrze ustalić rolę pozostałych systemów jeszcze podczas projektowania wdrożenia. Pozwala to uniknąć sytuacji, w której kolejne integracje powstają niezależnie i każda korzysta z innych zasad wymiany danych.
Więcej o samym projektowaniu CRM opisaliśmy w artykule Wdrożenie HubSpot krok po kroku.
Integracje HubSpot w Velmanta
Zaczynamy od przepływu danych, a nie od wyboru technologii
Przy projektowaniu integracji sprawdzamy najpierw, jakie informacje mają przepływać pomiędzy systemami, kto odpowiada za ich wartość i co powinno wydarzyć się po zmianie rekordu.
Jeżeli gotowa aplikacja dobrze obsługuje taki proces, nie ma potrzeby zastępować jej własnym rozwiązaniem. Gdy potrzebna jest niestandardowa logika, projektujemy integrację przez API z obsługą błędów, limitów i monitoringu.
Porozmawiajmy o integracji HubSpotNajczęstsze pytania o integracje HubSpot
Czy każda integracja HubSpot wymaga programowania?
Nie. W HubSpot Marketplace dostępnych jest wiele gotowych aplikacji, które można uruchomić bez tworzenia własnego kodu. Programowanie staje się potrzebne przede wszystkim wtedy, gdy proces wymaga własnej logiki lub zakres danych nie jest obsługiwany przez dostępne rozwiązanie.
Kiedy warto zbudować własną integrację HubSpot API?
Najczęściej wtedy, gdy potrzebne są niestandardowe zasady synchronizacji, własne obiekty lub identyfikatory, większa kontrola nad błędami albo integracja ma obsługiwać ważny fragment procesu biznesowego.
Czy HubSpot może integrować się z własnym systemem firmy?
Tak, jeżeli system posiada odpowiedni interfejs wymiany danych lub możliwe jest przygotowanie go po jego stronie. Zakres integracji zależy od danych i operacji, które udostępniają oba systemy.
Czy integracja powinna synchronizować dane w obie strony?
Nie zawsze. Kierunek powinien wynikać z tego, który system odpowiada za daną informację. W wielu procesach bezpieczniejsza jest synchronizacja jednokierunkowa niż możliwość zmiany tej samej wartości w dwóch różnych miejscach.
Co trzeba monitorować w integracji API?
Przede wszystkim poprawność wykonania operacji i błędy zwracane przez oba systemy. Przy większej skali warto również wiedzieć, którego rekordu dotyczył problem, ile razy operacja została ponowiona i czy wymaga ręcznej interwencji.
Komentarze