Monitorowanie zgłoszeń serwisowych pod kątem zagrożenia opóźnieniem to zadanie, które AI może w istocie w pełni przejąć. Nie chodzi tu o szarą strefę z udziałem nadzoru ludzkiego: samo sygnalizowanie jest zadaniem, które już dziś można zautomatyzować za pomocą istniejącej technologii (rpa), o ile spełnione są pewne warunki podstawowe.
Decydujące znaczenie mają trzy osie: ustrukturyzowanie, wolumen i zakres oceny. Wszystkie trzy wskazują w tym samym kierunku.
Ustrukturyzowanie (5 z 5). Zadanie polega na porównaniu daty z regułą: jak długo zgłoszenie jest już otwarte i kiedy upływa uzgodniony termin realizacji? To nie jest interpretacja, to jest liczenie. System zgłoszeń rejestruje czas otwarcia, termin SLA jest wcześniej ustalony, a jedyne, co jest potrzebne, to porównanie dwóch liczb. Gdy te terminy SLA są jednoznacznie zdefiniowane, nie ma miejsca na wątpliwości co do tego, co znaczy „zagrożenie”.
Wolumen (5 z 5). Zespół obsługi klienta przetwarza zwykle od kilkudziesięciu do kilkuset zgłoszeń dziennie, każde z własnym upływającym zegarem. Kierownik zespołu, który śledzi to ręcznie, musi nieustannie przeglądać listę i liczyć. To właśnie ten rodzaj powtarzalnej, dużej objętościowo pracy, przy której oprogramowanie się nie męczy i nie przeoczy żadnego zgłoszenia.
Zakres oceny (4 z 5). Samo sygnalizowanie wymaga niewielkiej oceny: termin jest terminem. Istnieje niewielka marża, ponieważ niektóre organizacje znają niuanse (na przykład: czy czas oczekiwania po stronie klienta wlicza się do zegara SLA, czy nie), ale gdy te reguły są już ustalone, nie ma już miejsca na interpretację w samej sygnalizacji.
Pozostałe osie są w przypadku tego pytania praktycznie nieistotne dla głównej kwestii. Kontakt z klientem i czynności fizyczne nie odgrywają tu roli: chodzi o proces w tle, a nie o rozmowę z klientem. Kreatywność nie wchodzi w grę: nie trzeba wymyślać nowego rozwiązania, tylko pilnować terminu. Koszty błędów i zgodność z przepisami uzyskują wynik średni (3), nie dlatego, że samo sygnalizowanie jest ryzykowne, ale dlatego, że pominięte lub błędne powiadomienie może mieć wpływ na satysfakcję klienta lub uzgodnienia umowne. To nie przemawia przeciw automatyzacji, ale przemawia za prawidłowym wcześniejszym skonfigurowaniem.
Odpowiednia technologia jest tu stosunkowo skromna: robotic process automation (rpa). Nie potrzeba modelu językowego ani złożonej AI, by porównać datę z regułą. Skrypt, który okresowo odczytuje system zgłoszeń, obliczaczas pozostały do terminu SLA i przy wcześniej ustalonym progu wysyła powiadomienie do kierownika zespołu, wykonuje to zadanie. Może to być e-mail, widżet na pulpicie lub powiadomienie w samym systemie zgłoszeń.
Warunki podstawowe są proste, ale niezbędne: terminy SLA muszą być jasno i jednoznacznie ustalone, a sygnalizacja musi być technicznie skonfigurowana na podstawie tych terminów. Jeśli jednego z nich brakuje, automatyzacja nie działa dobrze — nie dlatego, że zadanie się do niej nie nadaje, ale dlatego, że podstawa jest nieprawidłowa.
Ten wynik dotyczy sygnalizowania. Nie dotyczy on automatycznie tego, co dzieje się po powiadomieniu. W organizacji, w której eskalacja zagrożenia opóźnieniem natychmiast uruchamia ustaloną, przewidywalną akcję (na przykład: automatyczne przekazanie zgłoszenia do specjalisty), również ten kolejny etap można w dużej mierze zautomatyzować. W organizacji, w której eskalacja zależy od relacji z klientem, formy umowy lub politycznej wrażliwości, ten kolejny etap pozostaje pracą ludzką — tam odpowiednim punktem wyjścia jest nadzór ludzki nad AI, konkretnie.
Również definicja „terminu SLA” różni się w zależności od organizacji. Firma z jednym prostym, jednolitym terminem realizacji ma prostsze zadanie automatyzacyjne niż firma z dziesiątkami wariantów umów, poziomów priorytetów i reguł wyjątków. Im bardziej złożony ten zestaw reguł, tym więcej pracy przygotowawczej jest potrzebne, zanim sygnalizacja może działać niezawodnie automatycznie. Właśnie dlatego potrzebny jest skan dla poszczególnych zadań, a nie dla poszczególnych funkcji: to samo stanowisko „kierownik obsługi klienta” może w jednej firmie mieć zadanie sygnalizacyjne w dużej mierze podlegające automatyzacji, a w innej — zadanie wymagające jeszcze w dużej części pracy ręcznej.
Ta strona opisuje zadanie, a nie decyzję personalną. Czy i jak zwolniona przepustowość w ramach zespołu zostanie ponownie rozdzielona, to decyzja, która leży w gestii samej organizacji i do której mają zastosowanie własne wymogi prawne, zwłaszcza jeśli ma to konsekwencje dla stanowisk lub struktury zatrudnienia. Zachowanie należytej staranności w tym zakresie, w tym poinformowanie rady zakładowej, to odrębny proces — zob. na przykład poinformowanie rady zakładowej o AI oraz należyta staranność przy redukcji stanowisk. Ta strona nie stanowi dla tego uzasadnienia, podaje jedynie fakty dotyczące samego zadania.
Sygnalizowanie zagrożenia naruszenia SLA nie jest zadaniem odosobnionym. Podobne zadania monitorujące i sygnalizacyjne występują również w procesach finansowych, takich jak okresowe fakturowanie subskrypcji lub wymiana faktur elektronicznych za pomocą e-fakturowania. Również tam obowiązuje zasada: im bardziej ustrukturyzowane reguły i im większy wolumen, tym bardziej zadanie nadaje się do automatyzacji.
Chce Pan/Pani wiedzieć, jak to wygląda w przypadku Pana/Pani własnego zespołu, z uwzględnieniem dokładnej struktury SLA i wolumenu zgłoszeń, z którymi Pan/Pani pracuje? Bezpłatny quickscan ftetoai składa się z dwunastu pytań, można go wypełnić bez konta i daje wskazanie, jaka część godzin w Pana/Pani profilu może już dziś zostać przejęta przez AI. Pełny werkscan, który zagłębia się w Pana/Pani własne procesy na poziomie poszczególnych zadań, jest jeszcze w budowie — tej obietnicy tutaj celowo nie przedstawiamy jako większej, niż jest w rzeczywistości.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.