Integracja sklepu internetowego z systemem CRM

Dane o klientach w dwóch miejscach

Gdy informacje o kupujących są rozproszone między sklepem a osobnym systemem do zarządzania relacjami, żadne z tych miejsc nie daje pełnego obrazu. Handlowiec nie widzi historii zamówień, a sklep nie wie o ustaleniach prowadzonych telefonicznie.

Co przekazujemy

• Dane klientów zakładających konto w sklepie.
• Historię zamówień wraz z wartością i częstotliwością zakupów.
• Porzucone koszyki, jeśli firma chce z nimi pracować.
• Zgłoszenia reklamacyjne i zwroty.
• Zgody marketingowe wraz z datą ich udzielenia.

Jedno źródło danych kontrahenta

Ustalamy, który system jest źródłem prawdy dla danych klienta. Bez tego ten sam kupujący istnieje w dwóch wersjach, z różnymi adresami i różną historią — a scalanie takich kartotek po roku jest pracą znacznie większą niż konfiguracja na starcie.

Zgody i dane osobowe

Przekazywanie danych klientów między systemami wymaga uwagi: zakres przesyłanych informacji ograniczamy do tego, co jest potrzebne, a zgody marketingowe przenosimy razem z datą i treścią. Przesyłanie wszystkiego „na wszelki wypadek" to podejście, którego nie stosujemy.

Co to daje w praktyce

Obsługa widzi przy telefonie od klienta jego zamówienia, reklamacje i wcześniejsze ustalenia. To zmienia rozmowę bardziej niż jakiekolwiek narzędzie sprzedażowe.

Kontrola

Po wdrożeniu sprawdzamy zgodność danych na próbce klientów — zwłaszcza tych, którzy istnieli w obu systemach przed integracją.

Integracja jednokierunkowa i dwukierunkowa

Najprostszy wariant polega na przekazywaniu informacji tylko ze sklepu do CRM, czyli systemu do zarządzania relacjami z klientami. Nowe konto, zamówienie albo zgłoszenie tworzy lub aktualizuje kartę klienta, ale zmiana wykonana przez handlowca nie wraca automatycznie do sklepu. Taki kierunek wystarcza, gdy CRM służy głównie do analizy historii zakupów, prowadzenia rozmów i planowania dalszego kontaktu.

Integracja dwukierunkowa pozwala aktualizować dane w obu systemach. Wymaga jednak dokładnych reguł rozstrzygania konfliktów. Trzeba ustalić, co stanie się wtedy, gdy adres e-mail zostanie zmieniony niemal równocześnie w sklepie i w CRM. Potrzebna jest także odpowiedź na pytanie, czy notatki handlowe mają trafić do sklepu, czy powinny pozostać wyłącznie w CRM. Dwukierunkowa wymiana nie oznacza, że każde pole należy kopiować w obie strony.

Osobnym wariantem jest synchronizacja okresowa, podczas której dane są przekazywane w ustalonych cyklach, oraz synchronizacja uruchamiana przez zdarzenie. Zdarzenie to konkretna czynność, na przykład złożenie zamówienia albo utworzenie konta. Dobór rozwiązania zależy od procesu firmy. Informacja potrzebna konsultantowi podczas bieżącej rozmowy powinna pojawiać się szybko, natomiast dane przeznaczone wyłącznie do raportu mogą być uzupełniane okresowo.

Mapowanie pól przed uruchomieniem wymiany

Mapowanie pól oznacza przypisanie informacji z jednego systemu do właściwych miejsc w drugim. Pole „firma” w sklepie może odpowiadać nazwie kontrahenta w CRM, ale już jeden zapis adresu może wymagać rozdzielenia na ulicę, numer budynku, numer lokalu, miejscowość i kod. Podobnie status zamówienia ze sklepu nie zawsze ma bezpośredni odpowiednik w etapach procesu sprzedażowego używanych przez handlowców.

Przed wdrożeniem przygotowujemy zestawienie pól, ich formatów i kierunków przepływu. Określamy również, które dane są obowiązkowe, które opcjonalne, a których nie należy przenosić. Pozwala to zauważyć różnice, zanim zostaną utworzone niepełne kartoteki. Szczególnej uwagi wymagają wartości wybierane z list, ponieważ ten sam rodzaj klienta może mieć w obu systemach inną nazwę lub oznaczenie.

Ważne są również identyfikatory, czyli wartości pozwalające jednoznacznie rozpoznać rekord. Samo imię i nazwisko nie wystarcza, a adres e-mail może zostać zmieniony albo użyty przy więcej niż jednym zakupie. Integracja powinna zachowywać powiązanie między kontem sklepowym, zamówieniami i właściwą kartą w CRM. Reguły dopasowania ustala się przed importem starszych danych, ponieważ błędne połączenie dwóch osób bywa trudniejsze do poprawienia niż brak automatycznego połączenia.

Różne scenariusze obsługi klienta

Klient indywidualny może złożyć zamówienie bez zakładania konta, a przy kolejnym zakupie użyć innego adresu dostawy. Firma może natomiast mieć wielu pracowników składających zamówienia na jeden podmiot. Integracja powinna odróżniać osobę kontaktową od kontrahenta, czyli firmy będącej stroną relacji handlowej. W przeciwnym razie każdy pracownik może zostać zapisany jako osobna firma, a historia zakupów pozostanie podzielona.

Kolejny scenariusz dotyczy klienta, który najpierw kontaktuje się z handlowcem, a dopiero później kupuje w sklepie. CRM zawiera już wtedy notatki i dane kontaktowe. Nowe zamówienie nie powinno tworzyć przypadkowego duplikatu. Potrzebna jest reguła dopasowania oraz możliwość skierowania niejednoznacznego przypadku do ręcznej weryfikacji.

Inaczej obsługuje się porzucony koszyk. Nie każdy niedokończony zakup powinien automatycznie tworzyć zadanie dla handlowca. Znaczenie mają zgody, przyjęty sposób komunikacji oraz reguły biznesowe firmy. Integracja może przekazać samo zdarzenie, wartość koszyka i jego zawartość, ale decyzja o dalszym kontakcie powinna wynikać z uzgodnionego procesu, a nie z technicznej możliwości przesłania danych.

Najczęstsze błędy przy samodzielnym łączeniu systemów

Częstym błędem jest rozpoczęcie prac od kopiowania wszystkich dostępnych pól bez opisania celu. Powstaje wtedy duża liczba danych, z których zespół nie korzysta. Jednocześnie może zabraknąć jednej informacji naprawdę potrzebnej, na przykład źródła pozyskania kontaktu albo daty ostatniego zamówienia. Zakres integracji warto więc budować na podstawie konkretnych czynności wykonywanych przez sprzedaż i obsługę.

Problemy powoduje także uznanie adresu e-mail za zawsze pewny identyfikator. Literówka, zmiana adresu lub wspólna skrzynka firmowa mogą doprowadzić do utworzenia duplikatów albo połączenia niewłaściwych kart. Nie należy też automatycznie scalać rekordów wyłącznie na podstawie podobnego nazwiska czy numeru telefonu bez sprawdzenia pozostałych danych.

Inny błąd to brak obsługi sytuacji, w której jeden z systemów chwilowo nie odpowiada. Próba przesłania informacji może się nie udać, mimo że zamówienie zostało prawidłowo przyjęte w sklepie. Mechanizm powinien odnotować błąd, umożliwić ponowienie operacji i zapobiegać wielokrotnemu utworzeniu tego samego rekordu. Log, czyli dziennik zdarzeń technicznych, pomaga ustalić, jaka informacja została wysłana i na którym etapie wystąpił problem.

Niebezpieczne jest również testowanie od razu na całej bazie. Duży import może powielić kontakty, nadpisać poprawne wartości albo uruchomić nieplanowane automatyzacje w CRM. Bezpieczniej sprawdzić reprezentatywne przypadki: nowego klienta, istniejącego klienta, zakup bez konta, firmę z kilkoma osobami kontaktowymi, zwrot oraz zmianę danych. Dopiero po potwierdzeniu wyników można rozszerzyć zakres.

Kiedy problem nie wynika z integracji CRM

Brak zamówienia na karcie klienta nie zawsze oznacza awarię połączenia. Rekord mógł zostać przypisany do duplikatu, zamówienie mogło powstać bez konta albo pracownik mógł korzystać z niewłaściwego widoku. Najpierw sprawdza się więc identyfikator klienta, historię synchronizacji i reguły filtrowania danych.

Opóźnienie informacji może być zgodne z projektem, jeśli wymiana działa okresowo. Nie jest to wtedy utrata danych, lecz cecha przyjętego sposobu synchronizacji. Jeżeli informacja ma być potrzebna natychmiast po zakupie, należy zmienić mechanizm lub częstotliwość przekazywania, zamiast naprawiać element, który działa zgodnie z wcześniejszym założeniem.

Nie każda rozbieżność wymaga też dwukierunkowej integracji. Gdy pracownicy wpisują dane w różnych formatach, przyczyną może być brak wspólnych zasad wprowadzania informacji. Automatyczne przesyłanie nie poprawi literówek ani nie rozstrzygnie, która nazwa firmy jest prawidłowa. W takim przypadku potrzebne jest uporządkowanie danych i procesu, a dopiero potem rozszerzenie wymiany.

Bezpieczne uruchomienie i późniejsze utrzymanie

Wdrożenie zaczyna się od opisania przebiegu danych: gdzie powstają, kto może je zmieniać i do czego są później używane. Następnie przygotowuje się środowisko testowe, czyli oddzielne miejsce, w którym można sprawdzić integrację bez wpływania na bieżące zamówienia. Jeśli któryś system nie udostępnia takiego środowiska, zakres prób ogranicza się i oznacza rekordy testowe tak, aby można je było łatwo rozpoznać.

Kontrola nie kończy się w dniu uruchomienia. Sklep i CRM mogą otrzymywać aktualizacje, a firma może dodawać nowe statusy, pola lub etapy sprzedaży. Zmiana nazwy pola albo zasad dostępu potrafi zatrzymać część wymiany, podczas gdy pozostałe operacje nadal działają. Dlatego sprawdza się dzienniki błędów oraz zgodność liczby i treści przesłanych rekordów, a ważne niepowodzenia kieruje do osoby odpowiedzialnej za obsługę procesu.

Potrzebne są również zasady postępowania z usuwaniem i poprawianiem danych. Skasowanie klienta w jednym systemie nie powinno bez uzgodnienia usuwać pełnej historii w drugim. Czasem właściwe jest oznaczenie rekordu jako nieaktywnego, a czasem jego anonimizacja, czyli zastąpienie danych pozwalających rozpoznać osobę. Ostateczny sposób zależy od celu przetwarzania i zasad obowiązujących w firmie.

Dodatkowe pytania o integrację sklepu z CRM

Czy trzeba przenosić całą dotychczasową bazę klientów?

Nie zawsze. Można przenieść pełną historię, ograniczyć migrację do aktywnych klientów albo rozpocząć automatyczną wymianę od ustalonego dnia. Decyzja zależy od tego, czy starsze zamówienia są potrzebne handlowcom, obsłudze reklamacji lub do analizy. Przed migracją warto ocenić jakość danych, ponieważ przeniesienie nieaktualnych i powielonych kartotek nie rozwiązuje ich problemów.

Czy integracja może tworzyć zadania dla handlowców?

Tak, jeżeli CRM obsługuje zadania lub automatyzacje, czyli działania uruchamiane po spełnieniu określonych warunków. Zadanie może powstać po zamówieniu wymagającym kontaktu, zgłoszeniu reklamacyjnym albo innym uzgodnionym zdarzeniu. Reguły powinny być precyzyjne, aby zespół nie otrzymywał wielu powiadomień, które nie wymagają reakcji.

Co zrobić z klientami istniejącymi już w obu systemach?

Najpierw porównuje się kartoteki i ustala zasady dopasowania. Jednoznaczne rekordy można połączyć według uzgodnionych identyfikatorów. Przypadki z różnymi adresami, nazwami lub danymi kontaktowymi wymagają wskazania wartości nadrzędnej albo ręcznej decyzji. Warto zachować raport z łączenia, aby później można było wyjaśnić pochodzenie danych.

Czy klient zobaczy notatki zapisane przez handlowca?

Zależy to od zakresu integracji, ale wewnętrzne notatki handlowe nie powinny automatycznie trafiać do konta klienta w sklepie. Pola przeznaczone do komunikacji z kupującym trzeba wyraźnie oddzielić od komentarzy wewnętrznych. Takie rozdzielenie ogranicza ryzyko przypadkowego ujawnienia informacji roboczych.

Czy po zmianie platformy sklepowej integrację trzeba zbudować od początku?

Zmiana platformy zwykle wymaga dostosowania części odpowiedzialnej za pobieranie i zapisywanie danych sklepu. Reguły biznesowe, mapowanie oraz uzgodniony model kartoteki mogą jednak pozostać przydatne. Przed migracją sprawdza się, czy nowa platforma udostępnia potrzebne dane i zdarzenia oraz czy zachowa identyfikatory umożliwiające połączenie wcześniejszej historii.

Spójna kartoteka zaczyna się od jasnych reguł

Dobra integracja sklepu z CRM nie polega na przesyłaniu największej możliwej liczby informacji. Jej zadaniem jest dostarczenie właściwych danych do miejsca, w którym są potrzebne, bez tworzenia duplikatów i bez niekontrolowanego nadpisywania zmian. Jasne wskazanie źródła danych, kierunku wymiany oraz sposobu obsługi wyjątków pozwala zbudować kartotekę, na której mogą polegać sprzedaż, obsługa klienta i osoby odpowiedzialne za sklep.