Integracja strony z CRM-em - jak uporządkować obsługę zapytań?

Co dziś dzieje się z zapytaniem po kliknięciu „Wyślij”

Integracja strony z CRM-em zaczyna się od pytania, co dziś dzieje się z zapytaniem. W większości firm, z którymi rozmawiamy, trafia ono na jedną skrzynkę. Ktoś je czyta, przekazuje dalej, a potem przepisuje do arkusza albo do CRM-u, jeśli ma chwilę. Jeśli nie ma, zapytanie zostaje w skrzynce i czeka. Po tygodniu nikt nie wie, czy klient dostał odpowiedź.

Połączenie strony z CRM-em zamyka tę lukę: zapytanie z formularza zapisuje się w systemie samo, z opiekunem i terminem reakcji. Brzmi prosto, a większość pracy przy takim projekcie to decyzje, nie kod. Co ma powstać w CRM-ie, kto to dostaje, co się dzieje, gdy system nie odpowiada. Ten poradnik przechodzi przez te decyzje po kolei.

Jeśli dopiero wybierasz system, zacznij od porównania gotowego CRM-u z dedykowanym. Jeśli system już jest, a formularz na stronie nie jest jeszcze gotowy, przyda się poradnik o tym, jak ułatwić wysłanie zapytania. Tutaj zajmujemy się tym, co dzieje się między jednym a drugim.

Trzy poziomy połączenia

Zanim zaczniesz rozmowę o integracji, ustal, na którym poziomie jesteście i na który chcecie przejść. Każdy z nich ma sens w innej firmie.

• Poziom pierwszy: formularz wysyła maila, a ktoś przepisuje dane do CRM-u ręcznie. Działa przy kilku zapytaniach w tygodniu i jednej osobie, która to robi zawsze.
• Poziom drugi: formularz zapisuje zapytania do pliku albo arkusza, a CRM importuje je raz dziennie. Wystarcza, gdy nikt nie oczekuje reakcji tego samego dnia.
• Poziom trzeci: zapytanie trafia do CRM-u od razu, z opiekunem i etapem, a zespół dostaje powiadomienie. Potrzebny, gdy liczy się czas reakcji albo zapytań jest tyle, że przepisywanie zabiera etat.

Ten poradnik dotyczy poziomu trzeciego. Jeśli po lekturze uznasz, że wystarczy Wam drugi, to też jest dobra decyzja, o ile ktoś odpowiada za codzienny import.

Droga zapytania z formularza do CRM-u, krok po kroku

Zanim ustalimy zakres, opiszmy, co dzieje się w kilku sekundach po wysłaniu formularza. Każdy z tych kroków może się nie udać i każdy trzeba zaplanować.

Przeglądarka

Klient wypełnia pola i klika „Wyślij”. Przeglądarka sprawdza, czy wymagane pola są uzupełnione, i wysyła dane na serwer strony. Na tym etapie nie dzieje się nic w CRM-ie. Jeśli ktoś zamknie kartę albo straci zasięg, zapytanie przepada, bo jeszcze nigdzie nie zostało zapisane.

Serwer strony

Serwer odbiera dane i sprawdza je po raz drugi, tym razem bez zaufania do przeglądarki. Weryfikuje zabezpieczenie przed botami, czyści nietypowe znaki, odrzuca załączniki w niedozwolonym formacie. Dopiero wtedy przekazuje zapytanie dalej: do CRM-u, na skrzynkę albo w oba miejsca. Ten moment jest najważniejszy w całej integracji, bo tu zapada decyzja, co zrobić, gdy CRM nie odpowie.

CRM

CRM przyjmuje dane przez swój interfejs programistyczny, czyli API, i odpowiada: przyjąłem, albo nie przyjąłem i dlaczego. Odpowiedź może brzmieć „taki kontakt już istnieje”, „brakuje wymaganego pola” albo „za dużo żądań w tej minucie”. Każdą z tych odpowiedzi serwer strony musi rozumieć i obsłużyć inaczej.

Potwierdzenie dla klienta i pomiar

Klient widzi komunikat o wysłaniu. Powinien go zobaczyć dopiero wtedy, gdy serwer rzeczywiście przyjął wiadomość, a nie w chwili kliknięcia przycisku. Na naszej stronie zdarzenie konwersji dla narzędzi analitycznych wysyłamy dopiero po potwierdzeniu z serwera. Odświeżenie strony z podziękowaniem ani wejście na nią z zakładki nie dodaje kolejnej konwersji. Dlaczego ta kolejność ma znaczenie, opisujemy w sekcji o pomiarze.

Cały ten przepływ projektujemy w ramach integracji systemów: ustalamy dane, przypisanie osoby i kontrolę poprawności przekazania. Formularz sam w sobie jest najmniejszą częścią tej pracy.

Co ma powstać w CRM-ie i z jakich pól

Pierwsze pytanie przy integracji brzmi: co dokładnie ma się pojawić w systemie po wysłaniu formularza. Odpowiedzi są co najmniej cztery i każda zmienia zakres.

Jedna firma może pytać o kilka niezależnych projektów. Producent maszyn dostaje od tego samego klienta zapytanie o serwis i o nową linię. Jeśli integracja wrzuci oba do jednej sprawy, handlowiec straci jedno z nich. Jeśli założy dwie firmy o tej samej nazwie, raport będzie kłamał. Dlatego regułę rozpoznawania istniejących kontaktów ustalamy przed budową, a nie po pierwszych duplikatach.

Lista pól: strona, CRM, zasada sprawdzenia

Przygotuj prostą tabelę w trzech kolumnach: pole na stronie, pole w CRM-ie, zasada sprawdzenia wartości. Z takiej tabeli wynika większość pytań, które zadalibyśmy na pierwszej rozmowie.

• Co jest wymagane, a co opcjonalne. Telefon bywa wymagany w CRM-ie, a opcjonalny na stronie, i wtedy zapis się nie uda.
• Jak traktować brak nazwy firmy. Osoba prywatna pyta o ogrodzenie, a CRM wymaga firmy, więc trzeba ustalić wartość zastępczą albo zmienić regułę w systemie.
• Gdzie zapisać załączniki i kto może je otworzyć. Zdjęcie miejsca montażu jest użyteczne, ale CRM może mieć limit rozmiaru pliku.
• Czy wybrana usługa ma wpływać na przypisanie opiekuna i etap sprawy.
• Czy treść zgody i jej data mają być zapisane przy kontakcie. To przydaje się przy pytaniu, skąd macie dane tej osoby.
• Skąd przyszło zapytanie: z której podstrony, z jakiej kampanii. Te dane nie są osobowe, a pomagają ocenić, które źródła dają dobre zapytania.

Dane, których nie potrzebujecie do obsługi, nie powinny trafiać do systemu bez celu. To wymaganie RODO, ale też zdrowy rozsądek: każde pole to miejsce, w którym coś może się nie zgadzać. Jakie pola ma mieć sam formularz, żeby klient go wysłał, opisujemy w poradniku o formularzu kontaktowym.

Kto dostaje sprawę i co widzi reszta zespołu

Zapytanie zapisane w CRM-ie bez opiekuna jest w takiej samej sytuacji jak mail na wspólnej skrzynce. Wszyscy je widzą, nikt go nie bierze. Dlatego reguła przydziału jest częścią integracji, a nie ustawieniem, które zrobicie potem.

Najczęstsze warianty, które projektujemy:

• Według usługi albo produktu: zapytania o serwis idą do działu serwisu, zapytania o nową instalację do handlowca.
• Według obszaru: kod pocztowy albo miasto z formularza wskazuje oddział lub przedstawiciela regionu.
• Według dyżuru: osoba dyżurna z kalendarza dostaje wszystko, co przychodzi tego dnia.
• Według istniejącej relacji: jeśli firma ma opiekuna w CRM-ie, zapytanie trafia do niego, niezależnie od tematu.
• Do kolejki bez opiekuna, z której kierownik rozdziela sprawy ręcznie. Ten wariant wymaga osoby, która rzeczywiście zagląda do kolejki.

Każdy wariant wymaga odpowiedzi na pytanie o nieobecność. Opiekun jest na urlopie, dyżurny choruje, oddział nie ma dziś nikogo w biurze. Jeśli w CRM-ie nie ma zastępstw, zapytanie będzie czekać na powrót konkretnej osoby. Prosta reguła „po ustalonym czasie bez reakcji sprawa wraca do kierownika” załatwia większość takich sytuacji.

Powiadomienie mailowe albo na telefon może pomagać, ale nie powinno być jedynym miejscem zapisu zadania. Mail da się przeoczyć, a zadanie w CRM-ie ma status i datę. Zespół powinien widzieć w jednym widoku nowe zapytania bez reakcji, sprawy z przekroczonym terminem i osobę, która za nie odpowiada. Taki widok projektujemy w dedykowanych systemach CRM jako jeden z pierwszych, bo kierownik otwiera go częściej niż jakikolwiek raport.

Co ma zawierać powiadomienie

Powiadomienie o nowej sprawie ma pozwolić zareagować bez otwierania CRM-u, jeśli ktoś jest w terenie. Imię i firma, temat, treść zapytania, numer telefonu i link do sprawy w systemie. Bez numeru telefonu handlowiec musi wejść do CRM-u, żeby oddzwonić, a z samochodu tego nie zrobi. Jeśli powiadomienie idzie na telefon, treść zapytania powinna być w nim w całości, bo skrócona wersja wraca jako pytanie „o co właściwie pyta ten klient”.

Co może pójść nie tak i jak to zaplanować z góry

Integracja, która działa w dniu odbioru, to za mało. Ma działać też w dniu, w którym dostawca CRM-u zmieni wersję API, a Wasz klucz dostępu wygaśnie. Poniżej sytuacje, które widzieliśmy, i decyzje, które trzeba podjąć przed budową.

CRM nie odpowiada

System ma przerwę techniczną, limit żądań został wyczerpany albo sieć między serwerami nie działa. Są dwie uczciwe drogi. Pierwsza: serwer strony zapisuje zapytanie u siebie, w kolejce, i próbuje ponownie co jakiś czas, a klient widzi normalne potwierdzenie. Druga: klient widzi komunikat, że wysyłka się nie udała, z numerem telefonu i prośbą o kontakt inną drogą. Nieuczciwa jest trzecia droga: komunikat „dziękujemy” przy zapytaniu, które nigdzie nie dotarło.

Na naszej stronie, gdy serwer nie potwierdzi przyjęcia wiadomości, formularz pokazuje komunikat o błędzie, zamiast udawać sukces. Taki sam standard przyjmujemy przy integracjach u klientów.

Ponowienie tworzy duplikaty

Kolejka z ponowieniami ma skutek uboczny. CRM mógł przyjąć zapytanie, ale odpowiedź nie dotarła, więc serwer wysyła je drugi raz. Handlowiec dostaje dwie identyczne sprawy i dzwoni do klienta dwa razy. Zapobiega temu unikalny identyfikator zapytania, który CRM sprawdza przed zapisem. Jeśli CRM nie obsługuje takiego mechanizmu, deduplikację robimy po stronie serwera strony, po adresie e-mail i czasie wysłania.

Ktoś zmienił pole w CRM-ie

Administrator po stronie firmy usuwa pole „źródło”, zmienia listę etapów albo nazwę usługi. Integracja wysyła wartość, której system już nie zna, i zapytanie zostaje odrzucone. Takie zmiany nie są błędem, ale wymagają zasady: kto może zmieniać konfigurację CRM-u i kogo informuje przed zmianą. Dobra integracja zapisuje takie odrzucenia w logu i wysyła powiadomienie do osoby odpowiedzialnej, zamiast cicho gubić zapytania.

Klucz dostępu wygasł

Dostawcy CRM-ów wydają klucze z datą ważności albo unieważniają je przy zmianie hasła administratora. Integracja przestaje działać w dniu, w którym nikt na to nie patrzy. Dlatego w dokumentacji przekazania zapisujemy, gdzie jest klucz, kto go odnawia i jak to sprawdzić. Monitoring, który regularnie wysyła testowe zapytanie i sprawdza, czy dotarło, kosztuje mniej niż tydzień zgubionych zapytań.

Spam i boty

Formularz bez zabezpieczenia wypełnia bot, a każde zgłoszenie staje się kontaktem w CRM-ie. Po miesiącu baza ma więcej śmieci niż klientów. Zabezpieczenie przed botami, na przykład Cloudflare Turnstile, sprawdzamy po stronie serwera, przed przekazaniem danych dalej. Do tego prosta reguła: zapytanie bez treści i z adresem w domenie, której nikt nie zna, trafia do przeglądu, nie do handlowca.

Drobiazgi, które psują dane

Polskie znaki, które po drodze zmieniają się w krzaczki. Numer telefonu ze spacjami, którego CRM nie rozpoznaje. Strefa czasowa, przez którą zapytanie z wieczora ma datę następnego dnia. Załącznik większy niż limit systemu. Podwójne kliknięcie w „Wyślij”, które tworzy dwie sprawy. Każdy z tych drobiazgów wymaga jednego zdania w specyfikacji i jednego scenariusza w testach.

RODO i bezpieczeństwo danych w drodze między stroną a CRM-em

Zapytanie z formularza zawiera dane osobowe, więc integracja jest przetwarzaniem danych w rozumieniu RODO. Nie musisz być prawnikiem, żeby zaplanować podstawy. Poniżej pytania, które rozstrzygamy przed budową, i jedna rada: włącz wcześnie osobę, która zajmuje się u Was ochroną danych.

Co ustalić po stronie firmy

• Jakie dane zbieracie i po co. Zasada minimalizacji z RODO mówi, żeby zbierać tyle, ile potrzeba do obsługi sprawy. Pole „data urodzenia” w formularzu o ogrodzenie nie ma uzasadnienia.
• Jak informujecie osobę o przetwarzaniu. Klauzula przy formularzu i polityka prywatności powinny wymieniać CRM jako miejsce, do którego trafiają dane, jeśli dostawca CRM-u jest zewnętrzny.
• Czy macie umowę powierzenia z dostawcą CRM-u. Jeśli korzystacie z gotowego systemu w chmurze, dostawca przetwarza dane w Waszym imieniu, a to wymaga umowy. Sprawdźcie też, gdzie dostawca przechowuje dane.
• Jak długo przechowujecie zapytania, które nie zamieniły się w zlecenie. Zapytanie sprzed lat od osoby, która nigdy nie została klientem, nie powinno leżeć w bazie bez powodu.
• Jak obsługujecie prośbę o usunięcie danych. Dane są w CRM-ie, na skrzynce, w logach serwera i w kopiach zapasowych. Usunięcie musi objąć wszystkie te miejsca.
• Kto w firmie ma dostęp do zapytań. Uprawnienia w CRM-ie są częścią integracji, bo decydują, kto zobaczy dane osoby, która jeszcze nie jest klientem.

Tekst rozporządzenia jest dostępny na EUR-Lex, a wyjaśnienia i decyzje organu nadzorczego publikuje Urząd Ochrony Danych Osobowych. Treść klauzul i polityki jest po stronie firmy jako administratora danych. My wdrażamy ją technicznie: zgoda przy formularzu, zapis daty zgody, baner cookies z trybem zgody.

Co robimy po stronie technicznej

Klucz dostępu do CRM-u leży na serwerze, nigdy w kodzie strony widocznym w przeglądarce. Połączenie między stroną a CRM-em jest szyfrowane. Dane z formularza sprawdzamy po stronie serwera, niezależnie od sprawdzenia w przeglądarce, bo przeglądarkę da się ominąć. Logi integracji zapisują fakt przekazania i ewentualny błąd, a nie pełną treść zapytania, żeby dane osobowe nie leżały w trzecim miejscu. Ograniczamy liczbę zgłoszeń z jednego adresu w krótkim czasie. Punktem odniesienia dla tych zasad jest lista najczęstszych zagrożeń aplikacji webowych publikowana przez OWASP.

Jak liczyć zapytania, żeby raport nie kłamał

Integracja z CRM-em zmienia też sposób liczenia zapytań w narzędziach analitycznych. Do tej pory konwersją było kliknięcie w „Wyślij” albo wejście na stronę z podziękowaniem. Oba sposoby zawyżają wynik.

Kliknięcie liczy też próby, które serwer odrzucił: spam, błędy, podwójne kliknięcia. Strona z podziękowaniem liczy każde jej odświeżenie i każde wejście z zakładki. Przy kampanii reklamowej oznacza to, że system reklamowy uczy się na zdarzeniach, które nie są zapytaniami.

Dlatego na naszej stronie zdarzenie konwersji powstaje dopiero po potwierdzeniu z serwera, że wiadomość została przyjęta. Jest przekazywane na stronę z podziękowaniem i zużywane tam jeden raz. Ponowne wejście na tę stronę nie tworzy nowego zdarzenia. Nazwa zdarzenia jest zgodna z listą zdarzeń zalecanych przez Google dla GA4, dostępną w dokumentacji dla deweloperów. To ułatwia użycie go jako celu w GA4 i Google Ads.

Przy integracji z CRM-em można pójść krok dalej. Jeśli CRM zapisuje źródło zapytania, raport pokazuje, które kampanie dały zapytania zamienione w zlecenia, a które same zapytania. Taki raport wymaga zgody na analitykę w trybie zgody Google Tag Manager i decyzji, jakie identyfikatory przekazujecie do CRM-u. Nie zalecamy przekazywania do CRM-u niczego, czego nie potraficie wyjaśnić osobie, która o to zapyta.

Integracja strony z CRM-em w różnych firmach

Przepływ z poprzednich sekcji jest wspólny. Różni się to, co formularz zbiera, co CRM z tym robi i gdzie w firmie zapytanie ma wylądować. Poniżej sytuacje, które spotykamy najczęściej.

Serwis i instalacje

Klient wysyła adres i opis usterki, często ze zdjęciem. Zapytanie powinno trafić do osoby, która układa grafik ekip, a nie do handlowca. W CRM-ie powstaje zgłoszenie serwisowe z lokalizacją. Jeśli firma prowadzi obsługę zleceń w osobnej aplikacji, zgłoszenie od razu staje się zleceniem do zaplanowania. Przy takim układzie ustalamy, który system jest źródłem statusu, bo klient dzwoni z pytaniem „kiedy przyjedziecie” do biura, nie do serwera. Jak taki przepływ wygląda od środka, opisujemy w poradniku o CRM-ie dla firmy usługowej.

Produkcja B2B

Zapytanie ofertowe ma parametry: materiał, ilość, termin, rysunek w załączniku. Formularz powinien je zbierać osobno, a nie w jednym polu „wiadomość”, bo z osobnych pól CRM potrafi zbudować sprawę z wartością i terminem. Problemem bywa dopasowanie do istniejącej firmy, bo technolog pisze z innego adresu niż dział zakupów. Reguła: dopasowanie po domenie adresu e-mail, a nie po pełnym adresie, z ręcznym potwierdzeniem przy pierwszym zapytaniu z nowej domeny. Przy realizacji Nomatec zakres objął stronę z prezentacją oferty i procesu współpracy oraz CRM wspierający obsługę zapytań. Strona przedstawia ofertę, a dalsza obsługa toczy się w narzędziu firmowym.

Handel i dystrybucja

Tu formularz na stronie jest często początkiem relacji, która potem przenosi się do panelu klienta. Zapytanie o współpracę hurtową tworzy w CRM-ie sprawę, a po akceptacji handlowca powstaje konto w panelu B2B z cennikiem i historią zamówień. Integracja musi więc obsłużyć przejście: ten sam klient w CRM-ie i w panelu, z jednym identyfikatorem. Co taki panel powinien zawierać, opisujemy w poradniku o panelu klienta B2B.

Usługi dla firm: księgowość, kancelarie, agencje

Zapytanie dotyczy często obecnego klienta i bieżącej sprawy, a nie nowej sprzedaży. Formularz powinien pozwolić zaznaczyć „jestem już klientem”, a integracja dopisać wiadomość do istniejącej karty firmy jako zadanie dla opiekuna. Nowe zapytania idą do osoby od sprzedaży, a bieżące do opiekuna. Bez tego podziału handlowiec dostaje pytania o fakturę, a opiekun o cennik.

Budowlanka i wykończenia

Zapytania przychodzą od inwestorów prywatnych i od generalnych wykonawców, a to dwa różne procesy. Inwestor pyta o remont łazienki i chce wyceny po oględzinach. Wykonawca wysyła przedmiar i oczekuje oferty na piśmie. Dwa formularze albo jedno pole wyboru na starcie, a w CRM-ie dwa różne typy spraw z innymi etapami. Integracja, która wrzuca oba do jednego lejka, kończy się tym, że ktoś ręcznie przerzuca sprawy między kolumnami.

Firmy z oddziałami

Zapytanie ma trafić do oddziału, który obsługuje dany teren. Ustalamy, skąd integracja ma wiedzieć o terenie: z kodu pocztowego, z wyboru oddziału w formularzu, czy z podstrony, z której wysłano zapytanie. Centrala chce widzieć wszystko, oddział tylko swoje, a to oznacza uprawnienia w CRM-ie ustawione przed uruchomieniem. Dochodzi zastępstwo między oddziałami, gdy jeden nie ma nikogo w biurze.

Przykład z biurka: formularz, który trafiał do trzech skrzynek

Firma instalacyjna z okolic Nowego Tomyśla miała formularz wysyłający wiadomość na trzy adresy. Do właściciela, do biura i do handlowca. Każdy zakładał, że odpowie ktoś inny. Do tego biuro przepisywało zapytania do arkusza, ale tylko te, które uznało za poważne. CRM w firmie był, kupiony rok wcześniej, z trzema kontaktami w bazie.

Krok pierwszy: ustaliliśmy, co ma powstać. Zapytanie o nową instalację tworzy sprawę sprzedażową z etapem „do wyceny”. Zapytanie o serwis tworzy zgłoszenie serwisowe przypisane do koordynatora ekip. Formularz dostał pole wyboru tematu na samym początku, bo bez niego nie dało się rozróżnić jednego od drugiego.

Krok drugi: mapowanie pól. CRM wymagał nazwy firmy, a większość klientów to osoby prywatne. Zamiast zmuszać klientów do wpisywania czegokolwiek, ustaliliśmy wartość zastępczą „osoba prywatna” i oznaczenie typu klienta. Załącznik ze zdjęciem zapisywał się przy sprawie, z limitem rozmiaru, o którym formularz informował przed wysłaniem.

Krok trzeci: reguła przydziału i zastępstwa. Sprawy sprzedażowe szły do handlowca, serwisowe do koordynatora, a po ustalonym czasie bez reakcji wracały do właściciela z powiadomieniem. Trzy skrzynki zastąpiło jedno powiadomienie do osoby, która dostała sprawę.

Krok czwarty: awaria. Serwer strony zapisywał każde zapytanie u siebie i próbował przekazać je do CRM-u ponownie, jeśli pierwsza próba się nie udała. Po kilku nieudanych próbach wysyłał powiadomienie do biura. W testach wyłączyliśmy dostęp do CRM-u na godzinę i sprawdziliśmy, że zapytania dotarły po jego przywróceniu, bez duplikatów.

Krok piąty: odbiór z zespołem. Koordynator i handlowiec wysłali po kilka testowych zapytań z telefonu, w tym jedno od istniejącego klienta i jedno bez zdjęcia. Każdy sprawdził, czy widzi sprawę tam, gdzie się jej spodziewa. Dwie uwagi wróciły do nas: nazwa etapu była niezrozumiała dla serwisu, a powiadomienie przychodziło bez numeru telefonu klienta. Obie poprawiliśmy przed uruchomieniem.

Arkusz biura został jako archiwum. Nowe zapytania od dnia uruchomienia trafiały wyłącznie do CRM-u, a trzy adresy w formularzu zniknęły.

Jak testować integrację przed odbiorem

Integracja, która przeszła jeden test „wysłałem, doszło”, nie jest sprawdzona. Poniżej scenariusze, które przechodzimy z zespołem klienta przed uruchomieniem. Każdy z nich ma odpowiedź na dwa pytania: co powinno się stać i co widzi klient.

Do tego dwa testy, które dotyczą ludzi, nie systemów. Pierwszy: osoba, która dostaje sprawę, znajduje ją w CRM-ie bez instrukcji. Drugi: kierownik widzi w jednym widoku, że zapytanie czeka bez reakcji. Jeśli któryś z tych testów nie przechodzi, integracja technicznie działa, a firma dalej gubi zapytania.

Pytania do wykonawcy i etapy współpracy

Zanim zlecisz integrację, zadaj kilka pytań. Odpowiedzi pokażą, czy wykonawca myśli o awariach i danych, czy tylko o tym, żeby formularz „gadał” z CRM-em.

• Co dzieje się z zapytaniem, gdy CRM nie odpowiada, i co w tym czasie widzi klient.
• Jak integracja rozpoznaje istniejący kontakt i co robi z duplikatami przy ponowieniu.
• Gdzie leży klucz dostępu do CRM-u, kto go odnawia i jak dowiemy się, że wygasł.
• Co zapisują logi integracji i czy są w nich dane osobowe.
• Kto dostaje powiadomienie o błędzie i w jakiej formie.
• Jak zmiana pola w CRM-ie wpłynie na integrację i kto ma o niej informować.
• Jakie scenariusze testowe przejdziemy razem przed uruchomieniem.
• Co dostaniemy przy przekazaniu: dokumentację, dostępy, opis konfiguracji.
• Czy konwersja w analityce liczy się po potwierdzeniu z serwera, czy po kliknięciu.

Najczęstsze błędy przy zlecaniu integracji

• Zlecenie „podłączcie formularz do CRM-u” bez decyzji, co ma powstać w systemie. Wykonawca zgaduje, a zespół po uruchomieniu przerabia sprawy ręcznie.
• Brak osoby po stronie firmy, która zna konfigurację CRM-u. Pytania o pola i etapy czekają tygodniami, a bez nich nie da się zbudować mapowania.
• Testy wyłącznie przez wykonawcę. Zespół, który ma obsługiwać zapytania, pierwszy raz widzi sprawę w CRM-ie w dniu uruchomienia i nie wie, gdzie jej szukać.
• Integracja zbudowana na koncie pracownika zamiast na koncie technicznym. Pracownik odchodzi, konto zostaje zablokowane, integracja przestaje działać.
• Pominięcie RODO do czasu „aż będzie działać”. Potem okazuje się, że formularz zbiera pola, których nie wolno zbierać, albo że brakuje umowy z dostawcą.
• Brak dokumentacji przy przekazaniu. Po dwóch latach nikt nie wie, jak integracja działa, a jedyna osoba, która to wiedziała, nie pracuje już u wykonawcy.

Od czego zaczynamy

Do pierwszej rozmowy potrzebujemy nazwy systemu CRM, jego wersji albo planu abonamentu i informacji, czy macie dostęp do dokumentacji API. Sprawdzamy, co system udostępnia: interfejs programistyczny, eksport, webhooki albo inny dopuszczony sposób wymiany danych. Przed wyceną ustalamy ograniczenia dostawcy i ewentualne dodatkowe koszty dostępu, bo u części dostawców API jest dostępne w wybranych planach. Nie każdy system da się połączyć w pełni i wolimy to powiedzieć przed ofertą.

Dalej pracujemy etapami z oferty aplikacji dla firm. Poznajemy sposób pracy: jak dziś obsługujecie zapytanie, kto bierze w tym udział i gdzie gubią się informacje. Projektujemy i ustalamy zakres: przepływ danych, reguły przydziału, obsługę błędów i to, co zostaje w obecnych narzędziach. Budujemy i sprawdzamy na uzgodnionych scenariuszach, takich jak w tabeli wyżej. Wdrażamy i rozwijamy: uruchamiamy z zespołem, zbieramy uwagi z pierwszych tygodni i ustalamy zasady opieki. Co wpływa na wycenę takiego zakresu, opisujemy w poradniku o koszcie aplikacji dla firmy.

Co po wdrożeniu: utrzymanie, zmiany, dostępy

Integracja łączy dwa systemy, które żyją własnym życiem. Strona dostaje nowe formularze, CRM dostaje aktualizacje od dostawcy. Kilka rzeczy trzeba zaplanować w dniu uruchomienia, bo później nikt o nich nie pamięta.

Monitoring i powiadomienia

Ustalamy, jak firma dowie się o problemie: powiadomienie o błędzie, cykliczne zapytanie testowe, raport raz w tygodniu z liczbą przekazanych zapytań. Spadek do zera w tygodniu, w którym reklama działa, oznacza awarię, nie brak klientów.

Zmiany w CRM-ie i na stronie

Nowe pole w formularzu, nowa usługa w ofercie, nowy etap sprzedaży. Każda z tych zmian może dotyczyć integracji. Zasada jest prosta: zmiany konfiguracji CRM-u, które dotyczą pól używanych przez integrację, zgłaszacie przed ich wprowadzeniem. Przy zmianie wersji API przez dostawcę sprawdzamy, czy integracja działa, w ramach ustalonej opieki.

Dostępy i klucze

Przy przekazaniu dostajesz dokumentację: gdzie leży klucz dostępu, jak go odnowić, jak wyłączyć integrację, gdy trzeba. Zdecyduj, kto w firmie to przechowuje. Jeśli odchodzi administrator CRM-u, odnowienie klucza i zmiana haseł są częścią jego odejścia, tak samo jak oddanie kluczy do biura.

Dane i zmiana systemu

Firmy zmieniają CRM-y. Integracja powinna być zbudowana tak, żeby wymiana systemu po drugiej stronie wymagała zmiany jednego modułu, a nie przebudowy formularzy. Dlatego mapowanie pól trzymamy w jednym miejscu, z dokumentacją. Przed zmianą systemu sprawdź, czy obecny CRM pozwala wyeksportować zapytania wraz z historią, bo to Wasze dane i powinny pójść z Wami.

Rozwój

Po kilku miesiącach pracy z integracją widać, które zapytania trafiają nie tam, gdzie trzeba, i jakich danych brakuje handlowcom na starcie. Z tych obserwacji wynika kolejny zakres. Może to być dodatkowe źródło zapytań, na przykład z panelu klienta. Może to być podsumowanie treści zapytania przez AI jako podpowiedź dla opiekuna, z decyzją, co wymaga sprawdzenia przez człowieka. Albo raport łączący źródło zapytania ze zleceniem. Każdy z tych kroków ma sens dopiero wtedy, gdy pierwszy przepływ działa bez ręcznych poprawek. Jak dobierać zakres pierwszej wersji, opisujemy w poradniku o MVP aplikacji dla firmy.

Słownik pojęć z oferty integracji

W rozmowie o integracji padają słowa, które dla programisty są oczywiste, a dla właściciela firmy brzmią obco. Krótkie wyjaśnienia, żebyś wiedział, o czym mowa w ofercie.

• API. Interfejs, przez który jeden program rozmawia z drugim. CRM udostępnia API, a strona przez nie zapisuje zapytanie. Bez API zostaje eksport plików albo przepisywanie.
• Klucz API, token. Hasło dla programów, nie dla ludzi. Daje stronie prawo zapisu do CRM-u w ustalonym zakresie. Przechowywany na serwerze, odnawiany według zasad dostawcy.
• Webhook. Mechanizm, przez który system sam powiadamia drugi o zdarzeniu, na przykład CRM informuje stronę, że sprawa zmieniła status. Działa w drugą stronę niż zwykłe zapytanie.
• Mapowanie pól. Tabela, które pole formularza trafia do którego pola w CRM-ie i jak jest sprawdzane po drodze.
• Deduplikacja. Rozpoznawanie, że kontakt albo zapytanie już istnieje, żeby nie tworzyć drugiego. Wymaga ustalonej reguły, na przykład po adresie e-mail albo domenie.
• Kolejka. Miejsce, w którym serwer odkłada zapytania do przekazania, gdy CRM chwilowo nie odpowiada. Z kolejki zapytania są wysyłane ponownie, aż się uda albo aż ktoś zareaguje.
• Ponowienie. Kolejna próba przekazania zapytania po nieudanej. Wymaga ochrony przed duplikatami.
• Limit żądań. Maksymalna liczba operacji, jaką dostawca CRM-u pozwala wykonać w określonym czasie. Po przekroczeniu system odrzuca kolejne, dlatego potrzebna jest kolejka.
• Środowisko testowe, sandbox. Osobna instancja CRM-u do prób, bez prawdziwych danych. Nie każdy dostawca ją oferuje.
• Log. Zapis, co integracja zrobiła i kiedy: przyjęte, przekazane, odrzucone, z jakim błędem. Bez danych osobowych, jeśli da się tego uniknąć.
• Umowa powierzenia. Umowa między firmą a dostawcą systemu, który przetwarza dane osobowe w jej imieniu. Wymagana przez RODO przy zewnętrznym CRM-ie.
• Zdarzenie konwersji. Sygnał dla narzędzi analitycznych i reklamowych, że zapytanie zostało wysłane. U nas powstaje dopiero po potwierdzeniu z serwera.

TL;DR

• Zapisz, co ma powstać w CRM-ie po wysłaniu formularza: kontakt, sprawa, zadanie albo notatka przy istniejącej firmie.
• Przygotuj listę pól: strona, CRM, zasada sprawdzenia. Zbieraj tylko to, czego potrzebujesz do obsługi.
• Ustal regułę przydziału i zastępstwa, bo zapytanie bez opiekuna czeka tak samo jak mail na wspólnej skrzynce.
• Zdecyduj, co widzi klient, gdy CRM nie odpowiada, i jak zapytania są odzyskiwane bez duplikatów.
• Uporządkuj RODO: klauzula przy formularzu, umowa powierzenia z dostawcą CRM-u, okres przechowywania, usuwanie ze wszystkich miejsc.
• Licz konwersję po potwierdzeniu z serwera, nie po kliknięciu i nie po wejściu na stronę z podziękowaniem.
• Przetestuj scenariusze z tabeli na środowisku testowym, z udziałem osób, które będą obsługiwać zapytania.
• Zaplanuj monitoring, zasadę zgłaszania zmian w CRM-ie i miejsce, w którym leży klucz dostępu.

FAQ