Nie buduj, nie integruj — przewodnik po integracji z CRM

Załóżmy, że pracujesz dla startupu, który sprzedaje roboty we wszystkich branżach. Przyjmujesz zamówienia od różnych klientów, a zespół operacyjny ocenia zamówienia i współpracuje z dostawcami zewnętrznymi, aby zapewnić klientom odpowiedniego robota.

Budowanie MVP było stresujące, ale też dostarczało dużo frajdy. Twoi inwestorzy są podekscytowani i zasypują Cię pieniędzmi. Rozpoczyna się kolejna faza. Potrzebujesz większej widoczności rentowności i chcesz pozyskać większych klientów, którzy potrzebują bardziej wyrafinowanego fakturowania. Jednocześnie masz dość wyrafinowaną mapę drogową produktu, która umożliwia sprzedaż robotów o wyższych marżach. Zasoby są ograniczone, ale nadal musisz zadbać o to, aby firma działała.

Jak często głoszono w mniejszych firmach, skupienie się na tym, w czym jesteś dobry, jest świetną praktyczną zasadą. Ale co ze wszystkimi obszarami, w których działa codzienna działalność Twojej firmy? Na pewno nie chcesz budować systemu zarządzania relacjami z klientami (CRM) ani systemu księgowego. W końcu istnieje wiele produktów, które rozwiązują wszystkie problemy. Ale jak te systemy będą współpracować z istniejącym systemem zamówień?

Tutaj przydaje się integracja z innymi firmami. Zanurzmy się więc i zobaczmy, czy możemy uniknąć niektórych typowych pułapek.

Integracja z CRM

Niezależnie od tego, czy prowadzisz sprzedaż typu low-touch (marketing treści, reklamy w mediach społecznościowych lub biuletyny), czy też sprzedaż typu high-touch (rozmowy telefoniczne, udział w konferencjach lub kontakt telefoniczny z istniejącymi klientami), system CRM może zapewnić Ci wiele wgląd w to, jak radzisz sobie z istniejącymi klientami i jak skutecznie przekonujesz nowych klientów.

Często wybór systemu CRM w większości pozostawia się działowi sprzedaży i marketingu. Generalnie nie ma w tym nic złego. W końcu ci ludzie wiedzą najlepiej, jak zwiększyć przychody i potrzebują najlepszego dostępnego wsparcia. Ale nawet najlepsze oprogramowanie jest nic nie warte, jeśli nie współpracuje prawidłowo z systemem zamawiania robotów.

Uwzględnij swój dział techniczny w decyzji

Niezależnie od tego, czy jest to CTO, czy oddany inżynier, informuj ich na bieżąco od samego początku. Jest bardzo prawdopodobne, że dadzą ci lepszy wgląd w to, jak te dwa systemy będą ze sobą współpracować w przyszłości.

I słowo dla inżynierów: miej otwarty umysł na rozwiązania innych firm. Łatwo je odrzucić, ponieważ ich interfejs API nie jest najlepszy lub ich interfejs użytkownika jest brzydki. Jednak znalezienie eleganckich rozwiązań wokół istniejących systemów może być bardzo satysfakcjonujące.

Niemniej jednak istnieje kilka tematów, o których warto porozmawiać przed podjęciem decyzji. Ogólne tematy, takie jak „Czy w ogóle tego potrzebujemy?” musi być zaadresowany. Ale dobrze jest też mieć już pojęcie o tym, jaki jest zakres. Czy istnieje potrzeba synchronizacji dwukierunkowej, czy system innej firmy po prostu będzie podążał za systemem zamówień? Gdy zakres zostanie usunięty, musi również odbyć się techniczna dyskusja na temat szczegółów implementacji, takich jak webhook lub ocena limitów interfejsu API.

Czy w ogóle potrzebujesz niestandardowej integracji?

Jeśli chodzi o integrację, nie dziwi fakt, że istnieją już platformy, które obiecują rozwiązanie niektórych problemów, które możesz napotkać. Obecnie najbardziej obiecujące są Zapier i IFTTT.

W zależności od problemu, który próbujesz rozwiązać, Twój system zamówień robotów może nawet nie być zaangażowany w integrację. Załóżmy, że zarządzasz subskrybentami biuletynu za pomocą systemu CRM, takiego jak Salesforce lub HubSpot i po prostu chcesz wygodniejszego kontaktu z nimi za pośrednictwem dostawcy usług poczty e-mail, takiego jak Mailchimp, Zapier ma mnóstwo istniejących integracji, które mogą Ci w tym pomóc. Od tego momentu wybór dostawcy, który ma złącze Zapier, jest dobrym rozwiązaniem.

A nawet jeśli chodzi o integrację niestandardowych danych (zamówionych robotów i ich ceny), Zapier Webhooks może pełnić rolę pośrednika w Twojej integracji.

Z drugiej strony, jeśli już wysyłasz dane do osoby trzeciej, dlaczego nie wysłać ich bezpośrednio do systemu CRM? Im więcej danych chcesz zsynchronizować, tym bardziej użyteczna będzie integracja bezpośrednia.

Co prowadzi mnie do następnego punktu.

Czy potrzebujesz synchronizacji dwukierunkowej?

Zwykle integracja zaczyna się od prostego wymagania, takiego jak Czy możemy wprowadzić wszystkich naszych klientów do naszego systemu CRM? , zazwyczaj w połączeniu z wartościami poszczególnych zamówień robotów, co ułatwia korzystanie z narzędzi do segmentacji klientów.

Jednak prędzej czy później może się zdarzyć, że ludzie będą chcieli skorzystać z narzędzi do zarządzania kontaktami, które zazwyczaj oferuje pakiet CRM. Należą do nich funkcje takie jak deduplikacja, zmiana danych kontaktowych za pomocą danych z mediów społecznościowych, normalizacja adresów wysyłkowych lub po prostu usuwanie starych kontaktów.

Zmiana kontaktów w systemie CRM najprawdopodobniej będzie oznaczać konieczność zmiany danych kontaktowych w innym systemie, czyli zmiany muszą przebiegać w obie strony.

Wysiłek związany z wdrożeniem wykracza daleko poza prostą synchronizację jednokierunkową, więc jest to doskonały punkt do przemyślenia, w jaki sposób chcesz strategicznie korzystać z nowego systemu.

Jak będziesz powiadamiany o zmianach z CRM?

Jeśli zdecydujesz się na synchronizację dwukierunkową, pojawi się dodatkowe pytanie: Skąd wiesz, że coś się zmieniło po stronie CRM?

Większość dostawców systemów ma do tego narzędzia, ale najlepszym rozwiązaniem do natychmiastowych zmian są webhooki — zasadniczo system powiadomień HTTP, który można skonfigurować tak, aby informował o odpowiednich zmianach (w przypadku niektórych systemów nawet w poszczególnych polach) .

Jeśli system nie oferuje webhooków, przynajmniej sprawdź, czy możesz uzyskać listę wszystkich encji, które zostały ostatnio zaktualizowane. W ten sposób nie musisz przeglądać wszystkich kontaktów i transakcji tylko po to, aby zaktualizować własne dane. Pamiętaj jednak, że będziesz musiał regularnie odpytywać system.

W takim przypadku Twój system zamówień nadal będzie się zmieniał i tworzył dane za pomocą wywołania API w systemie CRM. Ale wszystkie zmiany z systemu CRM byłyby odpytywane w określonym przedziale czasu.

Warto zauważyć, że aktualizacje będą ograniczone do tego interwału i mogą prowadzić do tymczasowej niespójności danych. Na przykład, gdy synchronizujesz system CRM z systemem zamówień tylko raz dziennie, dane, które przeglądasz w systemie zamówień, mogą mieć nawet 24 godziny.

W zależności od tego, jakie funkcje oferuje system, zadanie integracji może różnić się złożonością i czasem wdrożenia. Sprawdź z wyprzedzeniem, co oferuje system i dokładnie sprawdź plan, który zamierzasz kupić. Na przykład niektóre systemy CRM oferują webhooki na wyższych poziomach.

Przykładem jest tutaj CRM HubSpot, który ogólnie oferuje webhooki, ale funkcja webhooka jest dostępna tylko w pakiecie Enterprise. Narzędzia księgowe Zoho Books będą oferować pięć zautomatyzowanych przepływów pracy (w tym webhooki) na najniższym poziomie.

Czy Twoje dane są w dobrym stanie?

Jeśli chodzi o tworzenie zbiorów danych w systemie zewnętrznym, dobrze jest wiedzieć, jak dane wyglądają we własnym systemie. Na szczęście nie ma zbyt wielu różnych sposobów prezentowania kontaktów i transakcji, ale jednym polem, które zawsze sprawia kłopoty, jest pole e-mail.

Różne systemy mają różne wyobrażenia o tym, czym jest prawidłowy adres e-mail, a oto alert spoilera — Twoi klienci mogli podać nieprawidłowe adresy e-mail wszelkiego rodzaju. Wiele systemów CRM odrzuci utworzenie kontaktu z nieprawidłowym adresem e-mail (i oczywiście dostawca CRM określa, co jest prawidłowe, a co nie).

Wskazówka: Jeśli to możliwe, synchronizuj tylko potwierdzone adresy e-mail z CRM. To na dłuższą metę zaoszczędzi ci wiele bólu.

Ograniczenia API

Wreszcie, ograniczenia API to coś, co należy rozwiązać tak szybko, jak to możliwe.

Zakładając, że istnieje API (które jest w zasadzie niezbędne w każdej integracji), warto przyjrzeć się ograniczeniom API. Większość startupów radzi sobie z podstawowymi ograniczeniami API większości systemów CRM. Na przykład HubSpot oferuje 250 000 wywołań interfejsu API na okres 24 godzin, nawet w warstwie bezpłatnej. Z drugiej strony ogranicza również połączenia do 10 na sekundę (100, jeśli używasz OAuth). Lider rynku Salesforce pozwala tylko na 100 000 co 24 godziny, ale oferuje więcej zakupów.

W większości przypadków łatwo wpadniesz w te ograniczenia, ale należy wziąć pod uwagę jedną rzecz: A co z pierwszym biegiem? Na początku będziesz przepychać wiele kontaktów i ofert do swojego CRM (i prawdopodobnie wiele razy, jeśli wystąpią problemy). W rezultacie możesz osiągnąć dzienny limit API.

Aby to złagodzić, możesz przetestować na małym zestawie danych i powoli zwiększać ich liczbę w trakcie implementacji, aby pozostać w limicie API. W przypadku początkowej migracji zaplanuj ją na kilka dni lub na weekend. Ewentualnie skontaktuj się z dostawcą i poinformuj go o swoich intencjach. Kiedy jesteś w fazie ewaluacji (i nie zapłaciłeś jeszcze za system), mogą chcieć nieco zwiększyć Twój przydział API.

Wdrożenie CRM

Powiedzmy, że wszyscy się zgadzacie. Wybrałeś świetne narzędzie CRM, a inżynierowie są przekonani, że można je dość łatwo zintegrować. Zdecydowałeś się na określenie zakresu, aby tylko przesyłać dane klientów i akceptować zamówienia robotów. Dlatego synchronizacja dwukierunkowa nie jest konieczna, a zmiany adresu będą obsługiwane tylko we własnym systemie zamówień.

W fazie wdrażania nadal należy przestrzegać kilku najlepszych praktyk.

Wypróbuj wszystko w środowisku testowym

W większości przypadków system CRM będzie używany dopiero po zakończeniu integracji i gotowości do użycia. W tym przypadku użycia może wydawać się atrakcyjne, aby po prostu użyć systemu produkcyjnego podczas programowania. W końcu nie ma danych produkcyjnych, na które mógłbyś mieć wpływ. Po zakończeniu programowania po prostu usuniesz wszystkie utworzone dane testowe, uruchomisz początkową migrację i skierujesz system zamówień do tego środowiska.

Z tym podejściem wiąże się kilka problemów:

1. Po prostu kopiesz puszkę w dół. Nawet jeśli Twoje uruchomienie pójdzie gładko, prędzej czy później pojawi się prośba o zmianę części integracji. Biorąc pod uwagę, że żądanie funkcji jest wystarczająco duże, prawdopodobnie będziesz potrzebować kolejnej fazy testowania. W tym momencie oddzielny system testowania jest nieunikniony; w przeciwnym razie możesz zepsuć dane produkcyjne. Po co więc czekać z konfiguracją, aż zostaniesz poproszony o zaimplementowanie pierwszej funkcji?

   

2. Skończysz z niechlujną konfiguracją. Jest bardzo prawdopodobne, że Twój system CRM wymaga jakiejś konfiguracji, aby dopasować ją do potrzeb Twojego systemu zamówień. Nazwy statusów mogą wymagać dostosowania, zwykle trzeba utworzyć pola niestandardowe i tak dalej. Ponieważ większość programistów będzie musiała przyzwyczaić się do systemu CRM, zostanie dodana konfiguracja, która nie jest potrzebna na dłuższą metę. W rzeczywistości ta nieużywana konfiguracja nie jest później usuwana i może nawet pozostać w Twoim CRM na zawsze. Wymuszając dodatkowy krok replikacji konfiguracji z systemu testowego do produkcji, najprawdopodobniej uzyskasz szczuplejszą konfigurację w swoim systemie produkcyjnym.
   
   Należy zauważyć, że może to również działać na twoją niekorzyść, jeśli zapomnisz skopiować konfigurację z testu do systemu produkcyjnego, a skończysz z błędami produkcyjnymi.
   
   Chociaż istnieje kilka systemów CRM, które pomogą Ci porównywać i kopiować elementy konfiguracji, ogólnie rzecz biorąc, przydatne będzie zapisanie konfiguracji, aby nie zapomnieć o kluczowych elementach. Większość CRM dostarcza do swojej konfiguracji API, dzięki czemu można zautomatyzować ten krok.

3. Narażasz się na większe ryzyko zanieczyszczenia danych produkcyjnych. Wyobraź sobie przez sekundę dwóch programistów pracujących nad integracją. Masz już system stopniowania systemu zamówień robotów. Ta inscenizacja jest również połączona z Twoim CRM. Po wysłaniu integracji musisz pamiętać o odłączeniu wszystkich trzech systemów, w przeciwnym razie możesz utworzyć dane testowe w swoim (teraz) produkcyjnym CRM.

Wszystkich tych problemów można uniknąć, tworząc od początku system testowy. Produkcja pojawia się dopiero na samym końcu, tuż przed wejściem na żywo. W ten sposób uzyskasz czystą konfigurację, nie ryzykujesz, że zapomnisz o odłączeniu systemów lokalnych i będziesz mieć czujność podczas wdrażania nowych funkcji.

Zdefiniuj identyfikator dopasowywania jednostek

Teraz zacznijmy pisać właściwy kod integracji. Weźmy za przykład synchronizację kontaktów z systemem CRM. Przypuszczalnie będziesz musiał utworzyć nowe kontakty i zaktualizować istniejące. Aby odróżnić tworzenie od aktualizacji, musisz połączyć te dwie jednostki. W ten sposób możesz sprawdzić, czy kontakt w Twoim systemie istnieje w systemie zewnętrznym.

Chociaż wydaje się atrakcyjne samo użycie adresu e-mail (w końcu jest to powszechny identyfikator rekordu kontaktu), istnieje bardziej ogólne rozwiązanie — dla każdego rekordu synchronizujesz się z zewnętrzną blokadą systemu i identyfikatorem we własnej bazie danych.

Zmień więc swoją tabelę kontaktów o kolumnę o nazwie crm_id lub external_id . Takie podejście ma kilka zalet:

• Ponieważ jest to identyfikator, nie zmieni się (w przeciwieństwie do adresu e-mail lub numeru telefonu).
• Możesz sprawdzić, czy musisz utworzyć lub zaktualizować encję bez wcześniejszego wywołania interfejsu API (jeśli pole identyfikatora zewnętrznego jest puste, możesz założyć, że kontakt nie istnieje).

Zanim:

Później:

Załóżmy na przykład, że jesteś programistą Ruby on Rails pracującym nad aplikacją, która musi zsynchronizować istniejących i nowych klientów z HubSpot.

Uproszczony przykład kodu może wyglądać tak:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Zwróć uwagę, w jaki sposób korzystamy z zapisywania identyfikatora firmy, który jest zwracany z companyId . Nie tylko pomaga nam określić, czy chcemy zaktualizować lub utworzyć firmę w HubSpot, ale także możemy zobaczyć w tabeli bazy danych, które encje są już zsynchronizowane z HubSpot, a których nadal brakuje.

Jeśli chodzi o mapowanie pól, wybierz Freestyle

Widziałem projekty, w których wdrożenie poprzedzone jest stworzeniem gigantycznego arkusza Excela określającego, które kolumny w systemie CRM przechodzą, z adnotacjami o tym, jak dane powinny być przekształcane.

W rzeczywistości istnieje tylko kilka sposobów reprezentowania kontaktów i transakcji. Więc zamiast spędzać dużo czasu na zastanawianiu się, jak dokładnie chcesz zmapować, dlaczego nie zacząć od eksperymentu? Daj programiście trochę miejsca na zaprojektowanie mapowania, ale także pozostań w kontakcie, aby pytania mogły pojawić się wcześnie.

Przynajmniej dla ogólnych pól kontaktowych (imię i nazwisko, adres e-mail, numer telefonu, adres) mapowanie będzie bardzo proste, a przekształcenia są zazwyczaj trywialne.

Jeśli chodzi o mapowanie statusów dla transakcji, pomocna jest nieco większa komunikacja (czasami pierwszy status nazywa się open , czasem new , a czasem model statusu nie jest zgodny w 100%, więc będziesz musiał grupować statusy razem ). Zamiast wymyślać idealne rozwiązanie, spójrz na swoje aktualne dane i zobacz, jak najlepiej pasowałoby do modelu danych CRM. W końcu jesteś zwinną firmą, prawda?

W powyższym przykładzie możesz zobaczyć metodę map, która konwertuje nasz model Rails na zwykły hash, który jest rozumiany przez HubSpot. W tym konkretnym przypadku jedynym zsynchronizowanym elementem jest nazwa. W przypadku bardziej zaawansowanych zastosowań prawdopodobnie chcesz uwzględnić więcej pól, ale aby uzyskać doskonały wynik, zacznij od wykształconego przypuszczenia i często komunikuj się ze stroną biznesową w celu uzyskania szczegółów.

Rozważ ponowne próby

Przejdźmy do bardziej technicznego poziomu: wdrożenie rzeczywistej synchronizacji między Twoim systemem a CRM. To prawie oczywiste, że integracja odbędzie się przez połączenie HTTP. Większość systemów udostępnia interfejs API HTTP, a wszystkie języki programowania umożliwiają bardzo łatwe wykonywanie wywołań HTTP.

Niestety, bez względu na to, ile pieniędzy wydasz na system CRM, ostatecznie nie będzie on osiągalny. To się stanie w pewnym momencie i nic nie możesz na to poradzić. Więc równie dobrze możesz to uwzględnić, gdy rozwijasz swoją integrację.

W praktyce oznacza to, że za każdym razem, gdy wywołujesz API, upewnij się, że Twoje wywołanie jest ponawiane w przypadku problemu (500 kodów statusu z drugiej strony). Implementacja ponownych prób jest zwykle dostarczana przez biblioteki innych firm w wybranym języku.

Oprócz ponawiania próby możesz rozważyć rejestrowanie tego, co dokładnie się wydarzyło. Otrzymanie powiadomienia o błędzie, który został już rozwiązany przy pierwszej próbie, może być frustrujące.

Tak więc zamiast spamować swój kanał błędów rozwiązanymi problemami, zapisz wszystkie objaśnienia z liczbą ponownych prób, aby poczuć, jak niezawodny jest system — system, za który właśnie zapłaciłeś dużo pieniędzy.

Jeśli weźmiemy klasę, którą utworzyliśmy jako przykład i pozostaniemy w kontekście Ruby on Rails, możemy po prostu umieścić wywołanie w ActiveJob i mieć pewność, że wywołanie w końcu się powiedzie. Metoda handle_response zgłosi błąd w przypadku nieoczekiwanego kodu stanu, a ActiveJob spróbuje ponowić próbę z wykładniczym wycofywaniem. W przypadku bardziej zaawansowanego rozwiązania należy również wziąć pod uwagę kody stanu 4xx, aby zapobiec ponownej próbie i zamiast tego wyświetlić komunikat o błędzie.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Upewnij się, że system jest faktycznie używany

OK, załóżmy, że wysłałeś to wszystko. Jesteś bardzo dumny ze swojej pracy, a system zostaje uruchomiony. Co teraz? To dopiero początek. Ponieważ bez względu na to, ile testujesz, zawsze będą błędy i żądane zmiany.

Problem polega na tym, że nie dowiesz się o nich, chyba że faktycznie użyjesz swojego systemu. Dzieje się tak z różnych powodów — dział sprzedaży jest obecnie zbyt zajęty, aby zacząć z niego korzystać, zmieniona strategia, a nawet nowe systemy są już w trakcie oceny.

Tak więc, aby uniknąć potencjalnych problemów w dłuższej perspektywie, upewnij się, że wyeliminowałeś wszystkie przeszkody, które uniemożliwiały produkcyjne wykorzystanie systemu. Często komunikuj się między zespołami, aby dostosować nowe wymagania. A jeśli okaże się, że system po prostu nie będzie dla Ciebie działał, wyłącz integrację. Brzmi to szorstko i może być bardzo frustrujące, ale jest mniej frustrujące niż ciągłe rozwiązywanie problemów z niespójnością danych i radzenie sobie z obejściami.

Zawijanie

W końcu projekt integracyjny to piekło projektu i jest wiele rzeczy, które mogą pójść nie tak. Nie jest to zbyt popularne wśród inżynierów z wielu powodów, ale satysfakcjonujące może być to, że wdrożenie ma pozytywny wpływ na produktywność osób siedzących obok Ciebie.

Dlatego dla inżynierów — spróbuj zrozumieć potrzeby systemu zewnętrznego, takiego jak CRM lub system fakturowania, zadając konkretne pytania, takie jak: W jaki sposób ten produkt ułatwi Ci życie? Czy brałeś pod uwagę konkurencję? Dlaczego nie działają?

Dla wszystkich innych zaangażowanych osób — poproś inżynierów jak najwcześniej, zaufaj im, gdy wskażą czerwone linie, i nie wybieraj taniego planu, gdy widzisz, że wdrożenie integracji znacznie utrudni proces długi bieg.