Automatyczne przypomnienia o terminach: jak wybrać właściwego odbiorcę

Klient otrzymuje przypomnienie o wizycie, którą przełożył dzień wcześniej. Pracownik dostaje wiadomość o zadaniu, które zdążył już zamknąć. W obu przypadkach powiadomienie mogło zostać zaplanowane poprawnie, a mimo to wysłane na podstawie nieaktualnych danych. Dobre przypomnienie wymaga sprawdzenia nie tylko terminu, lecz także bieżącego stanu sprawy i właściwego odbiorcy.

Automatyczne przypomnienia o terminach pomagają zespołom wrócić do sprawy we właściwym czasie. Zanim jednak system zacznie wysyłać wiadomości, trzeba ustalić źródło terminu, zasady zmian, zastępstwa i sytuacje, w których zaplanowane działanie powinno zostać odwołane. Ważne jest również to, co aplikacja pokaże, gdy nie uda się potwierdzić wysyłki.

Jeśli planujesz taki proces, wyślij brief z przykładem sprawy, jej terminu i osób, które powinny otrzymać przypomnienie. Możesz opisać fikcyjną sytuację bez danych klientów. Przyda się informacja, co dzieje się dziś po zmianie daty albo przejęciu sprawy przez inną osobę.

Określ zadanie, do którego prowadzi wiadomość

Wyobraźmy sobie firmę serwisową, która przypomina pracownikom o planowanym przeglądzie urządzenia. Wiadomość ma skierować osobę prowadzącą do właściwego zlecenia, gdzie może sprawdzić lokalizację i przygotowanie części. To przykład projektowy, nie opis konkretnego wdrożenia. Zanim pojawi się harmonogram, zespół powinien ustalić, jaka czynność ma nastąpić po otrzymaniu wiadomości.

Przypomnienie o zbliżającym się terminie ma inny cel niż informacja o zmianie osoby odpowiedzialnej. Pierwsze może pomagać w przygotowaniu pracy, drugie wyjaśniać przekazanie sprawy. Ich treść, odbiorcy i moment wysyłki nie muszą być takie same. Warto zapisać te różnice, aby system nie wysyłał jednakowej wiadomości przy każdym zdarzeniu. Szersze zasady doboru kanału i odbiorcy opisujemy w artykule o powiadomieniach w aplikacji firmowej.

Dobrze określić, co oznacza wykonanie zadania. Jeśli pracownik potwierdził termin, ale przegląd jeszcze się nie odbył, przypomnienie o przygotowaniu może być nadal potrzebne. Jeśli sprawę anulowano, kolejna wiadomość o planowanym terminie będzie myląca. Status sprawy powinien zatem odpowiadać rzeczywistej pracy, a reguła wysyłki musi uwzględniać jego znaczenie.

O tym, jak przeprowadzić zlecenie od zgłoszenia do zamknięcia, piszemy w artykule o automatyzacji zleceń serwisowych. Przypomnienie jest tylko jednym z etapów takiego procesu. Nie zastępuje informacji o tym, kto przejął zadanie i czy zostało wykonane.

Ustal źródło daty i odbiorcy

Termin może znajdować się w systemie zleceń, kalendarzu, wiadomości od klienta albo arkuszu używanym przez oddział. Przed zbudowaniem automatyzacji trzeba ustalić, które źródło jest obowiązujące oraz kto może zmienić datę. Jeśli dwa systemy podają różne wartości, potrzebna jest procedura wyjaśnienia, a nie wybór tej, która akurat dotarła ostatnia.

Odbiorca również może się zmienić. Pracownik przechodzi do innego zespołu, jest nieobecny albo przekazuje sprawę zastępcy. Warto ustalić, czy przypomnienie ma trafić do osoby zapisanej w chwili planowania, czy do aktualnego właściciela sprawy. Dla niektórych działań potrzebny może być zespół dyżurny zamiast jednego adresu. Każde z tych rozwiązań wymaga sprawdzenia uprawnień i aktualności danych.

Przy wielu systemach zapiszcie, skąd pochodzi informacja o właścicielu, kiedy jest aktualizowana i co zrobić, jeśli przypisanie jest puste. Przekazanie wiadomości na domyślny adres może pomóc, ale tylko wtedy, gdy ktoś naprawdę sprawdza tę skrzynkę i potrafi przejąć sprawę. Artykuł o źródłach danych w integracji pokazuje, jak zacząć takie ustalenia.

Jeśli odbiorca należy do organizacji klienta, ważny jest również zakres ujawnianych informacji. Wiadomość z numerem sprawy może być wystarczająca, podczas gdy pełny opis dokumentów powinien pozostać w chronionej aplikacji. Wybór zależy od procesu, kanału i uprawnień. Link powinien prowadzić do sprawy dostępnej tylko właściwym osobom.

Co zrobić, gdy data lub stan się zmieni

Załóżmy, że przypomnienie zaplanowano na poniedziałek, a w piątek termin przesunięto na kolejny tydzień. System powinien ustalić, co zrobić z dotychczasowym zadaniem: odwołać je, zastąpić nowym albo sprawdzić aktualne dane bezpośrednio przed wysyłką. Możliwości zależą od wybranego narzędzia, dlatego regułę trzeba przetestować w konkretnej konfiguracji.

Samo usunięcie zaplanowanego zadania może nie wystarczyć, jeżeli zostało już przekazane do kolejnego etapu wysyłki. Dlatego przed wykonaniem działania przydaje się ponowne sprawdzenie stanu sprawy, terminu i odbiorcy. Jeśli zadanie zostało zamknięte albo data się zmieniła, wiadomość nie powinna korzystać ze starego kontekstu. Trzeba też zdecydować, czy nowa sytuacja wymaga utworzenia kolejnego przypomnienia.

Dokumentacja AWS EventBridge Scheduler opisuje między innymi usuwanie harmonogramów. Jest to przykład możliwości konkretnej usługi, a nie gwarancja zachowania innych narzędzi. Przed wdrożeniem należy sprawdzić, kiedy można anulować zadanie oraz co dzieje się z działaniem, które już zostało przekazane dalej.

Użytkownik zmieniający termin powinien zobaczyć czytelny rezultat. Jeśli aplikacja przyjęła zmianę, ale aktualizacja drugiego systemu nadal trwa, komunikat nie może sugerować zakończenia całego procesu. W przypadku błędu potrzebna jest osoba odpowiedzialna za wyjaśnienie rozbieżności. O praktycznym znaczeniu stanu integracji piszemy w artykule o API i webhookach.

Nie wysyłaj dwa razy po niepewnej odpowiedzi

Połączenie z dostawcą wiadomości może zakończyć się błędem po przekazaniu żądania. Wtedy aplikacja może nie wiedzieć, czy dostawca przyjął wiadomość. Ponowienie bez sprawdzenia dostępnego potwierdzenia może prowadzić do dwóch przypomnień. Przy projektowaniu trzeba ustalić, jakie identyfikatory i statusy udostępnia konkretna usługa oraz jak rozpoznać próbę dotyczącą tego samego zadania.

Zapis techniczny powinien pomagać odtworzyć przebieg: która sprawa, jaki rodzaj przypomnienia, kiedy zaplanowano działanie i jaki stan udało się potwierdzić. Nie jest konieczne przechowywanie w każdym dzienniku pełnej treści wiadomości i wszystkich danych odbiorcy. Zakres informacji należy dopasować do obsługi błędów oraz uprawnień osób, które mają dostęp do zapisów.

Ważne jest rozróżnienie między przyjęciem wiadomości przez usługę a jej dostarczeniem lub przeczytaniem. Dostępność takich informacji zależy od kanału i dostawcy. Interfejs nie powinien obiecywać, że odbiorca zapoznał się z treścią, jeśli posiada tylko potwierdzenie przyjęcia żądania. Osoba prowadząca sprawę musi wiedzieć, na jakiej informacji może się oprzeć.

Po wyczerpaniu uzgodnionej liczby prób potrzebna jest dalsza droga obsługi. Może nią być kolejka wyjątków albo powiadomienie zespołu odpowiedzialnego za proces. Nie każde opóźnienie wymaga alarmu, lecz sprawa nie powinna znikać bez śladu. Więcej o sygnałach i osobach reagujących piszemy w artykule o monitorowaniu automatyzacji.

Zadbaj o treść i czas odbioru

Przypomnienie powinno mówić, czego dotyczy, jaki termin obowiązuje i gdzie znaleźć dalsze informacje. Jeżeli odbiorca ma wykonać czynność, warto nazwać ją wprost. Unikajcie wiadomości, która podaje numer sprawy bez możliwości sprawdzenia, o co chodzi. Z drugiej strony nie należy przesyłać pełnej historii klienta, jeśli wystarczy bezpieczny odnośnik do systemu.

Moment wysyłki powinien wynikać z pracy odbiorcy. Pracownik przygotowujący wizytę może potrzebować informacji wcześniej niż osoba, która ma tylko potwierdzić wykonanie zadania. Przy zespołach w różnych lokalizacjach trzeba ustalić strefę czasową oraz znaczenie terminu. Data kalendarzowa i konkretny moment nie są zawsze tym samym, dlatego warto potwierdzić oczekiwane zachowanie z osobą prowadzącą proces.

Przy dużej liczbie spraw rozważcie grupowanie informacji, ale sprawdźcie, czy odbiorca nadal potrafi rozpoznać pilne zadanie. Jedna wiadomość zawierająca zbyt wiele różnych terminów może ukryć sprawę wymagającą reakcji. Z kolei osobna wiadomość o każdej drobnej zmianie może utrudnić zauważenie ważnego zdarzenia. Decyzję należy podjąć na podstawie sposobu pracy zespołu.

Jeśli przypomnienia trafiają do klientów, ustalcie również zasady komunikacji dla konkretnego celu i kanału. Informacja związana z usługą może mieć inne wymagania niż oferta marketingowa. Nie warto projektować jednego ustawienia bez oceny wszystkich rodzajów wiadomości. Przy wyborze tekstów i pól przydaje się próba z użytkownikami opisana w artykule o testowaniu prototypu.

Przetestuj zmianę, zastępstwo i awarię

Przed uruchomieniem przygotujcie fikcyjne sprawy dla kilku użytkowników. Sprawdźcie zmianę terminu przed wysyłką, anulowanie zadania, przekazanie sprawy zastępcy i zamknięcie jej tuż przed zaplanowanym czasem. Dla każdego przypadku ustalcie, czy wiadomość powinna zostać wysłana i kto ma ją otrzymać. Oczekiwany wynik należy zapisać przed próbą.

Dodajcie niedostępność dostawcy i sytuację, w której potwierdzenie nie dotarło. Sprawdźcie, czy pracownik widzi stan sprawy, czy ponowienie nie powoduje duplikatu oraz jak można ręcznie wyjaśnić niepewny wynik. Jeśli wysyłka jest tylko jednym etapem większego procesu, test powinien obejmować także zmianę statusu w systemie źródłowym.

Warto zaprosić przyszłych odbiorców do oceny treści. Poproście ich o wskazanie zadania wynikającego z wiadomości, terminu oraz miejsca, w którym znajdą szczegóły. Jeśli muszą zgadywać, poprawcie komunikat przed rozszerzeniem procesu. Kryteria takich prób można zapisać zgodnie z podejściem opisanym w artykule o odbiorze aplikacji.

W planie testów uwzględnijcie także sytuację, w której osoba odpowiedzialna zmienia się wielokrotnie. Przypomnienie utworzone dla pierwszego pracownika nie powinno ujawniać mu szczegółów sprawy po odebraniu dostępu. Przed wysyłką warto ponownie sprawdzić aktualne przypisanie i uprawnienie. Jeżeli system nie potrafi ustalić właściwego odbiorcy, sprawa powinna trafić do uzgodnionej obsługi zamiast do przypadkowego adresata.

Przy sprawach powtarzalnych ustalcie, co oznacza wykonanie jednej czynności dla kolejnych terminów. Potwierdzenie przeglądu w tym miesiącu nie musi oznaczać odwołania przypomnienia na następny okres. Z kolei wycofanie urządzenia z użytku może wymagać zatrzymania całego cyklu. Warto sprawdzić te przypadki z osobami odpowiedzialnymi za rejestr urządzeń i nie opierać reguły wyłącznie na dacie w kalendarzu.

Po zmianie kanału wysyłki lub dostawcy ponownie sprawdźcie możliwości potwierdzeń, limitów oraz anulowania zaplanowanych wiadomości. Różne usługi mogą przedstawiać status w odmienny sposób. Zespół powinien znać znaczenie komunikatów oraz wiedzieć, kiedy potrzebne jest sprawdzenie bezpośrednio u dostawcy. Taka dokumentacja pomaga także osobie zastępującej dotychczasowego opiekuna integracji.

Jeżeli odbiorca zgłasza, że wiadomość nie dotarła, procedura powinna zacząć się od ustalenia właściwej sprawy i dostępnego potwierdzenia. Nie zawsze będzie można stwierdzić, co stało się z wiadomością po jej przekazaniu do usługi zewnętrznej. Wtedy pracownik może wybrać uzgodniony kanał kontaktu i zapisać wynik przy sprawie, zamiast wysyłać wiele kolejnych przypomnień na ślepo.

Dobrze wyznaczyć także termin przeglądu reguł wysyłki. Po zmianie organizacji zespołu lub rodzaju usługi dawne przypomnienie może trafiać do osoby, która nie odpowiada już za zadanie.

Po uruchomieniu obserwujcie przypadki, w których przypomnienie dotarło po zmianie stanu albo do niewłaściwej osoby. Zespół powinien móc zgłosić taki problem i prześledzić, z jakich danych skorzystał system. W automatyzacjach i workflow zadanie jest zakończone dopiero wtedy, gdy przypomnienie wspiera rzeczywistą pracę, a nie tylko pojawia się w skrzynce.