Łączenie kanałów obsługi mieszkańców bez utraty kontekstu

Telefon, formularz, e-mail i czat dostarczają zdarzenia, które mogą dotyczyć jednej sprawy albo kilku niezależnych problemów. Centralny model powinien rozróżniać identyfikator wiadomości źródłowej, identyfikator sprawy i ewentualne powiązanie między sprawami. Treść oryginalna, kanał, czas oraz status przekazania pozostają dostępne, natomiast wspólny kontekst zawiera tylko dane potrzebne do dalszej obsługi. Nie należy budować jednego nieograniczonego profilu mieszkańca z każdej interakcji.

Schemat sprawy powinien być uzgodniony z systemem, który pozostaje źródłem prawdy. Rozeta może proponować temat, wykrywać możliwe powiązanie i przygotować podsumowanie, ale nie powinna samodzielnie scalać rekordów lub przenosić statusu bez reguł i śladu decyzji. Jeśli wiadomość obejmuje dwa problemy, model powinien umożliwić podział przy zachowaniu relacji do źródła. Dzięki temu operator rozumie, skąd pochodzi kontekst, a korekta nie usuwa historii kanału.

Dwa zgłoszenia o podobnej treści mogą dotyczyć innego miejsca, czasu lub zdarzenia. Z kolei ta sama sprawa może zostać opisana całkowicie innymi słowami w rozmowie telefonicznej i późniejszym e-mailu. Reguła powiązania powinna uwzględniać zakres geograficzny, okno czasowe, kategorię i identyfikatory dostępne zgodnie z celem. Wynik jest kandydatem do sprawdzenia, a nie zgodą na usunięcie jednego rekordu.

Operator powinien móc potwierdzić relację, odrzucić ją albo oznaczyć zgłoszenia jako związane bez scalania. Połączenie wymaga historii: które rekordy, według jakiej reguły i przez jaką rolę zostały powiązane. Rozłączenie również musi być możliwe. Zagregowany widok nie może ukrywać liczby źródłowych raportów, ponieważ ta liczba może mieć znaczenie operacyjne; jednocześnie nie powinna być automatycznie przedstawiana jako liczba różnych osób ani potwierdzonych zdarzeń.

Kanały zapewniają różne poziomy pewności co do osoby po drugiej stronie. Numer telefonu lub adres e-mail nie powinien automatycznie oznaczać potwierdzonej tożsamości, a zalogowanie do aplikacji nie daje podstawy do użycia danych w każdym innym celu. Model sprawy powinien odróżniać dane kontaktowe, wynik uwierzytelnienia, preferowany kanał odpowiedzi oraz wymagane zgody lub inne podstawy działania. Dostęp do tych pól należy ograniczyć do ról, które faktycznie ich potrzebują.

Przeniesienie rozmowy między kanałami wymaga jasnego komunikatu o tym, co zostanie zachowane i dlaczego. Jeśli mieszkaniec zaczyna od kanału anonimowego, proces nie powinien wymuszać identyfikacji, o ile nie jest ona potrzebna do konkretnego następnego kroku. Zakres danych, retencja i prawa osoby wymagają oceny na gruncie RODO oraz właściwych przepisów sektorowych. Rozeta nie dostarcza automatycznej kwalifikacji prawnej; strona opisuje pytania, które organizacja powinna rozstrzygnąć przed integracją.

Kanał głosowy może ułatwić kontakt części osób, ale dla innych będzie barierą; podobnie formularz tekstowy, aplikacja lub czat. Projekt powinien zapewniać równoważny sposób przejścia przez kluczowe kroki i przekazanie do człowieka bez utraty kontekstu. Kryteria WCAG 2.2 są podstawą oceny interfejsów cyfrowych, lecz nie zastępują badań z użytkownikami ani wymagań prawnych właściwych dla konkretnego podmiotu.

Ciągłość oznacza, że operator widzi uzgodnione podsumowanie i źródła, a mieszkaniec nie musi powtarzać całej historii tylko z powodu zmiany kanału. Jednocześnie podsumowanie generowane automatycznie powinno być oznaczone i możliwe do sprawdzenia z oryginałem. Awaria Rozety lub rekomendacji nie może blokować podstawowego sposobu obsługi: organizacja potrzebuje procedury ręcznej, jasnego statusu integracji i możliwości wznowienia bez cichego tworzenia podwójnych spraw.

Pierwszy etap może odbierać kopię zdarzeń z jednego kanału i tworzyć propozycje powiązań bez zapisu do systemu źródłowego. Zespół weryfikuje, czy kontekst jest kompletny, ile kandydatów okazało się błędnymi duplikatami, jak często potrzebny był powrót do oryginału oraz czy osoby obsługujące rozumieją pochodzenie danych. Dopiero udokumentowany wynik pozwala rozważyć zapis relacji lub podsumowania przez kontrolowane API.

Czas obsługi jest tylko jedną z miar. Należy obserwować utracone lub zwielokrotnione sprawy, błędne powiązania, liczbę korekt, dostępność ścieżek, skuteczność przekazania do człowieka i incydenty danych. Oficjalny opis Warszawy 19115 pokazuje kontekst wielokanałowej informacji i zgłoszeń, lecz nie jest dowodem integracji Rozety ani wzorcem do skopiowania bez uzgodnień. Każdy pilotaż wymaga własnego zakresu, systemu źródłowego, właścicieli i kryteriów stop/go.