Centrum preferencji klienta: jak uporządkować kanały i zakres komunikacji

Klient zmienia adres e-mail i wyłącza wiadomości o promocjach. Mimo to po tygodniu dostaje kolejną ofertę na stary adres, a pracownik obsługi widzi w systemie dawną wersję ustawień. Problem nie musi wynikać ze złej woli. Preferencja mogła zostać zapisana w jednym narzędziu, podczas gdy wiadomość przygotowano w innym. Dla odbiorcy różnica jest niewielka: prośba nie została uszanowana.

Centrum preferencji klienta ma pomóc uporządkować takie decyzje. Powinno jasno pokazywać, jakie ustawienia dotyczą danej osoby, pozwalać je zmieniać i przekazywać aktualny stan do systemów odpowiedzialnych za komunikację. Zanim powstanie ekran z przełącznikami, trzeba jednak ustalić znaczenie każdego wyboru, źródło danych oraz sposób obsługi sytuacji, w której informacja nie dotarła na czas.

Jeżeli planujesz podobne rozwiązanie, wyślij brief z opisem kanałów, rodzajów wiadomości i systemów, które dziś przechowują ustawienia klientów. Wystarczy przykładowy przebieg zmiany bez rzeczywistych danych osobowych. Napisz też, gdzie obecnie pojawiają się rozbieżności i kto odpowiada za ich wyjaśnienie.

Najpierw rozdziel rodzaje wiadomości

Wyobraźmy sobie firmę usługową, która wysyła potwierdzenia wykonania zlecenia, przypomnienia o terminie i informacje o nowych usługach. Klient może chcieć otrzymywać potwierdzenia, ale nie interesować się ofertami. To przykład projektowy, a nie opis konkretnej firmy. Już na nim widać, że jeden przełącznik „wiadomości e-mail” może nie oddawać rzeczywistych potrzeb odbiorcy ani zasad poszczególnych procesów.

Zespół powinien przygotować spis wiadomości i wskazać ich cel. Inny charakter może mieć potwierdzenie działania zleconego przez klienta, inny informacja o zmianie usługi, a jeszcze inny oferta promocyjna. Przy każdej pozycji zapiszcie nadawcę, system wysyłkowy, odbiorców oraz osobę odpowiedzialną za treść. Nie zakładajcie, że podobny wygląd wiadomości oznacza identyczne zasady jej wysyłki.

Ustawienia widoczne użytkownikowi powinny odpowiadać tym rozróżnieniom. Jeżeli klient może wybrać określony rodzaj informacji, nazwa opcji musi wyjaśniać, czego dotyczy. Zamiast etykiety „pozostałe komunikaty” lepiej opisać faktyczną kategorię, o ile jest zrozumiała i potrzebna. Przy projektowaniu interfejsu pomogą zasady z artykułu o testowaniu prototypu z użytkownikami: poproście kilka osób o zmianę ustawień i sprawdźcie, jak rozumieją wynik. Jeżeli użytkownik może także samodzielnie zmienić dane konta, warto osobno zaplanować bezpieczną zmianę danych w portalu klienta.

Nie każda wiadomość musi podlegać temu samemu wyborowi, a sama preferencja nie zawsze jest zgodą w rozumieniu przepisów. Dla konkretnego procesu trzeba ustalić właściwą podstawę i wymogi dotyczące kanału oraz celu. Te decyzje powinny być uzgodnione przez osoby odpowiedzialne za zgodność i komunikację, a następnie odzwierciedlone w produkcie. Nie da się ich wyprowadzić wyłącznie z nazwy przycisku.

Pokaż stan zrozumiały dla odbiorcy

Dobry ekran pozwala rozpoznać, czego dotyczy ustawienie, jaki jest jego aktualny stan i co stanie się po zmianie. Jeżeli użytkownik wyłącza wiadomości o nowych usługach, potwierdzenie powinno odnosić się do tej konkretnej kategorii. Nie musi znać nazw list mailingowych ani systemów, które otrzymają aktualizację. Potrzebuje natomiast jasnej informacji, czy zmiana została zapisana i czy wymaga jeszcze jakiejś czynności.

Warto unikać pytań z podwójnym zaprzeczeniem. Przełącznik „nie rezygnuj z niewysyłania ofert” może być logiczny dla osoby, która go napisała, lecz nie pomaga nikomu w podjęciu decyzji. Nazwijcie opcję wprost i sprawdźcie, czy widoczny stan odpowiada tekstowi. Dostępna nazwa, obsługa klawiaturą i komunikat o błędzie są tak samo ważne jak wygląd przycisku.

Jeśli system obsługuje różne języki, nie wystarczy przetłumaczyć samej etykiety. Trzeba sprawdzić również opis skutku, potwierdzenie i wiadomość wyświetlaną przy błędzie. Zmiana oryginalnego tekstu powinna uruchamiać przegląd innych wersji. Użytkownicy powinni rozumieć tę samą decyzję niezależnie od języka interfejsu, choć dobór słów może wymagać innej konstrukcji.

Centrum preferencji nie musi żądać od klienta uzupełnienia każdego pola. W części spraw użytkownik przychodzi tylko po to, żeby wyłączyć jedną kategorię. Wymuszanie całej ankiety przed zapisaniem zmiany tworzy dodatkową przeszkodę. Dobrze zaprojektowana ścieżka pozwala wykonać zadanie i pokazuje pozostałe ustawienia wtedy, gdy są potrzebne.

Ustal, gdzie przechowywany jest aktualny stan

W praktyce dane mogą znajdować się w CRM, platformie mailingowej, aplikacji klienta i systemie obsługi zamówień. Jeśli każdy z nich dopuszcza zmianę tych samych ustawień, potrzebna jest reguła uzgadniania oraz informacja, skąd pochodzi ostatnia potwierdzona decyzja. Samo przesłanie żądania nie oznacza, że wszystkie systemy je przyjęły.

Wybierzcie właściciela każdej kategorii danych oraz sposób przekazywania zmian. Przydatna jest informacja o czasie zapisu, źródle aktualizacji i identyfikatorze osoby lub konta, którego dotyczy ustawienie. Jeżeli aktualizacja w systemie wysyłkowym zakończy się błędem, zespół powinien ją zobaczyć i wiedzieć, jak bezpiecznie ponowić operację. Artykuł o źródłach danych w integracji systemów pokazuje, jak rozpocząć takie uzgodnienia.

Trzeba także ustalić, co dzieje się w okresie między zapisem a potwierdzeniem zmiany w pozostałych narzędziach. Komunikat dla klienta powinien odpowiadać rzeczywistemu stanowi procesu. Jeżeli firma informuje o czasie potrzebnym na aktualizację, powinien on wynikać z możliwości systemów i ustalonych obowiązków, a nie z liczby wpisanej do projektu dla wygody. Gdy synchronizacja nie działa, potrzebny jest właściciel sprawy oraz plan reakcji.

W systemie wysyłkowym warto sprawdzić obowiązujący stan możliwie blisko momentu przygotowania wysyłki. Lista utworzona wcześniej mogła zawierać osoby, które od tego czasu zmieniły ustawienia. Reguła kontroli zależy od konkretnego narzędzia i procesu. Nie wystarczy założyć, że eksport przygotowany raz będzie zawsze aktualny.

Historia zmiany pomaga wyjaśnić problem

Gdy klient pyta, dlaczego otrzymał wiadomość, zespół potrzebuje danych pozwalających odtworzyć przebieg sprawy. Przydatne mogą być informacja o kategorii komunikacji, poprzednim i nowym stanie, czasie zmiany oraz źródle jej zapisania. Zakres historii powinien odpowiadać rzeczywistemu celowi i zasadom przechowywania danych. Nie trzeba zapisywać pełnej zawartości każdej wiadomości w każdym systemie.

Jeśli ustawienie zmienia pracownik obsługi na prośbę klienta, warto określić, w jaki sposób potwierdza tożsamość i opisuje podstawę zmiany. Pracownik nie powinien móc edytować cudzych preferencji tylko dlatego, że zna adres e-mail. Zakres uprawnień zależy od sposobu obsługi i ryzyka procesu. O planowaniu dostępu do danych piszemy w artykule o uprawnieniach do firmowych dokumentów; ta sama potrzeba rozpoznania użytkownika i zasobu pojawia się także w innych aplikacjach.

Jeżeli klient cofa zgodę, znaczenie mają zarówno możliwość wykonania tej czynności, jak i skuteczne przekazanie jej do właściwych procesów. Materiały Europejskiej Rady Ochrony Danych dotyczące zgody wyjaśniają między innymi, że jej wycofanie powinno być równie łatwe jak wyrażenie. To wskazówka dotycząca zgody na przetwarzanie danych, a nie odpowiedź na każde pytanie o podstawę i zasady wysyłki konkretnej wiadomości.

Przed wdrożeniem uzgodnijcie, jak długo potrzebna jest historia i kto może ją zobaczyć. Jeżeli w procesie obowiązują odrębne wymagania prawne lub umowne, trzeba je ocenić dla konkretnej sytuacji. Interfejs może pomagać w ich realizacji, ale sam nie rozstrzyga obowiązków organizacji.

Zadbaj o osoby korzystające z różnych kanałów

Jedna osoba może kontaktować się z firmą przez stronę, telefon i e-mail. Pracownik obsługi powinien wiedzieć, gdzie sprawdzić ustawienia oraz jak przekazać zmianę dalej. Jeśli formularz w aplikacji pokazuje jeden stan, a konsultant inny, klient ma prawo nie wiedzieć, któremu widokowi zaufać. Dlatego warto przetestować zmianę dokonaną w każdym kanale obsługiwanym przez firmę.

Przy wielu adresach lub numerach należy ustalić, czy preferencja dotyczy osoby, konta, konkretnego adresu czy relacji z daną firmą. Nie ma jednej odpowiedzi pasującej do każdego modelu współpracy. Przykładowo pracownik może występować jako osoba kontaktowa dla dwóch przedsiębiorstw i pełnić w nich różne role. Zmiana ustawienia powinna dotyczyć właściwego zakresu, a interfejs musi ten zakres wyjaśniać.

Warto też przewidzieć niedostępność konta. Jeżeli klient nie może się zalogować, powinien znać inną drogę zgłoszenia zmiany odpowiednią dla procesu. Zespół obsługi musi wtedy ustalić, jak zweryfikować zgłaszającą osobę i zapisać decyzję bez ujawniania informacji komuś nieuprawnionemu. Rozwiązanie powinno być wykonalne również poza idealnym scenariuszem demonstracyjnym.

Przy integracji kilku systemów przydatne jest rozróżnienie między otrzymaniem zdarzenia a jego skutecznym zastosowaniem. Jeśli komunikat o zmianie dotarł do kolejki, a zapis w platformie wysyłkowej się nie powiódł, zespół powinien widzieć różnicę. O takich etapach piszemy w artykule o API i webhookach w automatyzacji.

Sprawdź rzeczywisty przebieg przed wdrożeniem

Przygotujcie kilka scenariuszy z fikcyjnymi danymi. Klient wyłącza oferty w aplikacji, a następnie pracownik otwiera jego konto w systemie obsługi. Druga osoba dokonuje zmiany przez kontakt z konsultantem. W kolejnym przypadku integracja jest chwilowo niedostępna. Dla każdego scenariusza zapiszcie, jaki stan powinien pojawić się w poszczególnych miejscach i kto ma zareagować na błąd.

Sprawdźcie też, czy po wycofaniu ustawienia odpowiednia lista odbiorców jest aktualizowana przed następną wysyłką. Ważne są również wiadomości zaplanowane wcześniej: trzeba wiedzieć, czy i w którym momencie da się ponownie sprawdzić odbiorców. Możliwości zależą od konkretnego dostawcy, dlatego warto je potwierdzić w jego dokumentacji i podczas próby. Sam wygląd ekranu preferencji nie dowodzi działania całego przepływu.

Do testów włączcie osoby, które nie projektowały rozwiązania. Poproście je o sprawdzenie ustawienia, dokonanie zmiany i wyjaśnienie własnymi słowami, co właśnie zrobiły. Jeżeli uczestnik rozumie opcję inaczej niż zespół projektowy, warto poprawić tekst albo zakres decyzji. Przy odbiorze przydadzą się wcześniej uzgodnione rezultaty, o których piszemy w artykule o kryteriach odbioru aplikacji.

Zaplanuj utrzymanie i odpowiedzialność

Ustawienia komunikacji nie są jednorazowym projektem. Firma może dodać kanał, zmienić dostawcę albo uruchomić nowy rodzaj wiadomości. Ktoś powinien ocenić, czy istniejące kategorie nadal są zrozumiałe i czy nowe narzędzie otrzymuje aktualny stan. Przy zmianie definicji warto sprawdzić, jaki wpływ ma ona na wcześniejsze wybory i informacje przedstawiane klientom.

Zespół potrzebuje również sygnału o błędach synchronizacji, a nie tylko potwierdzenia, że strona się otwiera. Przydatna może być kolejka spraw wymagających wyjaśnienia, informacja o czasie ostatniej poprawnej aktualizacji oraz procedura dla pracownika obsługi. O doborze sygnałów i reakcji piszemy w tekście o monitorowaniu automatyzacji.

Na początek można wybrać jeden kanał i jedną kategorię komunikacji, prześledzić jej stan od decyzji klienta do systemu wysyłkowego, a dopiero potem rozszerzać zakres. Taką pracę warto prowadzić wspólnie z osobami od komunikacji, obsługi i danych. W integracjach systemów efektem powinno być nie tylko przesłanie zmiany, ale też możliwość sprawdzenia, czy trafiła tam, gdzie trzeba.