Dwustronna korespondencja mailowa zestawia wiadomości przychodzące i wychodzące w jednym wątku przypiętym do konkretnego dokumentu. System pobiera zawartość skrzynki odbiorczej, a wysyłka odbywa się z poziomu zgłoszenia - z szablonem uzupełnionym danymi dokumentu i możliwością dołączenia plików.
Czym jest dwustronna korespondencja
Obsługa zgłoszenia rzadko kończy się na jednej wiadomości. Klient pisze z pytaniem, dział serwisu odpowiada, klient odsyła zdjęcie uszkodzenia, ktoś dopytuje o numer dokumentu zakupu. W typowej organizacji ta wymiana rozprasza się między skrzynkami kilku pracowników, a osoba przejmująca sprawę po urlopie koleżanki zaczyna od zera.
Korespondencja mailowa prowadzona w systemie rozwiązuje ten problem inaczej niż zwykła wysyłka powiadomień. Określenie dwustronna jest tu istotne: system nie tylko wysyła wiadomości, ale też pobiera zawartość skrzynki odbiorczej, dzięki czemu w wątku widać obie strony rozmowy. Historia kontaktu przestaje być własnością pojedynczego pracownika i staje się częścią dokumentu.
W praktyce daje to kilka wymiernych efektów:
- Ciągłość obsługi - każda osoba otwierająca zgłoszenie widzi pełną historię wymiany zdań.
- Brak zagubionych ustaleń - odpowiedź klienta nie ginie w prywatnej skrzynce pracownika.
- Spójna forma komunikatów - szablony pilnują, by każdy klient dostawał wiadomość o tej samej strukturze.
- Mniej błędów w danych - numery i statusy podstawiane są automatycznie, a nie przepisywane ręcznie.
- Dowód kontaktu - przy sporze łatwo wykazać, kiedy i o czym poinformowano klienta.
Wątek zamiast rozproszonych maili
Transakcja odpowiedzialna za korespondencję wyświetla wiadomości w formie wątku, zestawiając przychodzące i wychodzące w porządku chronologicznym. Do prezentacji treści wykorzystywany jest edytor tekstu sformatowanego, dzięki czemu wiadomości zawierające formatowanie HTML - tabele, wyróżnienia, listy - wyświetlają się tak, jak zostały napisane, a nie jako surowy kod znaczników.
W praktyce wątek zapełnia się w kilku powtarzalnych momentach obsługi zgłoszenia. Warto zaplanować je z góry, bo to one decydują o tym, ile szablonów trzeba przygotować:
- Rejestracja zgłoszenia - potwierdzenie przyjęcia sprawy z nadanym numerem i statusem początkowym.
- Prośba o uzupełnienie - wiadomość z pytaniem o dowód zakupu, zdjęcia lub numer seryjny.
- Odpowiedź klienta - wiadomość przychodząca, często z załącznikiem, dopisywana do tego samego wątku.
- Zmiana statusu - informacja o przekazaniu sprawy do serwisu, decyzji albo zakończeniu naprawy.
- Zamknięcie sprawy - podsumowanie z rozstrzygnięciem i ewentualnym numerem przesyłki zwrotnej.
Każdy z tych momentów może mieć własny szablon, a wspólny numer referencyjny dokumentu spina je w jedną, czytelną historię. Osoba przejmująca zgłoszenie widzi nie tylko obecny status, ale też drogę, jaką sprawa przebyła.
Jeśli do wiadomości dołączono plik, przy wątku pojawia się przycisk załącznika prowadzący do listy dołączonych dokumentów. Sam mechanizm obsługi plików opisuje osobno strona transakcji j_zalaczniki.aspx, a szerszy kontekst modułu reklamacyjnego, w którym korespondencja jest wykorzystywana najczęściej - materiał o transakcjach RMA.
Wysyłka z poziomu dokumentu
Wysyłkę uruchamia się poleceniem dostępnym w oknie zgłoszenia, obok informacji o statusie i osobie zgłaszającej. Kluczowa różnica wobec zwykłego klienta pocztowego polega na tym, że formularz otwiera się już wypełniony danymi dokumentu.
Temat i treść gotowe przed otwarciem
Temat komponowany jest automatycznie z nazwy systemu i numeru dokumentu, a treść zawiera komplet danych zgłoszenia. Użytkownik dopisuje jedynie to, co wykracza poza szablon.
Formularz udostępnia standardowy zestaw pól znany z programów pocztowych, uzupełniony o elementy specyficzne dla pracy w systemie:
- Od - adres nadawcy wynikający z konta pocztowego przypisanego użytkownikowi.
- Adresat - odbiorca podstawiany z danych kontrahenta lub zgłaszającego.
- DW i UDW - kopia jawna i ukryta, odpowiedniki CC oraz BCC.
- Temat - komponowany automatycznie, na przykład z nazwy systemu i numeru dokumentu reklamacji.
- Treść - edytor z formatowaniem: pogrubienie, kursywa, wyrównanie, listy i kolory.
- Dodaj załącznik - dołączenie pliku do wysyłanej wiadomości.
W wiadomości dotyczącej zgłoszenia reklamacyjnego szablon podstawia komplet danych identyfikujących sprawę: numer RMA, numer reklamacji, numer referencyjny, aktualny status oraz dane kontaktowe zgłaszającego. Użytkownik zachowuje pełną kontrolę nad ostateczną treścią - może dopisać wyjaśnienie, skrócić komunikat albo dodać odbiorcę w kopii.
Szablony w skorowidzu EML
Treść wiadomości nie jest zapisana w kodzie transakcji, lecz w konfiguracji. Szablony przechowuje skorowidz EML, w którym obok samej treści definiuje się parametry uruchomienia. To rozwiązanie typowe dla całej platformy: zachowanie zmienia osoba odpowiedzialna za konfigurację, korzystając ze skorowidzy, a nie programista modyfikujący pliki źródłowe.
| Element konfiguracji | Gdzie się znajduje | Za co odpowiada |
|---|---|---|
| Szablon wiadomości | Skorowidz EML | Treść i temat komunikatu wraz z miejscami na dane dokumentu |
| Połączenie z serwerem | Administracja → Parametry | Adres serwera pocztowego, nazwa użytkownika, hasło i adres nadawcy |
| Konto pocztowe | Administracja → Użytkownicy | Adres e-mail przypisany konkretnej osobie pracującej w programie |
| Obiekty załączników | Skorowidz JZAL | Kod, opis, ścieżka zapisu plików i sposób nazywania załączników |
Rozdzielenie szablonu od kodu ma jeszcze jedną zaletę praktyczną. Zmiana formuły grzecznościowej, dopisanie klauzuli informacyjnej czy korekta literówki w komunikacie wysyłanym do setek klientów to zmiana jednego rekordu w skorowidzu - bez wdrożenia nowej wersji aplikacji.
Załączniki i pliki
Dokumentacja zgłoszenia rzadko obywa się bez plików: zdjęcia uszkodzonego towaru, skan dowodu zakupu, protokół serwisowy. Transakcja obsługująca załączniki pozwala dodawać je metodą przeciągnij i upuść, a jej konfiguracja opiera się na skorowidzu JZAL.
W skorowidzu określa się między innymi kod przekazywany jako parametr transakcji, opis wyświetlany wewnątrz obszaru upuszczania plików oraz fizyczną ścieżkę zapisu. Ścieżka obsługuje parametr @REFNO, zamieniany na numer referencyjny dokumentu, dla którego uruchomiono transakcję. Pozostawienie pola pustego oznacza użycie ścieżki domyślnej App_Zal/@REFNO, czyli osobnego katalogu dla każdego zgłoszenia.
Każdy rekord skorowidza konfiguruje osobny obszar upuszczania, więc jedna transakcja może udostępnić kilka miejsc na pliki różnego typu - na przykład osobno na dokumentację fotograficzną i osobno na dokumenty księgowe.
Konfiguracja przed pierwszą wysyłką
Zanim pierwsza wiadomość opuści system, trzeba przejść przez trzy kroki konfiguracyjne. Wszystkie wykonuje się w module administratora, bez ingerencji w kod.
- Połączenie z serwerem pocztowym - w sekcji Parametry podaje się adres serwera, nazwę użytkownika, hasło oraz adres, z którego mają wychodzić wiadomości.
- Konta pocztowe użytkowników - w sekcji Użytkownicy przypisuje się adres e-mail poszczególnym osobom; musi on być zgodny z konfiguracją zapisaną w Parametrach.
- Szablony komunikatów - w skorowidzu EML definiuje się treści wysyłane w poszczególnych sytuacjach wraz z parametrami uruchomienia.
Wysyłkę wiadomości można też uruchamiać poza kontekstem pojedynczego dokumentu - zagadnienie to opisuje szerzej strona o wysyłaniu maili, a techniczne szczegóły transakcji obsługującej wiadomości znajdują się w materiale o transakcji x_mail.aspx oraz w opisie skryptu j_mail.js.
Kiedy e-mail, a kiedy SMS
Poczta elektroniczna nie jest jedynym kanałem powiadomień dostępnym na platformie. Wybór między e-mailem a wiadomością tekstową warto podporządkować charakterowi komunikatu.
| Kryterium | SMS | |
|---|---|---|
| Objętość treści | Dowolna, z formatowaniem i tabelami | Krótki komunikat, kilkadziesiąt znaków |
| Załączniki | Tak - zdjęcia, skany, dokumenty | Nie |
| Typowe zastosowanie | Potwierdzenia, korespondencja ze zgłoszeniem, dokumentacja | Pilne powiadomienia, na przykład zwolnienie rampy |
| Historia w systemie | Pełny wątek dwustronny przy dokumencie | Rejestr wysłanych komunikatów |
W wielu wdrożeniach oba kanały działają równolegle: e-mail przenosi treść i dokumentację, a powiadomienie SMS sygnalizuje, że wydarzyło się coś wymagającego natychmiastowej reakcji.
Podsumowanie
Dwustronna korespondencja mailowa zamienia rozproszoną wymianę wiadomości w uporządkowaną historię przypiętą do dokumentu. System pobiera skrzynkę odbiorczą, zestawia wiadomości przychodzące i wychodzące w jednym wątku, a wysyłkę uruchamia z poziomu zgłoszenia - z tematem i treścią uzupełnionymi danymi sprawy.
Całość opiera się na konfiguracji, a nie na kodzie: szablony trafiają do skorowidza EML, obsługa plików do skorowidza JZAL, a parametry serwera pocztowego do modułu administratora. Ten sam mechanizm konfiguracji przez skorowidze wykorzystują pozostałe elementy platformy opisane w materiale o architekturze transakcji.