Masz działające kanały cyfrowe, ale obsługa polisy nadal szwankuje? Sprawdź, jak zachować ciągłość między self-service a infolinią

Co warto wiedzieć:

• Sam udział self-service nie mówi jeszcze, czy obsługa polisy jest efektywna. Warto patrzeć także na to, ile spraw wraca do konsultanta i ile pracy wymaga ich przejęcie.
• W ubezpieczeniach najwięcej problemów pojawia się zwykle na styku kanałów, danych i procesów. To tam powstają dodatkowe czynności, których klient nie widzi, ale organizacja za nie płaci.
• Ciągłość obsługi polisy można poprawić bez wymiany systemu core. Jednym ze sposobów jest warstwa, która łączy istniejące systemy wokół wspólnego stanu sprawy, dostępnego w aplikacji, portalu, u agenta i na infolinii.

Kiedy przejście na telefon zaczyna generować dodatkowy koszt?

EIOPA zwraca uwagę na specyfikę ubezpieczeń: w odróżnieniu od bankowości klient zwykle nie ma potrzeby regularnego korzystania z usług ubezpieczyciela. Kontakt pojawia się przy konkretnych okazjach, np. przy odnowieniu umowy albo przy zgłoszeniu szkody. Przy czym telefon, e-mail i kontakt osobisty nadal należą do najpopularniejszych kanałów, przez które klienci indywidualni kontaktują się z ubezpieczycielem.¹

Do tego dochodzą sprawy, które nie wpisują się w roczny rytm relacji z ubezpieczycielem: zmiana danych, korekta zakresu ochrony czy rozliczenie składki. W wielu z nich telefon nadal pozostaje wygodnym i często wybieranym kanałem obsługi, także wtedy, gdy firma rozwija aplikację i procesy self-service.

Część rozmów nie wynika jednak ze zwykłych preferencji. W badaniu Capgemini zapytano klientów ubezpieczeń na życie, co utrudnia im obsługę po zakupie polisy. Obok długiego czasu oczekiwania na kontakt z konsultantem wskazywano brak możliwości samodzielnego wykonania zmian na polisie: problem ten dotyczył 20% klientów indywidualnych i 28% klientów grupowych.² W takich przypadkach telefon staje się obejściem dla procesu, którego nie udało się zamknąć online.

Dlatego samego przejścia z kanału cyfrowego na infolinię nie powinniśmy traktować jako porażki self-service. Lepiej skupić się na tym, dlaczego klient zdecydował się zadzwonić (czy miał trudności z aplikacją lub stroną?) i przede wszystkim, co dzieje się ze sprawą po zmianie kanału. Jeżeli konsultant widzi jej status, wcześniejsze działania i przekazane już dane, może kontynuować proces bez dodatkowej pracy. Ukryty koszt pojawia się, gdy trzeba ponownie ustalić kontekst, zweryfikować informacje albo odtworzyć przebieg sprawy w kilku systemach.

Dlaczego organizacja traci kontekst sprawy między kanałami?

Przez lata rozwój cyfrowej obsługi oznaczał przede wszystkim uruchamianie kolejnych punktów kontaktu: aplikacji, portali klienta, formularzy online czy chatbotów. W wielu organizacjach każdy z tych kanałów powstawał jako kolejna warstwa nad istniejącą architekturą i procesami. Z perspektywy klienta front się zmieniał, ale po stronie operacyjnej sposób pracy często pozostawał znacznie bardziej rozproszony.

W praktyce konsultant może dziś mieć dostęp do wszystkich informacji potrzebnych do obsługi sprawy, tyle że znajdują się one w kilku różnych systemach:

• dane klienta i historia kontaktów w CRM,
• informacje o polisie w systemie polisowym,
• płatności w osobnym systemie,
• status dyspozycji lub zmiany w narzędziu procesowym,
• dokumenty i korespondencję w kolejnych repozytoriach.

Co się dzieje, gdy sprawa zaczyna żyć w kilku systemach?

Prześledźmy jedną dyspozycję. Klient wysyła ją w aplikacji w poniedziałek, a sprawa trafia do kolejki w narzędziu procesowym. We wtorek dzwoni, bo w portalu nadal widzi stare dane. Konsultant sprawdza CRM, system polisowy i narzędzie procesowe. Widzi, że dyspozycja czeka na walidację, ale nie wie, czy to normalny etap, czy proces utknął, więc zakłada drugą sprawę. W środę operacje dostają dwie dyspozycje dotyczące tej samej polisy i muszą ustalić, która jest aktualna.

Opóźnienie bierze się z przejść między systemami i z braku jednego miejsca, w którym widać aktualny stan sprawy. W efekcie pracownik musi sam zebrać informacje i ustalić, co już się wydarzyło oraz co powinno stać się dalej.

Dlatego dojrzałość cyfrową obsługi trudno oceniać wyłącznie liczbą uruchomionych kanałów. Znacznie więcej mówi zdolność organizacji do prowadzenia jednej sprawy przez różne kanały bez utraty jej historii, statusu i kontekstu.

Jak uporządkować przepływ informacji, gdy kanały cyfrowe już działają?

Skoro ubezpieczyciele mają za sobą lata inwestycji w portale, aplikacje, CRM-y i narzędzia wspierające obsługę, trudno uzasadnić kolejną dużą przebudowę tylko po to, żeby zapewnić płynniejszy przepływ spraw między kanałami. Potrzebna jest raczej warstwa, która pozwoli wykorzystać istniejące rozwiązania w ramach jednego procesu obsługowego.

W naszej platformie ubezpieczeniowej, Altkom Insurance Suite, taką rolę pełni moduł Policy Center. Zbudowaliśmy go jako wspólny punkt dostępu do danych i procesów związanych z obsługą polisy: od informacji o kliencie i samej polisie, przez płatności i dokumenty, po historię działań i zmiany wykonywane w trakcie jej życia.

Samo utworzenie wspólnego punktu dostępu do informacji nie wystarczy jednak, jeśli dane przekazywane między systemami są niepełne, nieaktualne albo nie pozwalają jednoznacznie określić, co dzieje się ze sprawą. Dlatego nawet tam, gdzie takie centrum już funkcjonuje, warto zacząć od sprawdzenia, jakich informacji rzeczywiście potrzebują kolejne kanały i zespoły, żeby przejąć proces bez odtwarzania kontekstu.

• Który system jest źródłem prawdy dla statusu sprawy?
• Czy wiadomo, kiedy dane zostały zaktualizowane i jaka operacja została już wykonana?
• Czy kolejny pracownik widzi nie tylko efekt, ale też to, czego brakuje do zakończenia procesu?

Taki przegląd pozwala sprawdzić, czy informacje dostępne w systemach rzeczywiście pomagają pracownikowi lub kolejnemu kanałowi zrozumieć stan sprawy i wykonać następny krok.

Jak Policy Center spina dane i procesy?

Policy Center obsługuje cykl życia polisy i wiąże go z informacjami o kliencie, zmianach, dokumentach oraz rozliczeniach. Zdarzenia pojawiające się w trakcie obsługi mogą uruchamiać odpowiednie operacje i zadania, dzięki czemu kolejne etapy procesu korzystają z tego samego kontekstu, niezależnie od kanału, w którym klient się pojawia.

Jednocześnie Policy Center nie musi przejmować roli wszystkich systemów działających u ubezpieczyciela. Altkom Insurance Suite ma architekturę mikroserwisową i integruje się z otoczeniem przez API, dlatego moduł może zostać połączony z istniejącymi kanałami, systemami core czy rozwiązaniami finansowymi. Pozwala to porządkować obsługę etapami i wykorzystać wcześniejsze inwestycje technologiczne, zamiast rozpoczynać zmianę od wymiany całego środowiska IT.

Jak zmienia się koszt obsługi, gdy kanały zaczynają pracować na wspólnym kontekście?

Chociaż Policy Center jest jednym ze sposobów uporządkowania problemu, to w zależności od architektury ubezpieczyciela podobną rolę może pełnić również indywidualnie zbudowana warstwa integracyjna lub usługowa. Taka warstwa powinna co najmniej łączyć dane z istniejących systemów, utrzymywać stan sprawy i udostępniać go wszystkim kanałom obsługi.

Chodzi więc nie tyle o wdrożenie konkretnego produktu, ile o stworzenie miejsca, w którym informacje potrzebne do prowadzenia sprawy są dostępne niezależnie od tego, gdzie klient rozpoczął kontakt.

Co to zmienia?

Dla Contact Center: mniej czasu na odtwarzanie historii klienta

Klient, który nie widział statusu zmiany w portalu, dzwonił na infolinię. Konsultant sprawdzał polisę, historię kontaktów i dyspozycję w kilku miejscach, czasem ponownie prosił o dane lub przekazywał sprawę do innego zespołu. Po spięciu procesu widzi od razu, co klient już zrobił, na jakim etapie znajduje się sprawa i czego jeszcze brakuje. Zamiast odtwarzać historię, kontynuuje obsługę.

Dla działów obsługowych: mniej ręcznej pracy i mniej duplikatów spraw

Podobnie zmienia się praca operacji. Informacje, które wcześniej trzeba było przepisywać lub ponownie weryfikować przy zmianie kanału, mogą być wykorzystane w dalszej części tego samego procesu. Ogranicza to liczbę ręcznych czynności, przekazań między zespołami i spraw wymagających ponownego wyjaśnienia.

Dla klienta: mniej powtarzania tych samych informacji

Zmiana jest odczuwalna także po stronie klienta. Jeśli może kontynuować sprawę niezależnie od kanału, nie musi za każdym razem odtwarzać jej historii, ponownie opisywać problemu ani przekazywać tych samych danych. Obsługa staje się dzięki temu bardziej płynna, a przejście z aplikacji do infolinii nie oznacza zaczynania procesu od początku.

Prostszy rozwój kolejnych kanałów po stronie IT

Zmiana jest widoczna także po stronie IT. Kolejny kanał nie musi od początku budować własnych integracji i własnej logiki obsługi polisy. Może korzystać ze wspólnej warstwy danych i procesów, co zmniejsza liczbę połączeń punkt-punkt i upraszcza dalszy rozwój środowiska.

Co dalej z obsługą polisy między kanałami?

Spójna obsługa polisy nie zależy więc od liczby dostępnych kanałów, ale od tego, czy wszystkie korzystają z tego samego kontekstu sprawy. Jeśli dane, historia działań i stan procesu pozostają dostępne niezależnie od punktu kontaktu, kolejne inwestycje w digital mogą rzeczywiście ograniczać pracę operacyjną, zamiast przenosić ją między zespołami.