CCM, CRM czy ESP? Jak stworzyć architekturę komunikacyjną w banku lub firmie ubezpieczeniowej

Masz CRM (Customer Relationship Management), który zarządza relacją firmy z obecnymi i potencjalnymi klientami. Masz ESP (Email Service Provider) do wysyłki kampanii. I mimo to przy każdej zmianie regulacyjnej może wrócić ten sam problem: nikt nie potrafi z pewnością powiedzieć, co dokładnie trafia do klientów, przez który kanał i w której wersji.

Nie dlatego, że systemy nie działają. Działają. Problem leży gdzie indziej: każdy z nich odpowiada za inny kawałek procesu, działa w innym tempie i jest zarządzany przez inny zespół. A w miejscu, gdzie te kawałki powinny złożyć się w spójną całość, często nie ma niczego.

Ten artykuł dotyczy architektury: jak te systemy działają względem siebie, gdzie każdy z nich osiąga swoje granice i co brakuje między nimi.

Dlaczego CRM i ESP nie zastępują się nawzajem

Najczęstszy błąd przy projektowaniu architektury komunikacyjnej to traktowanie tych systemów jako zamienników. Każdy z nich działa w fundamentalnie innym rytmie organizacyjnym.

• CRM (n.p. Salesforce, Microsoft Dynamics, Oracle) żyje w rytmie relacji z klientem. Klient kupuje produkt, zmienia segment, wchodzi do oddziału, i dane się aktualizują. Strona dokumentowa tej historii nie jest jego zmartwieniem: CRM nie wie, że ktoś, gdzieś, musi właśnie teraz wysłać umowę. Dział sprzedaży to wie, bo dla niego CRM to karta klienta, a nie silnik komunikacji.
  
• ESP żyje w zupełnie innym cyklu. Segmenty, harmonogramy wysyłek, testy A/B. Zmiana szablonu e-maila to kwestia kilku godzin. Compliance nie jest tym, do czego te systemy są zbudowane. Kiedy marketing uruchamia kwartalną kampanię cross-sell, ESP działa dokładnie tak, jak został zaprojektowany. Kiedy ten sam zespół ma wysłać zmianę warunków umowy, zaczynają się problemy, ale o tym poniżej.

CCM to warstwa, która spina te dwa rytmy i sprawia, że doświadczenie klienta staje się omnichannelowe i bezpieczne pod kątem compliance. Pobiera dane klienta z CRM, generuje dokument w wymaganym formacie, dostarcza go przez właściwy kanał (e-mail, druk, portal, SMS), a jednocześnie prowadzi ścieżkę audytową, wersjonuje szablon i zapewnia zgodność z PDF/UA oraz EAA.

Innymi słowy, robi to, czego CRM i ESP nigdy nie miały robić.

Gdzie CRM i ESP osiągają swoje granice

Każdy z tych systemów ma swoje uzasadnione miejsce w architekturze. Każdy ma też punkt, w którym przestaje wystarczać.

CRM: dane o kliencie, a nie oficjalne dokumenty i komunikacja do klienta

CRM wie, kiedy sprzedaż ostatnio dzwoniła i do jakiego segmentu należy dany klient. To fundament, na którym opiera się wszystko inne.

Większość systemów CRM potrafi wygenerować dokument z szablonu, na przykład gotową fakturę albo ofertę. Ale na tym się kończy. Wersjonowanie szablonów, które przetrwałoby audyt zgodności, w CRM nie istnieje, bo model danych nigdy nie był zaprojektowany tak, by przechowywać zatwierdzone wersje regulowanego dokumentu w czasie. 

Obsługa druku nie jest realizowana, bo CRM nie ma pojęcia o strumieniu wydruku, dostawcy fulfilmentu ani o SLA pocztowym. I nie ma logu tego, kto co wysłał, kiedy i która wersja wyszła. CRM rejestruje, że e-mail został wysłany, a nie którą wersję szablonu bazowego użyto w momencie wysyłki.

Organ prowadzący audyt może zapytać: pokażcie dokładną wersję pisma, które wysłaliście temu klientowi czternaście miesięcy temu, oraz podstawę prawną jego wydania. CRM nie ma odpowiedzi.

ESP: dobry do kampanii komunikacyjnych, ale nie do compliance

ESP wysyła e-mail szybko, na dużą skalę, z personalizacją opartą na segmentach i z głęboką automatyzacją. Do kampanii cross-sell i powiadomień promocyjnych to właściwe narzędzie, bo dokładnie do tego zostało zbudowane.

Nie jest jednak narzędziem compliance. Szablony nie są wersjonowane w sposób, który mógłby wykorzystać audytor, bo platforma traktuje szablon jak wersję roboczą, którą można dowolnie edytować aż do momentu naciśnięcia przycisku wysyłki. Druk i inne kanały leżą poza jego zakresem, bo ESP zostały zaprojektowane pod jedną metodę dostarczania. Komunikacja regulowana nigdy nie była intencją projektową.

Personalizacja pogarsza sprawę. Kampania z dwustoma segmentami i dynamicznymi blokami treści to potencjalnie dwieście wariantów tego samego regulowanego komunikatu, a ESP nie zapisze żadnego z nich jako wersjonowanego artefaktu. Platforma powie ci, że e-mail wyszedł i że klient go otworzył. Nie powie ci, jaką dokładnie treść klient zobaczył.

Wysłanie zmiany warunków umowy przez ESP oznacza wysłanie dokumentu prawnego przez platformę marketingową. Nie ma wersjonowania regulowanej treści. Nie ma gwarancji, że wersja e-mailowa odpowiada wersji papierowej. Nie ma sposobu, by czternaście miesięcy później udowodnić, że klient otrzymał dokładnie tę treść, która obowiązywała w dniu wejścia zmiany w życie.

CCM: łączenie kropek w całość

Każda luka, w której CRM i ESP przestają wystarczać, to dokładnie obszar, za który odpowiada CCM:

Dwa główne scenariusze, w których brak CCM staje się widoczny

Zmiana regulacyjna. Regulator ogłasza nowy obowiązek informacyjny. Organizacja ma CRM i ESP, ale żaden z tych systemów nie zarządza szablonami dokumentów klienckich centralnie. Każdy kanał jest aktualizowany niezależnie, przez różne zespoły, w różnych systemach, bez gwarancji spójności. Terminy są zbyt napięte, żeby przeprowadzić skoordynowaną zmianę IT we wszystkich z nich jednocześnie. Któryś kanał zostaje z nieaktualną wersją, i nikt nie zauważa luki, dopóki nie pojawi się audyt.

Kiedy audyt regulacyjny w końcu się pojawia, regulator żąda dokumentacji całej komunikacji z klientami za poprzednie 12 i więcej miesięcy: które wersje szablonów były używane, kiedy, do kogo i na jakiej podstawie prawnej. CRM przechowuje historię kontaktów, a ESP przechowuje logi wysyłek. Żaden z tych systemów nie potwierdzi, która wersja szablonu była aktywna w danym dniu ani czy dokument, który wyszedł, był z nią spójny. Odtworzenie tej historii ręcznie, z dwóch systemów, zajmuje tygodnie i rzadko daje pełny obraz.

Nowy kanał komunikacji wynikający ze zmiany oczekiwań klientów, modernizacji technologicznej lub rozwoju organizacji. Na przykład organizacja dodaje SMS jako kanał powiadomień regulacyjnych. Bez CCM oznacza to nowy projekt IT: osobną integrację, osobną logikę szablonów, osobny proces zatwierdzania i nowe źródło niespójności z pozostałymi kanałami. Z CCM to zadanie konfiguracyjne w istniejącej platformie. Szablony, logika biznesowa i ścieżka audytowa pozostają niezmienione.

Architektura przepływu danych, która umożliwia zarówno sprawność operacyjną, jak i zgodność z przepisami

Każda organizacja jest inna. Ale w projektach bankowych i ubezpieczeniowych, które realizujemy w całej Europie, wyłania się kilka zasad architektonicznych, których brak niezawodnie prowadzi do jednego z dwóch scenariuszy opisanych powyżej.

Kiedy architektura jest kompletna, z wszystkimi wejściami i wyjściami, zmiana regulacyjna nie uruchamia projektu IT, wymaga tylko aktualizacji szablonu. Audyt nie oznacza tygodni ręcznego odtwarzania historii z dwóch systemów, bo odpowiedź istnieje w jednym miejscu. A dodanie nowego kanału to zadanie konfiguracyjne, a nie nowa integracja.

Dlaczego CCM tak często jest brakującą warstwą

W sektorze bankowości i ubezpieczeń każdy dokument wysyłany do klienta pełni jednocześnie kilka funkcji: 

• jest obowiązkiem prawnym
• punktem odniesienia dla spójności marki 
• zapisem transakcyjnym klasy archiwalnej
• elementem głęboko zautomatyzowanego doświadczenia klienta
• potencjalnym dowodem w postępowaniu regulacyjnym
• oraz programatycznym silnikiem cross-sellingu generującym przychód

CRM i ESP były projektowane z myślą o jednej lub dwóch z tych ról. CCM musi spełnić wszystkie naraz, dla każdego dokumentu, przez każdy kanał, przy każdej zmianie regulacyjnej.

Dlatego decyzja o wdrożeniu CCM nie jest decyzją o dodaniu kolejnego narzędzia. Częściej jest to decyzja o tym, że organizacja nie będzie już akceptować sytuacji, w której nikt nie odpowiada naprawdę za to, co faktycznie trafia do klientów.

Jak ta warstwa wygląda w praktyce i co jej brak kosztuje organizacje, które przez lata próbowały wypełnić tę rolę zlepkiem istniejących systemów, opisujemy w naszym artykule o rzeczywistym koszcie utrzymania środowisk legacy CCM.

Podsumowanie

Właściwe pytanie nie brzmi „który system wybrać?". Brzmi ono: „czy nasza architektura zawiera warstwę, która rzeczywiście odpowiada za regulowaną komunikację z klientami i czy jest naprawdę zdolna sprostać tej odpowiedzialności?"

Jeśli odpowiedź brzmi „CRM obsługuje część tego" albo „wysyłamy to przez ESP", to jest dokładnie ten moment, żeby uważnie przyjrzeć się architekturze. Zanim zrobi to za was regulator.