AI do wykrywania podobnych zgłoszeń serwisowych: jak nie ukryć nowej sprawy

Dwa zgłoszenia opisują ten sam nietypowy dźwięk urządzenia. Mogą pochodzić od dwóch osób, które zauważyły jedno zdarzenie. Mogą też dotyczyć dwóch różnych maszyn o podobnych objawach. Narzędzie wskazujące podobne zgłoszenia może pomóc pracownikowi znaleźć kontekst, ale nie powinno automatycznie ukrywać nowej sprawy tylko dlatego, że jej opis przypomina wcześniejszy.

AI może przygotować propozycje podobnych zgłoszeń do przeglądu. Zespół musi jednak ustalić, jakie informacje rozstrzygają o związku między sprawami, kto podejmuje decyzję oraz co dzieje się z każdą historią po połączeniu. Ważne jest również zachowanie drogi dla sprawy, której podobieństwa nie udało się potwierdzić.

Jeśli planujesz takie wsparcie serwisu, wyślij brief z opisem źródeł zgłoszeń, sposobu identyfikacji urządzeń i decyzji podejmowanych przez pracowników. Wystarczy fikcyjny przykład dwóch podobnych spraw. Nie przesyłaj poufnej dokumentacji, danych klientów ani haseł podczas pierwszego kontaktu.

Zdefiniuj, czego szuka pracownik

Wyobraźmy sobie firmę obsługującą urządzenia w kilku obiektach. Pracownik otrzymuje nowe zgłoszenie i chce sprawdzić, czy inny zespół już prowadzi sprawę dotyczącą tego samego egzemplarza. To przykład projektowy, nie opis konkretnej firmy. W pierwszej kolejności trzeba ustalić, jak rozpoznać urządzenie oraz co oznacza związek między zgłoszeniami.

Możliwe są różne relacje. Dwie wiadomości mogą dotyczyć jednego zdarzenia, podobnych objawów na różnych urządzeniach albo kolejnego zdarzenia po wcześniejszej naprawie. Wyszukiwanie podobnych opisów może pomóc znaleźć te przypadki, ale sama lista nie rozstrzyga, która relacja zachodzi. Osoba prowadząca sprawę potrzebuje kontekstu i możliwości porównania danych.

Zacznijcie od rozmowy z pracownikami, którzy przyjmują i realizują zgłoszenia. Jak rozpoznają urządzenie? Kiedy kontaktują się z innym zespołem? Jak zapisują informację o powiązaniu? Odpowiedzi pomogą ustalić, czy potrzebna jest sugestia podobnych spraw, widok historii urządzenia czy zmiana sposobu przyjmowania zgłoszenia.

O drodze zlecenia od zgłoszenia do zamknięcia piszemy w artykule o automatyzacji zleceń serwisowych. Wykrywanie podobieństwa ma wspierać ten obieg. Nie powinno sprawiać, że osoba zgłaszająca przestaje wiedzieć, co dzieje się z jej sprawą.

Porównaj kontekst, nie tylko słowa

Krótki opis „urządzenie nie działa” może pojawić się w wielu zgłoszeniach. Przy porównaniu przydatne mogą być identyfikator egzemplarza, lokalizacja, czas, osoba prowadząca oraz stan wcześniejszej sprawy. Zakres zależy od procesu i uprawnień. Dwa podobne zdania nie dowodzą, że dotyczą jednego zdarzenia.

Odwrotna sytuacja jest również możliwa. Dwie osoby mogą opisać tę samą sytuację różnymi słowami. System może pomóc pracownikowi odnaleźć potencjalne powiązanie, lecz wynik powinien prowadzić do oryginalnych zgłoszeń. Osoba oceniająca musi zobaczyć, które informacje są zgodne, a których brakuje. Jeśli nie ma pewności, powinna móc pozostawić sprawy oddzielnie i skierować pytanie do właściwego zespołu.

Identyfikacja urządzenia wymaga ustalenia źródła danych. Nazwa potoczna może być taka sama w różnych lokalizacjach, a numer wpisany ręcznie może zawierać błąd. W artykule o historii urządzenia w aplikacji terenowej opisujemy znaczenie właściwego egzemplarza i jego dokumentacji.

Zespół powinien również uzgodnić, jaki przedział czasu ma znaczenie dla przeglądu. Podobny objaw sprzed dłuższego okresu może być przydatną informacją, lecz nie musi oznaczać tej samej sprawy. Nie warto ustalać uniwersalnej granicy bez rozmowy z osobami znającymi proces i rodzaj urządzeń.

Pokaż propozycję i zachowaj źródła

Wynik wyszukiwania powinien wskazywać, dlaczego dana sprawa została pokazana oraz jakie informacje można porównać. Użytkownik może potrzebować numeru urządzenia, czasu zgłoszenia, aktualnego stanu i krótkiego fragmentu opisu. Zakres powinien odpowiadać jego uprawnieniom. Nie należy pokazywać pełnej historii innego klienta tylko dlatego, że opis wydaje się podobny.

Przy każdej propozycji przydaje się możliwość otwarcia oryginału, odrzucenia dopasowania lub zgłoszenia braku danych. Jeśli pracownik nie ma dostępu do drugiej sprawy, system powinien zachować ograniczenia także w wynikach wyszukiwania. O tej zasadzie piszemy w artykule o uprawnieniach do dokumentów; podobna potrzeba dotyczy również rekordów zgłoszeń.

Jeśli narzędzie pokazuje ocenę podobieństwa, zespół powinien sprawdzić, jak jest obliczana i do czego można jej użyć. Wysoka wartość dla opisu nie potwierdza identyczności urządzenia ani przyczyny zdarzenia. Użytkownik potrzebuje danych pozwalających podjąć decyzję, a nie tylko liczby sugerującej pewność.

Ważne jest też oznaczenie wieku danych. Wcześniejsza sprawa mogła zostać już zamknięta, a jej dokumentacja mogła dotyczyć innej wersji urządzenia. Wynik powinien pokazywać stan i czas w sposób pozwalający ocenić przydatność. O ustalaniu odpowiedzialności za informacje piszemy w artykule o źródłach danych w integracji.

Nie zamykaj sprawy bez uzgodnionej decyzji

Powiązanie zgłoszeń i zamknięcie jednego z nich są różnymi operacjami. Zespół może chcieć pokazać, że dwie osoby opisały podobne zdarzenie, a jednocześnie zachować osobne informacje o kontakcie i przebiegu obsługi. Jeśli proces przewiduje połączenie, trzeba ustalić, która sprawa pozostaje główna oraz co dzieje się z załącznikami i terminami.

Pracownik podejmujący decyzję powinien widzieć jej skutki. Czy zgłaszający nadal otrzyma odpowiedź? Czy zadania przypisane do obu spraw pozostaną widoczne? Czy można później wyjaśnić, dlaczego uznano je za powiązane? Odpowiedzi należy uzgodnić przed wdrożeniem. Prosty przycisk „duplikat” nie opisuje jeszcze całego obiegu.

Jeśli w trakcie pracy okaże się, że zgłoszenia dotyczą różnych urządzeń, zespół powinien mieć drogę do poprawienia relacji. Ustalcie, kto może to zrobić oraz jak informuje osoby prowadzące otwarte zadania. Historia decyzji pomaga odróżnić korektę od nowego zgłoszenia. Nie zawsze da się automatycznie cofnąć wszystkie działania wykonane po wcześniejszym połączeniu.

O potrzebie czytelnej propozycji i zatwierdzenia piszemy w artykule o zatwierdzaniu działań AI. Przy podobnych zgłoszeniach decyzja może wymagać kontaktu z technikiem lub osobą, która utworzyła sprawę. System powinien zostawić na ten krok miejsce.

Przetestuj oba rodzaje pomyłek

Przygotujcie fikcyjne zgłoszenia dotyczące jednej maszyny opisanej różnymi słowami, dwóch maszyn o podobnych objawach oraz sprawy z brakującym identyfikatorem. Dodajcie przykład ponownego zdarzenia po zakończonej naprawie. Osoby znające proces powinny przed próbą ustalić oczekiwane relacje i informacje, które pozwalają je rozpoznać.

Pominięcie powiązanej sprawy i błędne połączenie różnych spraw mogą mieć odmienne skutki. Zespół powinien obejrzeć oba rodzaje błędów oraz sprawdzić, czy pracownik potrafi je skorygować. Nie wystarczy policzyć, ile propozycji zostało zaakceptowanych. Potrzebne jest również zrozumienie, dlaczego odrzucono pozostałe i czy wśród niewskazanych spraw nie było istotnego przypadku.

Wskazówki OpenAI dotyczące oceny opisują przygotowywanie testów związanych z konkretnym zadaniem. Nie oznacza to uniwersalnej skuteczności dla zgłoszeń serwisowych. Kryteria muszą wynikać z procesu i zostać sprawdzone na odpowiednio przygotowanych przykładach. W artykule o testowaniu asystenta AI opisujemy rolę takich scenariuszy.

Dodajcie próbę użytkownika bez dostępu do jednej ze spraw oraz sytuację, w której zgłoszenie zmienia się podczas przeglądu. Osoba podejmująca decyzję powinna wiedzieć, czy porównuje nadal aktualne dane. Jeśli powiązanie wpływa na inne systemy, test obejmuje także sposób przekazania wyniku i obsługę błędu.

Zaplanuj dane, integracje i dalszą reakcję

Przed przekazaniem opisów do zewnętrznego modelu ustalcie zakres potrzebnych danych, dostęp i warunki używanej usługi. Nie każda informacja o kliencie jest potrzebna do porównania dwóch zgłoszeń. Z drugiej strony usunięcie kontekstu urządzenia może utrudnić ocenę. Dobór należy sprawdzić na przykładach i uzgodnić z osobami odpowiedzialnymi za dane.

Dokumentacja OpenAI o kontroli danych w API opisuje opcje zależne od funkcji i konfiguracji. To źródło dla konkretnej usługi. Zasady innego dostawcy mogą się różnić, dlatego należy sprawdzić aktualną dokumentację i umowę dotyczącą rzeczywiście używanego rozwiązania.

Jeśli potwierdzona relacja trafia do innego systemu, zespół musi wiedzieć, czy aktualizacja została tam zapisana. Przy błędzie potrzebna jest osoba odpowiedzialna i sposób wyjaśnienia stanu bez ponownego tworzenia sprawy. O przekazywaniu informacji między narzędziami piszemy w artykule o API i webhookach.

Ważny jest także sposób przedstawienia propozycji osobie zgłaszającej problem. Jeśli pracownik uzna, że sprawa jest powiązana z wcześniejszą, klient powinien wiedzieć, jak będzie otrzymywać informacje o dalszym przebiegu. Nie każda organizacja stosuje tę samą procedurę, dlatego treść komunikatu oraz odpowiedzialność za kontakt trzeba uzgodnić przed uruchomieniem narzędzia.

Zespół powinien sprawdzić, co dzieje się z terminami przypisanymi do obu zgłoszeń. Połączenie historii nie może po cichu usunąć zadania, które nadal wymaga wykonania. Jeżeli wcześniejsza sprawa ma inny termin lub właściciela, osoba oceniająca musi zobaczyć tę różnicę. W razie niepewności można skierować sprawę do koordynatora zamiast automatycznie wybierać jedną z wartości.

Przy zgłoszeniach pochodzących z różnych kanałów mogą występować odmienne identyfikatory. Formularz, rozmowa telefoniczna i wiadomość e-mail nie zawsze zawierają ten sam zestaw danych. Przed porównaniem ustalcie, skąd pochodzi informacja o urządzeniu i kto może ją poprawić. Nieobecny numer nie jest dowodem, że zgłoszenie nie ma związku z żadną inną sprawą.

Warto także zachować informację o przypadkach, które pracownik obejrzał i odrzucił. Jeśli następna osoba otwiera tę samą sprawę, może potrzebować wiedzy, że podobna propozycja została już sprawdzona. Taki zapis nie powinien jednak uniemożliwiać ponownej oceny po pojawieniu się nowych danych. Powód i zakres wcześniejszej decyzji pomagają odróżnić zmianę sytuacji od niepotrzebnego powtarzania pracy.

Po zmianie modelu lub sposobu wyszukiwania powtórzcie próby na wcześniej przygotowanych przykładach. Nowa wersja może wskazywać więcej podobnych opisów, lecz równocześnie przeoczyć różnicę w identyfikatorze urządzenia. Zespół powinien ocenić zarówno przydatność wyników, jak i przypadki, w których narzędzie powinno pozostawić decyzję otwartą.

Przed rozszerzeniem procesu na kolejne obiekty sprawdźcie, czy mają one porównywalny sposób oznaczania urządzeń. Nazwa lokalna używana w jednym miejscu może oznaczać inny sprzęt w drugim. Integracja powinna zachować kontekst organizacji i lokalizacji, a pracownik musi wiedzieć, jakie źródło potwierdza przypisanie. Zmianę słownika warto uzgodnić z osobami, które używają go podczas codziennej pracy.

Jeżeli pracownik nie ma dostępu do sugerowanej sprawy, nie powinien otrzymywać jej treści w skrócie, który obchodzi istniejące ograniczenie. Zespół może ustalić inną ścieżkę wyjaśnienia, na przykład kontakt z uprawnionym właścicielem, o ile jest to odpowiednie dla procesu. Dostęp do samej listy wyników wymaga takiej samej uwagi jak dostęp do pełnego rekordu.

Po uruchomieniu analizujcie przypadki, w których pracownicy poprawiają sugestie lub nie mogą znaleźć powiązanej sprawy. W rozwiązaniach AI dla firm wynik powinien pomagać prowadzić obsługę, a odpowiedzialność za decyzję i kontakt ze zgłaszającym musi pozostać czytelna.