Jak projektować triaż zgłoszeń mieszkańców

Zespół powinien zacząć od nazwania decyzji, którą triaż ma przygotować: czy chodzi o skierowanie sprawy do właściwej kolejki, rozpoznanie brakujących informacji, wykrycie sygnału wymagającego szybkiej weryfikacji, czy jedynie wsparcie raportowania. Te cele prowadzą do innych danych wejściowych i innych kosztów pomyłki. Jedna etykieta nie powinna jednocześnie udawać tematu, priorytetu i właściwości jednostki, bo później nie wiadomo, który element rekomendacji był błędny i jak go poprawić.

Proponowany warsztat powinien objąć operatorów pierwszej linii, właścicieli procesów i osoby odpowiedzialne za dane. Na rzeczywistych, prawidłowo udostępnionych przykładach z uzgodnionego okresu zespół opisuje obecny przebieg sprawy i miejsca niejednoznaczności. Wynikiem nie jest jeszcze model, lecz wersjonowany słownik pojęć: definicja kategorii, kryteria włączenia i wyłączenia, możliwe pomyłki oraz osoba, która może rozstrzygnąć spór. Jeżeli dwaj doświadczeni operatorzy regularnie klasyfikują tę samą sprawę inaczej, automatyzacja nie naprawi nieuzgodnionego procesu.

Temat odpowiada na pytanie, czego dotyczy zgłoszenie. Pilność opisuje, jak szybko sprawa wymaga weryfikacji według uzgodnionych przesłanek. Wpływ dotyczy możliwej skali lub skutku, a właściciel procesu wskazuje zespół odpowiedzialny za dalszy krok. Te wymiary mogą być ze sobą skorelowane, ale nie są tożsame. Zgłoszenie dotyczące popularnego tematu może mieć niski wpływ, a niepozorna treść może zawierać sygnał, który człowiek powinien sprawdzić natychmiast.

Wzorzec wyjścia powinien zachować osobne pola wraz z poziomem pewności i krótką podstawą rekomendacji. Brak danych musi pozostać brakiem, a nie wartością dopowiedzianą przez system. Taksonomia powinna też przewidywać kategorię do ręcznej oceny i kontrolowaną ścieżkę dla nowych tematów. Nie oznacza to tworzenia pojemnego worka „inne” bez właściciela: każda sprawa poza słownikiem powinna trafić do wskazanej kolejki, a powtarzające się przypadki zasilać okresowy przegląd taksonomii.

Jedna globalna wartość progowa jest zwykle zbyt uproszczona. Wynik wystarczający do podpowiedzi tematu może być niewystarczający do nadania pilności lub przekierowania sprawy poza standardową kolejkę. Dla każdego pola i kategorii należy opisać konsekwencję wyniku fałszywie dodatniego oraz fałszywie ujemnego. Dopiero wtedy można zaproponować próg automatycznego zapisu, próg rekomendacji wymagającej zatwierdzenia oraz zakres, który zawsze trafia do ręcznej weryfikacji.

Poziom pewności jest sygnałem technicznym zależnym od sposobu kalibracji i danych, nie gwarancją poprawności operacyjnej. Operator powinien widzieć oryginalną treść, wersję taksonomii i pola, które wpłynęły na rekomendację w zakresie możliwym do rzetelnego przedstawienia. Jeżeli zgłoszenie jest nieczytelne, sprzeczne, wielowątkowe albo dotyczy obszaru o wysokim koszcie pomyłki, właściwym wynikiem może być jawna eskalacja, a nie wymuszone przypisanie najbardziej prawdopodobnej etykiety.

Interfejs weryfikacji powinien pozwalać zaakceptować, poprawić lub odrzucić każde istotne pole, a także wskazać przyczynę korekty w prostym, uzgodnionym słowniku. Operator nie może być zmuszany do zatwierdzania rekomendacji tylko po to, aby przejść dalej. Oryginalny wynik, korekta, czas i uprawniona rola powinny pozostać w historii potrzebnej do kontroli procesu. Zakres dziennika i okres przechowywania wymagają odrębnego uzgodnienia zgodnego z celem i zasadą minimalizacji.

Korekty nie powinny automatycznie zasilać kolejnej wersji modelu bez oceny jakości i podstawy przetwarzania. Mogą wynikać ze zmiany procedury, niejednoznacznej treści albo błędu operatora, dlatego wymagają przeglądu przed użyciem. Właściciel procesu odpowiada za definicje i decyzję o użyciu rekomendacji; zespół techniczny odpowiada za działanie uzgodnionego mechanizmu i obserwowalność. Taki podział nie przenosi odpowiedzialności za usługę publiczną na algorytm ani dostawcę narzędzia.

Bezpieczny początek to jedna kolejka, uzgodniony okres i tryb cienia: system tworzy rekomendacje, ale nie zmienia źródłowego statusu ani właściciela sprawy. Zespół porównuje je z oceną uprawnionych operatorów i analizuje wyniki osobno dla kategorii. Średnia zgodność może ukryć rzadką, lecz kosztowną klasę błędów. Warto mierzyć także odsetek eskalacji, brakujące dane, czas potrzebny na weryfikację oraz stabilność wyniku po zmianie języka lub formy zgłoszenia.

Kryteria kontynuacji, zatrzymania i cofnięcia powinny powstać przed rozpoczęciem testu. Pilotaż może wykazać, że automatyzacja nie jest uzasadniona, że potrzebna jest zmiana taksonomii albo że system nadaje się wyłącznie do podpowiedzi. Taki wynik jest wartościowy, jeśli został udokumentowany. Ten przewodnik nie potwierdza aktywnego wdrożenia Rozety w mieście; opisuje proponowany sposób oceny, który musi zostać dopasowany do konkretnego procesu, podstaw prawnych i architektury organizacji.