Jak ponawiać nieudane sprawy bez duplikatów?

Nie każde niepowodzenie można naprawić przez ponowne kliknięcie „wykonaj”. Jeśli pierwsza próba zmieniła stan w systemie, lecz potwierdzenie nie wróciło, druga może utworzyć duplikat zamówienia, wysłać dwie wiadomości lub podwójnie obciążyć klienta. Proces potrzebuje sposobu sprawdzenia skutku przed ponowieniem.

Szerszy kontekst pokazuje filar „Automatyzacja i agenci AI”.

Rozróżnij rodzaje błędów

Jedna sprawa nie przeszła, bo brakowało danych. Inna czeka na niedostępny system. Jeszcze inna mogła się wykonać, ale utraciła potwierdzenie. Te sytuacje wymagają różnych działań. Brak danych kieruj do właściciela sprawy; przejściową niedostępność można ponowić po sprawdzeniu statusu; niepewny wynik wymaga odczytu z systemu źródłowego.

Przykład dydaktyczny: agent zleca wystawienie dokumentu, po czym połączenie się urywa. Nie powinien od razu zlecać go ponownie. Najpierw wyszukuje dokument po identyfikatorze sprawy. Jeżeli istnieje, kończy proces na podstawie faktycznego wyniku. Jeżeli nie, może spróbować jeszcze raz zgodnie z regułą. Przy spornej sytuacji przekazuje ją człowiekowi.

Pokaż sprawę człowiekowi

Każde zadanie powinno mieć identyfikator, status, liczbę prób, ostatni błąd i następny krok. Pracownik musi zobaczyć, czy klient został poinformowany i czy firma już podjęła zobowiązanie. Kto przejmie pracę po awarii automatyzacji opisuje organizacyjną stronę tej samej sytuacji. Techniczny mechanizm ponowienia nie wystarczy, jeśli nikt nie odpowiada za sprawę pozostawioną w stanie niepewnym.

Ustal limit ponowień. Bez niego jedna uszkodzona sprawa może wykonywać się w kółko i ukrywać problem. Po przekroczeniu limitu system kieruje zadanie do kolejki wyjątków z jasnym opisem. Nie zamyka go jako „obsłużone”, dopóki nie ma potwierdzenia wyniku.

Mierz skuteczność końcową

Raportuj liczbę spraw zakończonych poprawnie, liczbę duplikatów, czas do wyjaśnienia stanu niepewnego i najczęstsze przyczyny ponowień. Jeśli błąd stale wraca, napraw źródło danych lub połączenie. Samo zwiększenie limitu prób będzie tylko maskować awarię.

Pierwszy test zrób na scenariuszu przerwanego połączenia po wykonaniu działania. To zwykle ujawnia, czy proces naprawdę potrafi bezpiecznie wrócić do pracy.

Próba awaryjna przed produkcją

Przerwij testową sprawę w trzech miejscach: przed wykonaniem działania, tuż po nim i podczas potwierdzania wyniku. Dla każdej sprawdź, czy operator potrafi rozpoznać stan oraz bezpiecznie ją dokończyć. Szczególnie groźny jest drugi wariant: system źródłowy zmienił dane, lecz agent nie otrzymał odpowiedzi. Jeżeli identyfikator sprawy nie pozwala sprawdzić skutku, ponawianie powinno zostać wstrzymane do czasu poprawy integracji.

Zapisz również, jak komunikujesz klientowi opóźnienie spowodowane awarią. Nie wysyłaj potwierdzenia wykonania tylko dlatego, że zadanie zostało ponownie umieszczone w kolejce. Raport operacyjny powinien odróżniać „czeka”, „wynik niepewny”, „wymaga człowieka” i „zakończone w źródle”. Te statusy brzmią technicznie, ale rozstrzygają bardzo praktyczne pytanie: czy klient może polegać na obietnicy firmy.