Klient oddaje telefon do naprawy. Następnego dnia dostaje wiadomość o gotowej wycenie, ale po jej dotknięciu trafia na ekran główny aplikacji. Musi szukać zlecenia albo zadzwonić do serwisu. Samo wysłanie powiadomienia zadziałało. Obsługa sprawy utknęła jednak dokładnie tam, gdzie miała stać się prostsza.
Ten hipotetyczny przykład dobrze pokazuje problem, z którym mierzą się twórcy aplikacji dla lokalnego handlu i usług. Powiadomienia dla klientów sklepu mają sens wtedy, gdy prowadzą do informacji potrzebnej w danym momencie i umożliwiają kolejny krok. Warto zaprojektować całą drogę: zdarzenie w systemie, zapis wiadomości, próbę dostarczenia sygnału oraz otwarcie właściwej sprawy.
Zacznij od sprawy, którą klient potrafi rozpoznać
Przyjmijmy, że serwis przygotował wycenę wymiany ekranu na 350 zł. Klient powinien zobaczyć, którego urządzenia dotyczy oferta, co obejmuje cena, do kiedy wycena obowiązuje i jak przekazać decyzję. Obsługa potrzebuje dodatkowo historii ustaleń oraz informacji, kto odpowiada za dalszy kontakt.
Dla zespołu projektowego to wskazówka, żeby połączyć wiadomość z identyfikatorem sprawy, punktem obsługi, uprawnionym odbiorcą i aktualnym stanem zlecenia. Sam adres e-mail lub numer telefonu nie wystarczy do opisania tej relacji. Jeden klient może mieć dwie naprawy, a ten sam punkt może obsługiwać go przez kilku pracowników.
W powiadomieniu wystarczy krótki komunikat: „Wycena naprawy jest gotowa. Sprawdź szczegóły w aplikacji”. Numer sprawy i pełne warunki można pokazać już po otwarciu odpowiedniego ekranu. Ograniczenie treści na ekranie blokady pomaga uniknąć ujawniania osobom postronnym danych, które są potrzebne wyłącznie klientowi.
Najpierw zachowaj wiadomość, potem wysyłaj sygnał
Praktycznym rozwiązaniem jest trwały zapis wiadomości w systemie i udostępnienie jej w skrzynce aplikacji. Push pełni wówczas rolę zaproszenia do otwarcia szczegółów. Gdy telefon pozostaje offline albo użytkownik wyłączy powiadomienia, informacja nadal czeka na niego po zalogowaniu.
Na etapie implementacji trzeba zadbać o spójność zapisu i wysyłki. Jeżeli zapis wyceny się powiedzie, a zlecenie wysyłki zniknie wskutek awarii, klient może nigdy nie dostać sygnału. Jednym ze sposobów ograniczenia tego ryzyka jest zapisanie zdarzenia do wysłania w tej samej transakcji bazy danych co zmianę sprawy. Osobny proces odczytuje zdarzenia i ponawia nieudane próby.
Ponowienia wymagają rozpoznawania duplikatów. Przykładowy klucz złożony z numeru sprawy, wersji wyceny i rodzaju zdarzenia pozwala stwierdzić, że tę samą wiadomość już utworzono. Nie daje to gwarancji pojedynczego dostarczenia na każdym urządzeniu, ale pomaga uniknąć tworzenia kolejnych identycznych wpisów w skrzynce klienta.
Link powinien otwierać właściwy ekran i sprawdzać dostęp
Kliknięcie wiadomości o wycenie powinno prowadzić do tej wyceny. Jeżeli sesja wygasła, aplikacja może najpierw poprosić o logowanie, a później wrócić do docelowej sprawy. Zgubienie celu podczas logowania to drobny błąd techniczny, który dla klienta oznacza konieczność ponownego szukania informacji.
Identyfikator umieszczony w linku nie może zastępować kontroli uprawnień. Serwer powinien sprawdzać przy odczycie, czy zalogowana osoba ma dostęp do wskazanej sprawy. Dotyczy to również sytuacji, gdy ktoś prześle link dalej lub otworzy go na urządzeniu z innym kontem. Kod QR punktu może ułatwiać rozpoczęcie kontaktu; dostęp do prywatnej historii wymaga osobnego zabezpieczenia.
Po otwarciu ekranu trzeba pobrać aktualny stan sprawy. Wycena mogła zostać poprawiona, zaakceptowana innym kanałem albo stracić ważność. Użytkownik powinien zobaczyć datę aktualizacji oraz dostępne teraz działania. Stara wiadomość może pozostać w historii, lecz nie powinna umożliwiać zatwierdzenia nieaktualnych warunków.
Zgoda na powiadomienia pojawia się w konkretnym momencie
Prośba o włączenie powiadomień jest bardziej zrozumiała po utworzeniu sprawy: klient wie już, że będzie czekać na wycenę lub termin odbioru. W interfejsie można wyjaśnić, jaką informację otrzyma, a dopiero później wyświetlić systemowe pytanie.
To ma także wymiar techniczny. Według dokumentacji Androida dotyczącej uprawnienia do powiadomień, na Androidzie 13 i nowszych wersjach zwykłe powiadomienia wymagają uprawnienia POST_NOTIFICATIONS. W nowo zainstalowanych aplikacjach są domyślnie wyłączone do czasu udzielenia zgody. Projekt powinien więc uwzględniać odmowę jako normalny stan działania.
Klient bez zgody nadal powinien móc sprawdzić historię i status po wejściu do aplikacji. Warto też oddzielić w ustawieniach informacje dotyczące prowadzonych spraw od wiadomości o promocjach. Dzięki temu wybór klienta jest czytelny, a pracownik nie traktuje każdej nowej sprawy jako okazji do wysłania reklamy.
Pięć prób, które warto wykonać przed uruchomieniem
Test samego pojawienia się dymka na telefonie obejmuje zaledwie fragment procesu. Poniższe sytuacje pozwalają sprawdzić, czy całość pozostaje użyteczna również przy błędach i zmianach:
- Klient odmawia powiadomień. Wiadomość pozostaje dostępna w skrzynce, a status zlecenia można sprawdzić ręcznie.
- Proces ponawia to samo zdarzenie. W historii nie pojawiają się kolejne identyczne wyceny.
- Telefon jest offline, a oferta w tym czasie wygasa. Po powrocie do sieci ekran pokazuje aktualny stan i wyjaśnia, jak uzyskać nową wycenę.
- Link zostaje otwarty na innym koncie. Aplikacja nie ujawnia cudzych danych ani nie pozwala podjąć decyzji w cudzej sprawie.
- Obsługę przejmuje inny pracownik. Widzi wcześniejsze ustalenia i kolejny krok bez proszenia klienta o opowiedzenie wszystkiego ponownie.
Jak ocenić gotowe narzędzie do obsługi klientów
Podobny kierunek organizacji kontaktu przedstawia Lokaloo.pl: wspólna aplikacja dla lokalnych firm, w której kontakt ma być powiązany z historią spraw i dalszymi ustaleniami. To użyteczny punkt odniesienia podczas rozmowy o potrzebach sklepu lub serwisu. Przed wyborem rozwiązania trzeba jednak sprawdzić zakres dostępnej wersji. Lokaloo udostępnia panel firmy i aplikację klienta. Dostępny zakres można sprawdzić podczas 14 dni bezpłatnych testów, bez karty i automatycznych opłat.
Na prezentację narzędzia warto przynieść własny scenariusz: przyjęcie urządzenia, przygotowanie wyceny, zmianę warunków, decyzję klienta i odbiór. Przejście go na dwóch kontach oraz z wyłączonymi powiadomieniami pokaże więcej niż oglądanie samego panelu. Pozwoli też ustalić, które funkcje działają obecnie, a które należą do planu rozwoju.
Po wdrożeniu przydatne będą osobne pomiary: ilu klientom utworzono wiadomość, do ilu urządzeń podjęto próbę wysyłki, ilu użytkowników otworzyło sprawę i ilu wykonało oczekiwane działanie. Przyjęcie komunikatu przez usługę push nie oznacza jeszcze, że klient go przeczytał. Nawet otwarcie ekranu nie dowodzi, że zrozumiał ofertę.
Ostatecznie liczy się domknięcie konkretnego zadania: klient znalazł wycenę, zna jej aktualne warunki i wie, co zrobić dalej. Jeśli po powiadomieniu nadal musi dzwonić z pytaniem „o którą sprawę chodzi?”, warto wrócić do projektu tej ścieżki.
Źródło ilustracji głównej: wygenerowana przy użyciu AI. Schemat: opracowanie własne.
Artykuł sponsorowany.
