Integracja czatu z CRM: co naprawdę warto przekazywać i co się psuje po drodze

Większość poradników o integracji czatu z systemem CRM to instrukcje obsługi jednego pola w ustawieniach. Wklej adres, zapisz, gotowe. Trudne pytania zaczynają się dzień później: dlaczego ten sam lead pojawił się w systemie trzy razy, dlaczego notatka z rozmowy trafiła do kontaktu jego kolegi z tej samej firmy i dlaczego z wczorajszego popołudnia nie ma w ogóle śladu. Ten tekst jest o tych pytaniach, a nie o polu w ustawieniach.

Po co w ogóle integrować i kiedy nie warto

Integracja ma sens wtedy, gdy rozwiązuje konkretny problem organizacyjny, a nie wtedy, gdy jest dostępna. Zwykle chodzi o jedno z trzech: handlowiec ma zobaczyć w swoim narzędziu, że kontakt już pytał o ofertę; nikt nie ma przepisywać ręcznie danych z rozmowy; a raport sprzedaży ma pokazywać, ile okazji przyszło z czatu, a nie tylko z formularza.

• Dwa zespoły, dwa narzędziaObsługa pracuje w panelu czatu, sprzedaż w systemie CRM i nikt nie zagląda do drugiego.
• Ręczne przepisywanieKtoś codziennie kopiuje imię, telefon i treść rozmowy do nowej karty kontaktu.
• Proces po drugiej stronieZdarzenie z czatu ma uruchomić coś dalej: przypisanie opiekuna, zadanie, sekwencję.
• Raportowanie źródełZarząd pyta o udział czatu w pipelinie, a dane leżą w dwóch niepołączonych miejscach.

Warto powiedzieć też odwrotność, bo nikt tego nie robi. Jeżeli rozmowy obsługuje ten sam zespół, który potem prowadzi sprzedaż, a leadów z czatu jest kilka tygodniowo, integracja jest kosztem bez zwrotu. Utrzymanie działającego przepływu danych to nie jest jednorazowe piętnaście minut — to pola, które ktoś musi zmapować, awarie, które ktoś musi zauważyć, i duplikaty, które ktoś musi posprzątać. Pięć rekordów tygodniowo taniej przenieść ręcznie i mieć pewność, że każdy trafił tam, gdzie powinien.

Dobrym testem jest pytanie o decyzję: co konkretnie ktoś zrobi inaczej, gdy dane pojawią się w systemie CRM automatycznie zamiast po dwóch godzinach ręcznie. Jeżeli odpowiedź brzmi „nic, i tak sprawdzamy raz dziennie”, integracja jest projektem na później. Jeżeli brzmi „opiekun oddzwoni w ciągu kwadransa”, to jest projekt na teraz.

Co przekazywać, a czego nie

Domyślny odruch przy integracji to przekazać wszystko, co się da, bo „może się przydać”. To najdroższy z możliwych wyborów. Każde pole, które wysyłasz, musi być gdzieś zmapowane, komuś pokazane i przez kogoś chronione. Pełna treść rozmowy w karcie kontaktu wygląda imponująco przez tydzień, a potem jest ścianą tekstu, której nikt nie czyta, i zbiorem danych, który trzeba objąć tymi samymi zasadami co resztę.

Zasada, która upraszcza większość sporów przy wdrożeniu: do systemu CRM trafia to, co zmienia decyzję handlową, a nie to, co opisuje przebieg obsługi. Handlowiec potrzebuje wiedzieć, że kontakt pytał o wdrożenie dla dwudziestu osób i prosi o telefon po piętnastej. Nie potrzebuje trzydziestu linii wymiany zdań o tym, czy licencja obejmuje drugą lokalizację. Co warto ustalić w rozmowie, żeby to podsumowanie miało sens, opisujemy w tekście o kwalifikacji leadów na stronie.

Osobno przemyśl podstawę i zakres przetwarzania. Przekazanie danych z rozmowy do innego systemu to nowe miejsce ich przechowywania i nowy krąg odbiorców — te ustalenia robi się przed wdrożeniem, nie po nim. Praktyczną stronę tych decyzji opisujemy w artykule o live chacie a RODO.

Dopasowanie do właściwego rekordu

To jest miejsce, w którym integracje psują się najciszej i najboleśniej. Przekazanie danych działa, odbiorca odpowiada poprawnie, w raporcie nie ma żadnego błędu — a notatka z rozmowy dopisała się do kontaktu, który nigdy tej rozmowy nie prowadził. Dopasowanie to decyzja, nie szczegół techniczny, i warto ją podjąć świadomie.

1. Numer sprawy.Najpewniejszy klucz, jeśli po obu stronach jest ten sam identyfikator zgłoszenia. Nie zmienia się i nie należy do dwóch osób naraz.
2. Adres e-mail.Działa dobrze przy zakupach indywidualnych. Zawodzi tam, gdzie kilka osób korzysta ze wspólnej skrzynki firmowej.
3. Numer telefonu.Wygodny, ale bywa zapisany w kilku formatach i bywa numerem centrali, a nie osoby.
4. Nazwa firmy.Najsłabszy klucz. Literówka, skrót i forma prawna tworzą trzy różne rekordy tej samej organizacji.
5. Brak dopasowania.Świadoma decyzja: nowy rekord z wyraźnym oznaczeniem źródła albo kolejka do ręcznego sprawdzenia.

Najgorszy możliwy wybór to dopasowanie „na siłę”, czyli reguła, która zawsze znajdzie jakiś rekord. Jeżeli klucz jest niepewny, lepiej utworzyć nowy wpis i zostawić człowiekowi decyzję o scaleniu, niż dopisać historię rozmowy do cudzej karty. Nadmiar duplikatów jest problemem porządkowym, który da się posprzątać. Wpis w złym rekordzie jest problemem zaufania i zwykle wychodzi na jaw przy najgorszej możliwej rozmowie.

Stabilny identyfikator po stronie obsługi bardzo tu pomaga. W Meetlead każde zgłoszenie ma niezmienny numer sprawy i pełną oś zdarzeń, a kontakty oraz historia wizyt są izolowane osobno dla każdej witryny — dzięki temu przekazane zdarzenie da się jednoznacznie powiązać z konkretną sprawą, a nie tylko z podobnie brzmiącym nazwiskiem. Jak taki numer porządkuje pracę po stronie obsługi, opisujemy w tekście o systemie zgłoszeń w obsłudze klienta.

Co się psuje po drodze

Zanim przejdziemy dalej, jedno wyjaśnienie. Webhook to po prostu automatyczne wywołanie adresu po stronie odbiorcy w momencie, gdy po stronie nadawcy wydarzy się coś istotnego — nowa rozmowa, prośba o telefon, zmiana statusu zgłoszenia. Nadawca wysyła powiadomienie i czeka na krótkie potwierdzenie. Cała trudność siedzi w tym, co się dzieje, gdy tego potwierdzenia nie ma.

Lekarstwo jest proste i prawie nigdy nie ma go w domyślnej konfiguracji: każde zdarzenie powinno nieść własny, niezmienny identyfikator, a odbiorca powinien go zapamiętać i przy powtórce nie robić nic. To jedna kolumna w bazie po stronie odbiorcy i jeden warunek w kodzie. Bez tego każde ponowienie jest loterią, a ponowienia będą — sieć, restart serwera i chwilowe spowolnienie bazy zdarzają się każdemu.

• Cisza po stronie odbiorcyAdres odpowiada wolno albo wcale, a zdarzenia z tej godziny nie trafiają nigdzie.
• Odpowiedź bez znaczeniaOdbiorca potwierdza przyjęcie, po czym gubi dane w swoim przetwarzaniu. Nadawca nie ma o tym pojęcia.
• Kolejność bez gwarancjiZamknięcie sprawy dociera przed jej otwarciem i status w systemie CRM jest odwrotny do rzeczywistego.
• Zmiana pola bez uprzedzeniaKtoś przemianował pole po stronie odbiorcy, a integracja od tygodnia zapisuje puste wartości.

Z tego wynika reguła, którą warto przyjąć od pierwszego dnia: integracja nie może być jedynym miejscem, w którym zdarzenie istnieje. Sprawa ma nadal żyć po stronie obsługi, z własnym numerem i historią, a przekazanie do systemu CRM ma być kopią, nie przeprowadzką. Wtedy awaria odbiorcy jest niedogodnością, a nie utratą leada. Ta sama zasada obowiązuje przy każdej regule automatycznej — piszemy o niej w tekście o automatyzacji live chatu.

Zakres dostępnych akcji automatyzacji, w tym akcji webhook, zależy w Meetlead od funkcji planu i konfiguracji witryny. Ten artykuł opisuje ogólne zasady projektowania przepływu danych, a nie listę gotowych integracji z konkretnymi systemami.

Bezpieczeństwo adresu odbiorczego

Adres, pod który wysyłane są zdarzenia, jest wejściem do waszej infrastruktury i trzeba go traktować poważnie. Dwa ryzyka są realne i oba bywają pomijane. Pierwsze: ktoś podszywa się pod nadawcę i wpisuje wam do systemu CRM dane, których nikt nie podawał. Drugie działa w odwrotną stronę — źle zabezpieczony mechanizm wysyłki daje się namówić na odpytanie adresu wewnętrznego, do którego z internetu nie ma dostępu.

• Adres odbiorczy przyjmuje wyłącznie połączenia szyfrowane i nie jest zgadywalny.
• Odbiorca weryfikuje, że żądanie faktycznie pochodzi od nadawcy, zanim cokolwiek zapisze.
• Powtórzone zdarzenie o tym samym identyfikatorze jest rozpoznawane i pomijane.
• Odbiorca odpowiada szybko i krótko, a ciężką pracę wykonuje już po potwierdzeniu.
• Rozmiar przyjmowanego żądania jest ograniczony, żeby jedno zdarzenie nie zablokowało kolejki.
• Ktoś konkretny dostaje sygnał, gdy odsetek nieudanych prób rośnie.

Po stronie nadawcy sensowne zabezpieczenia wyglądają podobnie w każdym narzędziu. W Meetlead akcja webhook dopuszcza wyłącznie publiczne adresy w protokołach HTTP i HTTPS, ponownie sprawdza adresację po przekierowaniach, przypina zweryfikowany adres serwera oraz ogranicza liczbę przekierowań, czas oczekiwania i rozmiar żądania i odpowiedzi. Brzmi to jak drobiazgi, ale właśnie te reguły odróżniają mechanizm wysyłki od otwartego narzędzia do odpytywania cudzych zasobów.

Wdrożenie etapami i checklista

Integracje najczęściej przewracają się na starcie z jednego powodu: wszystko włącza się naraz, dla wszystkich zdarzeń i wszystkich pól. Pierwszy tydzień schodzi wtedy na czyszczeniu bazy zamiast na sprawdzaniu, czy przepływ w ogóle daje zespołowi to, po co powstał.

1. Etap 1 — jedno zdarzenie.Wybierz jedno: nowa prośba o kontakt albo nowe zgłoszenie. Nic więcej przez pierwszy tydzień.
2. Etap 2 — minimalny zestaw pól.Cztery lub pięć pól, każde z jasnym miejscem docelowym po stronie odbiorcy.
3. Etap 3 — reguła dopasowania.Ustal klucz i zapisz na piśmie, co się dzieje, gdy dopasowanie zawiedzie.
4. Etap 4 — test awarii.Wyłącz odbiornik na kilka minut i sprawdź, czy zdarzenia wracają i czy nie tworzą duplikatów.
5. Etap 5 — obserwacja i rozszerzenie.Po dwóch tygodniach przejrzyj rekordy z tego okresu i dopiero wtedy dokładaj kolejne zdarzenia.

• Wiadomo, kto po stronie firmy jest właścicielem integracji i kto ją naprawia.
• Zakres przekazywanych pól jest spisany i zaakceptowany przez osobę odpowiedzialną za dane.
• Każde zdarzenie ma własny identyfikator, po którym odbiorca rozpoznaje powtórzenia.
• Reguła dopasowania jest opisana razem ze scenariuszem, w którym zawodzi.
• Sprawa istnieje niezależnie po stronie obsługi, także gdy przekazanie się nie powiedzie.
• Ktoś przegląda rekordy utworzone przez integrację przynajmniej w pierwszym miesiącu.

Etap czwarty jest najczęściej pomijany i najbardziej wartościowy. Kilkuminutowe wyłączenie odbiornika w kontrolowanych warunkach mówi o waszej integracji więcej niż tydzień poprawnego działania — bo pokazuje, co się stanie w dniu, w którym nikt nie będzie tego obserwował.