Powiadomienia w aplikacji firmowej: które wysłać, a które zostawić w systemie

Pracownik otwiera pocztę i widzi kilkanaście wiadomości z aplikacji. Część informuje o zmianach w sprawach, którymi się nie zajmuje. Jedna prosi o decyzję potrzebną jeszcze dziś, ale wygląda tak samo jak pozostałe. System wysłał wszystko zgodnie z ustawieniami. Tyle że odbiorca musi teraz sam odszukać to, co wymaga działania.

Powiadomienie w aplikacji firmowej powinno pomagać podjąć kolejny krok. Zanim wybierzecie kanał lub kolor znacznika, ustalcie, co się wydarzyło, kto ma zareagować i ile czasu ma znaczenie dla procesu. Nie każde zdarzenie wymaga wiadomości e-mail. Czasem wystarczy historia w sprawie, a pilna decyzja potrzebuje wyraźniejszej drogi przekazania.

Opisane sytuacje są fikcyjne. Zasady powiadomień powinny wynikać z pracy konkretnej firmy, dostępnych kanałów i potrzeb użytkowników. Warto sprawdzić je z osobami, które faktycznie odbierają wiadomości, zamiast zakładać, że więcej informacji zawsze oznacza lepszą kontrolę.

Zacznij od zdarzenia i oczekiwanego działania

Dla każdej wiadomości zapiszcie, jakie zdarzenie ją uruchamia i co odbiorca ma zrobić. „Zmieniono status” jest mało pomocne, jeżeli nie wiadomo, której sprawy dotyczy zmiana ani czy wymaga reakcji. „Zlecenie wymaga przypisania wykonawcy” prowadzi do konkretnego zadania, pod warunkiem że osoba otrzymująca wiadomość może je wykonać.

W fikcyjnej firmie usługowej zgłoszenie trafia do koordynatora. Jeżeli brakuje adresu, aplikacja może wskazać osobie obsługującej klienta, jakiej informacji potrzebuje. Po uzupełnieniu adresu może przekazać zadanie dalej. Nie ma potrzeby wysyłać całej historii każdemu pracownikowi przy każdej zmianie pola.

Ustalcie także, co dzieje się, gdy nikt nie zareaguje. Czy zadanie przejmuje zastępca, czy informacja trafia do właściciela procesu? Czy pilność dotyczy wszystkich spraw, czy tylko wybranych? Przed ustawieniem przypomnienia sprawdźcie rzeczywisty rytm pracy. O przekazywaniu odpowiedzialności piszemy w artykule o automatyzacji zleceń serwisowych.

Wiadomość informacyjna i prośba o decyzję mogą wyglądać podobnie, ale mają inne zadanie. Jeśli odbiorca nie musi nic robić, napiszcie to wprost i pozwólcie wrócić do szczegółów w systemie. Jeżeli potrzebne jest zatwierdzenie, pokażcie, co będzie skutkiem decyzji. Naciskanie kolejnego przycisku nie powinno wymagać zgadywania, co właściwie zostanie zmienione.

Wybierz odbiorcę, nie całą listę adresową

Odbiorcą powinna być osoba lub zespół, który ma powód zobaczyć wiadomość i odpowiednie uprawnienia. Kierownik może potrzebować informacji o sprawie bez przydzielonego właściciela, a wykonawca jedynie o zadaniach przypisanych jemu. Zbyt szeroki krąg odbiorców zwiększa liczbę wiadomości i może ujawnić informacje osobom, które ich nie potrzebują.

Uwzględnijcie zastępstwa oraz zmiany w zespole. Jeśli pracownik jest nieobecny, czy wiadomość trafia do osoby przejmującej sprawę, wspólnej kolejki czy pozostaje do późniejszego odczytu? Wybór zależy od znaczenia zadania i godzin pracy. Reguła powinna być widoczna osobom odpowiedzialnym za proces, a nie ukryta w ustawieniach integracji.

Treść powiadomienia nie zawsze musi zawierać pełne dane sprawy. Wiadomość może informować o zadaniu i prowadzić do systemu, który ponownie sprawdzi dostęp. Zakres informacji w e-mailu, na ekranie blokady telefonu lub we wspólnym kanale trzeba dobrać do sposobu korzystania z urządzeń i wrażliwości danych.

W rozwiązaniu z wieloma oddziałami trzeba dodatkowo ustalić, czy odbiorca widzi tylko zadania swojej jednostki, czy także sprawy przekazane mu przez inny zespół. O wspólnych zasadach i lokalnych różnicach piszemy w tekście o systemie dla wielu oddziałów.

Przy zmianie struktury firmy sprawdźcie, czy stare listy odbiorców nadal odpowiadają obecnym obowiązkom. Powiadomienie skierowane do byłego opiekuna może pozostać bez reakcji, nawet jeżeli zostało technicznie wysłane poprawnie. Warto uzgodnić okresowy przegląd takich przypisań i wskazać osobę, która je aktualizuje.

Gdy powiadomienie dotyczy zmiany grafiku, trzeba także ustalić, kto może ją zaakceptować i kiedy staje się obowiązująca. Omawiamy to w artykule o planowaniu obsad i zamianie zmiany.

Kanał dobierz do czasu i sposobu pracy

Wiadomość w aplikacji może wystarczyć, gdy pracownik regularnie w niej pracuje. E-mail bywa przydatny do przekazania informacji poza systemem, ale może nie zostać zauważony od razu. Powiadomienie na telefonie także ma ograniczenia: użytkownik może nie mieć urządzenia przy sobie albo nie dopuścić danego rodzaju komunikatów. Projekt powinien uwzględniać rzeczywiste zachowanie zespołu.

Przy pilnej sprawie uzgodnijcie kanał zastępczy i odpowiedzialność za reakcję. Nie zakładajcie, że techniczne wysłanie wiadomości oznacza jej przeczytanie. Jeżeli zadanie wymaga potwierdzenia przejęcia, system powinien rejestrować osobną decyzję użytkownika, a nie wyciągać jej z faktu dostarczenia e-maila.

Dla informacji niewymagających natychmiastowego działania przydatne może być zestawienie zmian w określonym rytmie. Zespół powinien zdecydować, które zdarzenia można grupować, a które muszą pozostać osobne. Jedna zbiorcza wiadomość o dziesięciu aktualizacjach nie pomoże, jeśli ukryje jedną sprawę oczekującą na pilną decyzję.

Zanim połączycie kilka kanałów, sprawdźcie ich wzajemne działanie. Jeżeli ta sama osoba zamknie zadanie w aplikacji, późniejszy e-mail nie powinien nadal sugerować, że decyzja czeka. Można skierować odbiorcę do aktualnego stanu w systemie i jasno oznaczyć, że wiadomość pokazuje sytuację z określonego momentu.

Napisz komunikat, który da się wykorzystać

Dobry komunikat odpowiada na pytania: czego dotyczy, co się wydarzyło i jaki jest możliwy następny krok. W sprawie serwisowej może wskazywać identyfikator zlecenia i brakującą informację. Szczegóły dostępne po otwarciu zadania powinny pomóc rozwiązać problem bez przeszukiwania całej historii.

Unikajcie samego kodu błędu albo przycisku „sprawdź” bez kontekstu. Jeśli wiadomość dotyczy odrzuconego dokumentu, powiedzcie, czy plik jest za duży, ma nieobsługiwany format czy wymaga innej czynności, o ile system zna przyczynę. Gdy przyczyna nie jest jeszcze ustalona, lepiej wskazać sposób kontaktu i kolejny krok niż podać zmyślone wyjaśnienie.

Nie każda wiadomość powinna przerywać pracę. W3C opisuje komunikaty statusu, które informują o wyniku działania, postępie lub błędzie bez zmiany kontekstu użytkownika. Odpowiednia semantyka pozwala technologiom asystującym przekazać taką informację bez przenoszenia uwagi na inny element. Wybór zachowania należy sprawdzić w konkretnym interfejsie i z używanymi technologiami.

Znaczenie musi być zrozumiałe także bez samego koloru lub dźwięku. Tekst powinien określać, czy zadanie się udało, czy wymaga poprawki. Przy formularzu komunikat błędu musi pomóc znaleźć właściwe pole i zachować wcześniej wpisane informacje tam, gdzie jest to możliwe. W3C opisuje dostępne sposoby informowania o wynikach i błędach formularza.

Preferencje nie mogą ukrywać odpowiedzialności

W niektórych procesach użytkownik może wybrać kanał i częstotliwość mniej pilnych wiadomości. W innych firma musi wcześniej ustalić, jak przekazuje zadanie wymagające reakcji. Rozmowa o ustawieniach powinna rozróżniać wygodę odbiorcy od zasad obowiązujących dla konkretnego procesu. Nie zakładajcie, że każdy komunikat ma taką samą podstawę i może być obsługiwany identycznie.

Jeżeli ktoś zmieni preferowany adres lub urządzenie, sprawdźcie, kiedy zmiana zaczyna obowiązywać oraz co stanie się z wiadomościami już oczekującymi na wysłanie. Ważne jest również czytelne potwierdzenie zmiany dla użytkownika. Sam zapis w profilu nie odpowiada na pytanie, czy połączona usługa pocztowa pobrała aktualne ustawienie.

Dla wspólnej kolejki ustalcie, czy przypomnienia trafiają do wszystkich osób z dostępem, czy do tej, która przejęła zadanie. Jeśli nikt nie przejął sprawy, potrzebna może być inna reguła. Wybór powinien wynikać ze sposobu pracy zespołu i być możliwy do wyjaśnienia, gdy ktoś pyta, dlaczego otrzymał wiadomość.

Sprawdź, ile pracy tworzy samo powiadomienie

Przed włączeniem nowego typu wiadomości policzcie zdarzenia na przykładowych danych lub prześledźcie je podczas próby procesu. Pytanie brzmi, czy odbiorca dostanie kilka użytecznych sygnałów, czy serię komunikatów o każdej drobnej poprawce. Liczba zależy od sposobu pracy i nie powinna być zgadywana w ofercie.

Porozmawiajcie z odbiorcami o tym, co robią po otrzymaniu wiadomości. Jeśli zwykle otwierają kilka ekranów tylko po to, aby znaleźć osobę odpowiedzialną, problem może leżeć w treści lub w samym przebiegu sprawy. Dodanie kolejnego przypomnienia nie rozwiąże braku jasnego przydziału.

Po zmianie porównajcie ustalone sygnały: na przykład liczbę zadań przejętych przez właściwą osobę, liczbę powtórnych wiadomości i przykłady spraw pozostawionych bez reakcji. Nie wyciągajcie daleko idących wniosków z jednego dnia. Sprawdźcie także, czy ograniczenie wiadomości nie ukryło zadania, które nadal wymaga decyzji.

Przegląd powinien mieć właściciela. Zespół może usuwać komunikaty, które nie prowadzą do działania, poprawiać niejasne treści i zmieniać odbiorców po zmianach organizacyjnych. Każdą taką korektę warto przetestować na przykładach, aby pracownik nadal potrafił znaleźć sprawę i zrozumieć, co ma zrobić.

Zapobiegaj powtórzeniom i nieaktualnym wiadomościom

Jedno zdarzenie może przejść przez kilka systemów. Jeżeli każdy z nich wysyła powiadomienie o tym samym, odbiorca dostanie serię wiadomości bez dodatkowej wartości. Ustalcie właściciela komunikatu oraz sposób rozpoznania zdarzenia. Przy ponownym dostarczeniu danych sprawdźcie, czy system powinien wysłać nową wiadomość, czy zachować informację o wcześniejszej próbie.

Jeżeli połączenie z dostawcą powiadomień przestanie odpowiadać, wynik wysyłki może być nieznany. Ponowienie bez sprawdzenia potrafi spowodować duplikat, a brak ponowienia może pozostawić odbiorcę bez informacji. Możliwość ustalenia stanu zależy od konkretnej usługi. Opis granic komunikacji znajdziesz w artykule o integracjach API i webhookach.

Informacja może się również zestarzeć po wysłaniu. Zadanie przydzielone rano mogło zostać przejęte przez zastępcę, zanim pierwsza osoba odczytała wiadomość. Po otwarciu odnośnika użytkownik powinien zobaczyć aktualny stan i dostępne działania, a nie móc wykonać decyzję sprzeczną z późniejszą zmianą.

Właściciel procesu powinien wiedzieć, jak sprawdzić wiadomości oczekujące, błędy wysyłki i sprawy bez reakcji. Odpowiedzialność za taki sygnał omawiamy w tekście o monitorowaniu automatyzacji. Sam wykres wysłanych wiadomości nie pokazuje, czy odbiorca wykonał wymagane zadanie.

Sprawdź z zespołem, czy wiadomości pomagają

Przygotujcie przykładową sprawę i poproście pracownika o przejście od powiadomienia do wykonania zadania. Zobaczcie, czy rozumie, dlaczego dostał wiadomość, czy ma uprawnienia do sprawy oraz czy potrafi ustalić następny krok. Oddzielnie sprawdźcie wiadomość informacyjną, którą można przeczytać później.

Dodajcie nieobecność odbiorcy, zmianę właściciela, ponowne dostarczenie zdarzenia i zadanie zakończone przed odczytaniem e-maila. Sprawdźcie interfejs klawiaturą oraz przy użyciu technologii asystujących odpowiednich dla projektu. W artykule o testowaniu prototypu z pracownikami opisujemy, jak przygotować zadanie bez podpowiadania odpowiedzi.

Przed odbiorem zapiszcie, kto potwierdzi rezultat, jakie kanały zostaną sprawdzone i w jaki sposób użyjecie danych testowych. Kryteria odbioru aplikacji powinny obejmować nie tylko pojawienie się wiadomości, lecz także jej treść, odbiorcę i działanie po otwarciu sprawy.

Jeśli chcesz uporządkować komunikację w systemie, opisz w briefie najważniejsze zdarzenie, odbiorców i sytuację, która dziś prowadzi do nadmiaru wiadomości. Możemy omówić oprogramowanie na zamówienie i sposób testowania powiadomień. Napisz do Archifutura, używając przykładów bez danych klientów.