uruchamianie automatyzacji na nieaktywnych kontaktach

Uruchamianie automatyzacji na nieaktywnych kontaktach obniża skuteczność scenariusza i marnuje zasoby wysyłkowe.

Jak działa automatyzacja uruchamiana na nieaktywnych kontaktach

Uruchamianie automatyzacji na nieaktywnych kontaktach oznacza kierowanie zaplanowanego scenariusza do rekordów, dla których system nie odnotował wymaganej aktywności. Aktywnością może być między innymi otwarcie wiadomości, kliknięcie odnośnika, odpowiedź, zalogowanie do aplikacji albo wykonanie określonej czynności w systemie CRM. Kontakt nieaktywny nie jest jednak pojęciem uniwersalnym. W jednym narzędziu może oznaczać brak zdarzenia przez 30 dni, a w innym brak odpowiedzi na konkretną kampanię.

Automatyzacja zwykle składa się z wyzwalacza, warunków, opóźnień i akcji. Wyzwalacz dodaje kontakt do scenariusza, warunek sprawdza jego właściwości, a akcja wykonuje operację, na przykład wysyła wiadomość albo aktualizuje pole w bazie. Jeżeli filtr aktywności jest niepoprawny, do kolejki mogą trafić kontakty, które nie powinny już otrzymywać kolejnych kroków. Problem może wynikać z błędnego mapowania pól, niewłaściwej strefy czasowej, opóźnionego zapisu zdarzeń lub braku synchronizacji między systemem CRM a narzędziem wysyłkowym.

Skutki przetwarzania nieaktualnych rekordów

Kontakt znajdujący się w bazie nie musi być gotowy do dalszego przetwarzania. Adres może być nieużywany, rekord może dotyczyć zamkniętej sprawy, a użytkownik może nie wykonywać żadnych czynności w aplikacji. Jeżeli scenariusz nie rozróżnia takich przypadków, kolejne zadania są nadal tworzone. W systemie opartym na kolejce oznacza to zajęcie miejsca przez zadania, które mają małą wartość operacyjną, a jednocześnie mogą opóźniać obsługę innych elementów.

Nieaktywne kontakty mogą także pogarszać jakość pomiaru automatyzacji. Wyniki scenariusza będą mieszać reakcje aktywnych odbiorców z brakiem reakcji rekordów, które od dawna nie generują zdarzeń. Trudniej wtedy ustalić, czy problem znajduje się w treści komunikatu, regułach segmentacji, opóźnieniu między krokami czy w samym źródle danych. Warto rozdzielać co najmniej datę ostatniej aktywności, typ ostatniego zdarzenia, status kontaktu oraz datę ostatniego uruchomienia automatyzacji.

Istotne jest również wielokrotne uruchomienie tego samego scenariusza. Jeżeli system nie zapisuje identyfikatora przebiegu albo znacznika czasu ostatniego wejścia, jeden kontakt może zostać dodany kilka razy. Skutkiem są duplikaty zadań, niespójne aktualizacje pól i trudności z odtworzeniem kolejności zdarzeń. Mechanizm idempotencji, czyli możliwość ponowienia operacji bez niepożądanego powielenia skutku, ogranicza takie ryzyko w procesach wywoływanych przez webhooki lub cykliczne zadania.

Warunki i kontrola przed wysłaniem zadania

Bezpieczniejszy scenariusz ponownie sprawdza aktywność bezpośrednio przed wykonaniem akcji. Samo spełnienie warunku w chwili dodania kontaktu do automatyzacji może być niewystarczające, ponieważ między kwalifikacją a wysłaniem zadania może upłynąć czas. Praktyczny warunek powinien uwzględniać aktualny status kontaktu, datę ostatniej aktywności, ewentualną blokadę przetwarzania oraz fakt, czy dla tego samego zdarzenia istnieje już wykonany krok.

Warto rozdzielić etap kwalifikacji od etapu wykonania. Pierwszy wybiera rekordy i zapisuje powód zakwalifikowania, drugi pobiera aktualny stan oraz podejmuje decyzję o kontynuacji. Przydatne są dzienniki zawierające identyfikator kontaktu, identyfikator przebiegu, nazwę kroku, czas rozpoczęcia, czas zakończenia i rezultat. Błąd połączenia z usługą zewnętrzną powinien być odróżniony od świadomego pominięcia kontaktu z powodu braku aktywności. Te dwa przypadki wymagają innych działań: pierwszy może wymagać ponowienia, drugi powinien zakończyć przebieg bez tworzenia kolejnych zadań.

Kontrolę jakości można oprzeć na niewielkiej próbce rekordów i porównaniu stanu w systemie źródłowym ze stanem w narzędziu automatyzacji. Należy sprawdzić, czy daty mają tę samą strefę czasową, czy zdarzenia nie są przesuwane przez opóźnioną synchronizację oraz czy filtr nie traktuje pustej wartości jako aktualnej aktywności. W przypadku zadań cyklicznych trzeba także kontrolować limit równoległych operacji, błędy odpowiedzi API oraz liczbę ponowień dla jednego kontaktu.

Diagnostyka problemu w środowisku użytkownika

Jeżeli automatyzacja działa na laptopie lub komputerze PC, pierwszym krokiem jest ustalenie, czy problem dotyczy aplikacji, połączenia z usługą, czy danych zapisanych po stronie systemu. Można sprawdzić czas systemowy, status synchronizacji, komunikaty w dzienniku aplikacji oraz moment utworzenia zadania. Różnica między czasem lokalnym a czasem serwera może powodować przedwczesne uznanie kontaktu za nieaktywnego albo odwrotnie — opóźniać jego wykluczenie ze scenariusza.

W diagnostyce przydatne jest porównanie jednego poprawnego i jednego błędnego przebiegu. Należy odtworzyć kolejno: źródłowe zdarzenie, zapis w CRM, zmianę statusu, kwalifikację do automatyzacji i wykonanie akcji. Jeżeli zdarzenie istnieje w aplikacji źródłowej, ale nie pojawia się w automatyzacji, przyczyną może być synchronizacja lub filtr. Jeżeli kontakt trafia do kolejki mimo nieaktywności, należy przeanalizować warunek kwalifikacji i ponowną kontrolę przed wysłaniem. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz ich podzespołów, dlatego przy problemach ze stabilnością sprzętu używanego do obsługi takich systemów można rozpocząć od diagnostyki komputera.

Do dokumentacji warto dołączyć identyfikator przebiegu, dokładny czas zdarzeń, komunikaty błędów oraz opis zastosowanych filtrów. Sam wpis „automatyzacja uruchomiła się na nieaktywnym kontakcie” nie wskazuje jeszcze przyczyny. Dopiero zestawienie logów, danych kontaktu i reguł scenariusza pozwala ustalić, czy błąd powstał podczas kwalifikacji, synchronizacji, kolejkowania czy wykonania akcji.