Wiadomość opisuje zdarzenie, ale nim nie jest
Oferta może zostać zatwierdzona, mimo że e-mail z potwierdzeniem nie został jeszcze wysłany. Warto oddzielić stan sprawy od stanu powiadomienia. Inaczej chwilowy błąd poczty może cofać prawidłową operację biznesową albo powodować jej ponowienie. System powinien pamiętać, co wydarzyło się w programie, oraz osobno, kogo trzeba o tym poinformować.
W przykładowej firmie serwisowej technik kończy naprawę, a klient ma otrzymać informację o odbiorze. Zapis statusu powinien być trwały. Zadanie wysyłki może oczekiwać w kolejce, gdy dostawca poczty jest niedostępny. Użytkownik panelu musi jednak widzieć, że powiadomienie nie zostało jeszcze przekazane, zamiast polegać na ogólnym komunikacie „zapisano”.
Zdefiniuj katalog komunikatów
Dla każdego typu wiadomości określ zdarzenie, odbiorcę, treść i warunek wysłania. Potwierdzenie przyjęcia zgłoszenia ma inne znaczenie niż informacja o terminie realizacji. Przypomnienie nie powinno trafić do osoby, której sprawa została już zamknięta. Warunki warto sprawdzać przy wykonywaniu zadania, ponieważ dane mogą się zmienić od chwili jego utworzenia.
Ustal, czy treść ma odzwierciedlać stan z momentu zdarzenia, czy najnowszą informację. Dla zaakceptowanej oferty zwykle potrzebna jest konkretna wersja; dla przypomnienia o terminie istotny jest termin aktualny. Bez tej decyzji opóźniona kolejka może wysłać klientowi dawne dane, które formalnie były poprawne w chwili przygotowania zadania, ale dziś wprowadzają w błąd.
Zapisz zamiar wysyłki razem ze zmianą
Jeśli zmiana statusu i dodanie powiadomienia są dwiema niezależnymi operacjami, awaria między nimi może zgubić wiadomość. Wzorzec transactional outbox łączy zapis danych biznesowych z wpisem do kolejki w jednej transakcji. Oddzielny proces odczytuje później zadania. Dokumentacja AWS opisuje także konieczność obsługi powtórzeń podczas takiego przekazywania.
Każdy komunikat powinien mieć identyfikator pozwalający rozpoznać ponowienie. Warto powiązać go z typem zdarzenia, odbiorcą i wersją danych, zamiast z samą godziną uruchomienia skryptu. Kilka uruchomień harmonogramu nie powinno tworzyć kilku identycznych potwierdzeń. Jednocześnie prawdziwa zmiana terminu może wymagać nowej wiadomości, mimo podobnej treści.
Zrozum granicę potwierdzenia SMTP
Pozytywna odpowiedź serwera SMTP po przekazaniu treści oznacza przyjęcie odpowiedzialności za dalszą obsługę wiadomości, a nie dowód przeczytania przez adresata. Późniejsze problemy mogą być zgłaszane odrębnie. Zasady przyjmowania, błędów i ponowień opisuje RFC 5321. Interfejs programu powinien unikać nazywania samego przyjęcia przez serwer pewnym doręczeniem do skrzynki odbiorczej.
MyTworzymy.pl obsługuje przedsiębiorstwa w całej Polsce i może pomóc zaplanować program, w którym powiadomienia są częścią procesu obsługi, a nie dodatkiem do formularza. W briefie warto określić, które informacje są krytyczne, jak pracownik rozpozna awarię i kiedy powinien skorzystać z innej uzgodnionej drogi kontaktu.
Przygotuj czytelną treść i właściwą odpowiedź
Wiadomość powinna wyjaśniać, czego dotyczy, co się zmieniło i czy klient ma wykonać działanie. Numer sprawy ułatwia powiązanie rozmowy. Nie dołączaj pełnych danych wrażliwych, jeśli wystarczy krótka informacja i dostęp do chronionego panelu. Wersja tekstowa powinna przekazywać sens niezależnie od tego, czy program pocztowy wyświetli układ HTML.
Adres nadawcy powinien odpowiadać rzeczywistej konfiguracji domeny, a odpowiedzi trafiać do obsługiwanej skrzynki. W formularzu kontaktowym adres klienta może służyć jako Reply-To, zamiast podszywania się pod jego domenę w polu From. Pola nagłówków mają określone znaczenie w standardzie wiadomości internetowych.
Zarządzaj błędami według rodzaju
Chwilowy brak połączenia uzasadnia ponowienie, lecz błędny adres albo brak uprawnień wymaga innej reakcji. Zapisuj bezpieczny opis problemu, czas i wynik ostatniej próby. Stosuj odstępy oraz limit podejść, po którym zadanie trafia do sprawdzenia przez człowieka. Nie uruchamiaj natychmiastowej pętli, która przeciąży usługę i utrudni diagnozę.
Przy wdrożeniu z MyTworzymy.pl warto odebrać widok kolejki oraz ręczne ponowienie pojedynczej wiadomości. Dla firmy działającej ogólnopolsko ważne jest, aby obsługa wiedziała, kto nie otrzymał jeszcze informacji, bez konieczności przeszukiwania plików na hostingu. Dobry panel pokazuje różnicę między błędem procesu a błędem samego kanału kontaktu.
Testuj niepewny wynik po zerwaniu połączenia
Trudny przypadek pojawia się, gdy serwer przyjął wiadomość, ale aplikacja nie odebrała odpowiedzi. Automatyczne ponowienie może wtedy dostarczyć kopię. Ustal sposób oznaczania niepewnego wyniku i dalszego sprawdzenia; zwykłe SMTP nie daje uniwersalnej gwarancji dokładnie jednej dostawy w każdej sytuacji awaryjnej. Nie ukrywaj tego ograniczenia za zielonym statusem.
Odbiór obejmij próbami: błędnego odbiorcy, niedostępnego serwera, dwóch pracujących procesów kolejki oraz zmiany sprawy przed wykonaniem zadania. Dopiero taki zestaw pokazuje, czy komunikacja pozostaje zrozumiała po awarii. Celem nie jest obietnica, że poczta nigdy nie zawiedzie, lecz możliwość kontrolowanego wykrycia i obsłużenia problemu.
Dodatkowo sprawdź podgląd przed wysyłką na danych testowych. Nazwisko z polskimi znakami, długi numer sprawy i brak opcjonalnego pola nie powinny zepsuć tematu ani treści. Szablon służy do komunikacji, dlatego jego odbiór wymaga zarówno sprawdzenia technicznego, jak i przeczytania wiadomości tak, jak zrobi to klient bez znajomości wewnętrznego programu.