multi-touch automation

Multi-touch automation to scenariusz komunikacji obejmujący serię kontaktów z odbiorcą w kilku kanałach.

Multi-touch automation jako orkiestracja kontaktów

Multi-touch automation oznacza automatyzację scenariusza, w którym system wykonuje kilka zaplanowanych kontaktów z tym samym odbiorcą. Poszczególne punkty kontaktu mogą wykorzystywać różne kanały, na przykład wiadomość e-mail, powiadomienie w aplikacji, formularz na stronie, komunikat SMS albo kontakt zainicjowany przez konsultanta. Istotą rozwiązania nie jest samo wysłanie wielu wiadomości, lecz powiązanie ich w jeden przepływ sterowany zdarzeniami, regułami i stanem odbiorcy zapisanym w systemie.

Automatyzacja tego typu zwykle działa na podstawie rekordu kontaktu, identyfikatora kampanii oraz zestawu atrybutów opisujących odbiorcę i jego aktywność. System może rozpocząć scenariusz po utworzeniu konta, przesłaniu formularza, pobraniu pliku, rozpoczęciu okresu próbnego albo wykonaniu określonej czynności w aplikacji. Kolejne kroki są uruchamiane po upływie czasu, po otrzymaniu zdarzenia z innego systemu lub po spełnieniu warunku logicznego. Dzięki temu następny komunikat może zależeć od tego, czy poprzedni został dostarczony, otwarty, kliknięty albo zignorowany.

Elementy techniczne scenariusza wielokanałowego

Podstawą multi-touch automation jest silnik przepływów, który przechowuje definicję scenariusza i aktualny etap dla każdego odbiorcy. Definicja może zawierać węzły akcji, opóźnienia, warunki, rozgałęzienia i zakończenia. Akcją jest na przykład utworzenie zadania dla pracownika, wysłanie komunikatu przez zewnętrzne API lub zapisanie wartości w systemie CRM. Warunek może sprawdzać typ urządzenia, status zamówienia, ostatnie zdarzenie użytkownika albo wynik poprzedniej próby kontaktu. Opóźnienia powinny być obliczane jednoznacznie, najlepiej z uwzględnieniem strefy czasowej i kalendarza przyjętego przez aplikację.

Wymiana danych między kanałami odbywa się zazwyczaj przez API, webhooki, kolejki komunikatów albo cykliczne zadania synchronizujące. Integracja powinna mieć jasno określony format danych: identyfikator odbiorcy, nazwę zdarzenia, czas wystąpienia, źródło oraz właściwości zdarzenia. Przy ponownym dostarczeniu tego samego komunikatu system powinien rozpoznać duplikat i nie wykonywać akcji drugi raz. Służą temu identyfikatory idempotencji, znaczniki wersji lub rejestr przetworzonych zdarzeń. Bez takiej kontroli jeden webhook albo chwilowy błąd połączenia może uruchomić wielokrotnie tę samą wiadomość.

W praktycznej implementacji ważne jest rozdzielenie planowania od wysyłki. Silnik scenariusza może zapisać zadanie w kolejce, a osobny worker pobiera je, wybiera właściwy kanał i przekazuje żądanie do dostawcy. Odpowiedź dostawcy powinna być zapisana razem z kodem wyniku, czasem próby i informacją o ewentualnym ponowieniu. Błędy tymczasowe, takie jak przekroczenie limitu API lub niedostępność usługi, można obsłużyć ponowną próbą z narastającym odstępem. Błędy trwałe, na przykład nieprawidłowy adres odbiorcy, powinny zakończyć daną ścieżkę albo skierować ją do obsługi ręcznej.

Reguły, pomiar zdarzeń i kontrola kolejności

Wielokanałowy scenariusz wymaga spójnego modelu zdarzeń. Wysłanie komunikatu, jego dostarczenie, kliknięcie odnośnika, odpowiedź użytkownika i rezygnacja z dalszego kontaktu nie są tym samym zdarzeniem. System powinien przechowywać je osobno, ponieważ każde może uruchamiać inną gałąź przepływu. Jeżeli odbiorca wykona oczekiwaną czynność, dalsze przypomnienia mogą zostać pominięte. Jeżeli nie ma reakcji, scenariusz może przejść do kolejnego kanału, o ile reguły dopuszczają takie działanie.

Istotna jest kolejność zdarzeń. Opóźniony webhook może dotrzeć po zdarzeniu nowszym, dlatego sama kolejność odbioru komunikatów nie zawsze odpowiada kolejności ich wystąpienia. Aplikacja może korzystać ze znacznika czasu źródłowego, numeru sekwencji lub wersji rekordu. Przy równoległym przetwarzaniu zadań potrzebne są również blokady, transakcje albo warunki aktualizacji, aby dwaj workerzy nie wysłali dwóch sprzecznych komunikatów dla tego samego etapu. W przypadku awarii procesu stan scenariusza powinien umożliwiać bezpieczne wznowienie pracy bez utraty kroku i bez niekontrolowanego powtórzenia akcji.

Ocena działania nie powinna ograniczać się do liczby wysłanych wiadomości. W systemie warto rejestrować czas wejścia do scenariusza, przejścia między etapami, status każdej akcji, przyczynę zakończenia oraz identyfikator wersji scenariusza. Takie dane pozwalają ustalić, czy problem dotyczy reguły, integracji, kolejki, dostawcy kanału czy błędnego mapowania identyfikatora odbiorcy. Przydatne są również dzienniki techniczne, metryki opóźnienia i liczba ponowień. Zmiana scenariusza powinna mieć własną wersję, aby później można było odtworzyć, według jakich reguł przetworzono konkretny kontakt.

Diagnostyka działania multi-touch automation na komputerze

Podczas diagnozowania problemu należy najpierw ustalić, na którym etapie przepływ przestał działać. Pomocne jest prześledzenie jednego identyfikatora od zdarzenia początkowego, przez zapis w bazie lub kolejce, aż do odpowiedzi dostawcy kanału. Brak rekordu wejściowego wskazuje na problem z formularzem, aplikacją źródłową albo webhookiem. Rekord bez utworzonego zadania może oznaczać błąd warunku lub harmonogramu. Zadanie zakończone błędem po stronie API wymaga sprawdzenia adresu endpointu, danych uwierzytelniających, limitów oraz formatu żądania. Sama obecność komunikatu w dzienniku nie potwierdza dostarczenia go do odbiorcy.

Na laptopie lub komputerze PC można sprawdzić logi aplikacji, historię żądań sieciowych i status usług odpowiedzialnych za kolejkę. W przeglądarce narzędzia deweloperskie pokazują między innymi kod HTTP, czas odpowiedzi, przekazane pola oraz odpowiedź serwera, ale nie zastępują logów po stronie backendu. Jeżeli system używa powiadomień w aplikacji, trzeba dodatkowo zweryfikować rejestrację urządzenia, token sesji i datę ostatniej synchronizacji. W przypadku wiadomości e-mail lub SMS należy rozróżnić przyjęcie żądania przez dostawcę od faktycznego dostarczenia. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z lokalnym środowiskiem pracy można rozpocząć od sprawdzenia systemu, połączenia sieciowego oraz poprawności działania aplikacji.

Bezpieczna diagnostyka powinna zachować ciągłość danych potrzebnych do odtworzenia zdarzenia, ale nie powinna polegać na ręcznym wielokrotnym uruchamianiu produkcyjnego scenariusza. Testy można wykonywać na osobnym rekordzie, w środowisku testowym albo z wyłączoną wysyłką zewnętrzną. Po naprawie warto ponowić tylko zadania o jednoznacznie ustalonym statusie i sprawdzić, czy mechanizm idempotencji zapobiega duplikatom. Końcowym rezultatem powinno być wskazanie konkretnego etapu, przyczyny błędu, zakresu dotkniętych kontaktów oraz sposobu potwierdzenia, że kolejne przejścia scenariusza zachodzą w prawidłowej kolejności.