Zgłoszono awarię, system ticketowy pokazuje czerwony status, a użytkownicy chcą wiedzieć: co się dzieje, jak długo to jeszcze potrwa i kiedy otrzymają kolejną informację. To praca, którą pracownicy helpdesku i komunikacji wykonują codziennie. Pytanie tutaj nie brzmi, czy AI może napisać tekst, ale czy AI może samodzielnie przejąć tę konkretną pracę komunikacyjną. Odpowiedź: częściowo, i silnie zależy to od tego, o jaki rodzaj awarii chodzi.
Zadanie ocenia się wysoko pod względem ustrukturyzowania (4): zgłoszenie awarii często przebiega według ustalonego wzorca — co jest nie tak, od kiedy, które systemy są dotknięte, jaki jest przewidywany czas naprawy. Ten wzorzec jest właśnie tym, co model językowy może dobrze wypełnić, o ile dane, na których się opiera, są poprawne. Również fizyczność (5) nie stanowi przeszkody: nie jest wymagana żadna czynność w realnym świecie, tylko tekst, który musi wyjść.
Z drugiej strony kontakt z klientem ocenia się nisko (1). To z definicji komunikacja z ludźmi, którzy często są już sfrustrowani, bo ich praca stoi. Ton, moment i precyzja komunikatu decydują, czy użytkownicy czują się wysłuchani, czy zignorowani. Wygenerowany komunikat, który jest faktycznie poprawny, ale niewłaściwie ocenia pilność, wyrządza więcej szkody niż brak komunikatu.
Koszty błędów (3) są umiarkowane, ale nie do zignorowania: błędny czas naprawy lub status, który nie jest aktualizowany, podkopuje zaufanie i prowadzi do lawiny kolejnych pytań — czyli właśnie tej pracy, którą chciano zaoszczędzić. Zgodność z przepisami (4) ma znaczenie, gdy incydent podlega umowom SLA lub, w niektórych sektorach, obowiązkowi zgłoszenia: wtedy komunikacja musi być wysyłana w sposób udokumentowany, na czas i według ustalonych norm. Zakres oceny własnej (2) i kreatywność (2) są niskie: jest niewiele miejsca na samodzielne decydowanie, co się zgłasza, to w dużej mierze podążanie za szablonem z aktualnymi danymi. Wolumen (4) jest wysoki: przy dużej awarii mowa o setkach lub tysiącach użytkowników potrzebujących tego samego komunikatu, i to jest właśnie miejsce, gdzie automatyzacja uwalnia czas.
Trzy osie decydują o obrazie. Ustrukturyzowanie sprawia, że jest to technicznie wykonalne: jeśli status incydentu jest jednoznacznie zapisany w systemie, model językowy może na tej podstawie zbudować komunikat według ustalonego szablonu. Ale niski kontakt z klientem to spowalnia — nie dlatego, że AI nie umie napisać poprawnej zdania, ale dlatego, że ryzyko źle dobranego momentu lub tonu komunikatu jest większe niż w przypadku tekstu wewnętrznego lub administracyjnego. A koszty błędów sprawiają, że nadzór pozostaje niezbędny: aktualizacja statusu, która wychodzi zanim naprawa zostanie potwierdzona, lub która zbyt optymistycznie ocenia czas naprawy, prowadzi do nowych skarg, a nie do ich mniejszej liczby.
Przykład to uściśla. Przy awarii wewnętrznego systemu e-mail, gdzie wpływ jest znany a czas naprawy stosunkowo przewidywalny, AI może przygotować pierwsze zgłoszenie i tymczasową aktualizację statusu na podstawie ticketu, przy czym pracownik krótko to zatwierdza przed wysłaniem komunikatu. Przy awarii, która dotyka funkcjonalności płatności klientów, z konsekwencjami finansowymi i niepewnym czasem naprawy, sytuacja wygląda inaczej: tam potrzebna jest ludzka ocena tego, co się mówi, a czego nie, i kiedy.
W firmie z rozwiniętą stroną statusową i systemem ticketowym, który automatycznie wypełnia odpowiednie pola, część, którą może obsłużyć AI, jest większa: tekst może pochodzić bezpośrednio ze ustrukturyzowanych danych. W firmie, gdzie awarie zgłaszane są ustnie, w pojedynczych wiadomościach Slack lub przez menedżera IT, który ocenia to sam, brakuje ustrukturyzowanej podstawy i jest niewiele, co AI może samodzielnie sporządzić. Liczy się także charakter użytkowników: wewnętrzni pracownicy akceptują krótką, faktyczną aktualizację; zewnętrzni klienci z umową i SLA oczekują tonu i kompletności, które raczej wymagają ludzkiej kontroli.
To zadanie nie jest odizolowane od pozostałej części łańcucha incydentów. Czy awaria jest skutecznie komunikowana, zależy od tego, jak dobrze monitorowana jest wydajność systemów — bez wiarygodnego monitorowania nie ma aktualnego statusu, który można by komunikować. Zależy to również od tego, jak incydent jest rejestrowany i priorytetyzowany, ponieważ to decyduje o tym, jakie dane są dostępne do oparcia komunikatu. A w niektórych przypadkach komunikacja przebiega równolegle do faktycznego rozwiązywania incydentu IT pierwszej linii, gdzie aktualizacja jest tylko tak dobra, jak postęp faktycznie osiągnięty.
Konkretnie: przygotowanie tekstu na podstawie ustalonych szablonów, z aktualnym statusem incydentu jako danymi wejściowymi, jest wykonalne, gdy te dwa warunki wstępne są spełnione. Decyzja, kiedy komunikat wychodzi, w jakim tonie i czy czas naprawy jest sformułowany realistycznie, pozostaje przy pracowniku. To nie jest etap przejściowy w drodze do pełnego przejęcia — to struktura, która odpowiada temu typowi komunikacji, dopóki koszty błędów niewłaściwie umieszczonego komunikatu pozostają wyższe niż czas potrzebny na jego sprawdzenie.
Jeśli ta analiza prowadzi Państwa do przemyślenia zatrudnienia pracowników helpdesku lub komunikacji, obowiązują w tym zakresie własne wymogi prawne dotyczące pracy i współdecydowania; ta strona nie stanowi porady personalnej i nie jest podstawą do decyzji o zwolnieniu. Więcej o szerszej rozwadze wokół zmian stanowisk, zob. rozwaga przy likwidacji stanowisk.
Chcą Państwo wiedzieć, jaka część komunikacji o awariach w Państwa firmie już dziś spełnia te warunki wstępne? Bezpłatny quickscan FTE TO AI składa się z dwunastu pytań, nie wymaga konta i podaje wskaźnik, jaką część godzin w tym profilu AI jest w stanie przejąć już dziś. Pełny werkscan, z rozszerzoną analizą zadań na poziomie zespołu, jest jeszcze w budowie — świadomie nie oferujemy go jeszcze tutaj.
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.